“Share your toys” was a phrase that many of us heard from adults growing up. For DevOps teams around the country, that sentiment never really dies. These units share and create “toys” (or, incredibly important tools) for their engineering and IT teams that allow the two groups to interact with greater efficiency.
We spoke with DevOps experts from Austin’s Iodine Software and TrustRadius, who shared the importance of working within key site reliability engineering team principles — like making data-based decisions — and the benefits of incorporating DevOps into departments across the business.
Iodine Software’s Director of Technical Services Cheng Zhou said the company’s site reliability engineering team is guided by a set of fundamental ideals that keep them hitting goals, like productizing ideas in short windows of time. And time is of the essence when you consider Iodine’s mission of improving hospitals’ clinical documentation.
How have you structured your DevOps team, and why?
Iodine’s site reliability engineering team serves all products and we work closely with engineering throughout. Our team orients toward principles that we think are critical for every successful SRE team, including engineering velocity, making decisions by metrics rather than patterns, focusing on the sustainability of on-call and practicing what you plan to be good at.
Our structure is largely an artifact of size. We started with a single, monolithic service that has exploded quickly. As cardinality increases, we’ll reevaluate whether our structure best supports those principles.
We launched a brand new product from inception to first live customer within six months...”
What was a recent DevOps win that resulted from your team structure?
Recently, we launched a brand new product from inception to first live customer within six months using a global development team. The product team had an embedded SRE who was supported by the rest of the SRE team at the outset. Because of that structure, deployability was built in from day one and we were able to go live without drama. This would not have been possible if we came into the process any later.
If certain professional tactics work well, why not use them in as many places as possible? CTO Scott Brittain at TrustRadius said his team injects fundamental DevOps principles like automation and data migration into just about every area of the business.
How have you structured your DevOps team, and why?
When it comes to rolling out new technology, we think of the entire business as “the product.” So in relation to DevOps, we thought broadly about how we could apply that division’s skills across every department, including sales, marketing, research, customer success and product. By doing so, we recognized the company-wide need to implement core principles we find in modern DevOps: keeping systems running, continuous improvement, deploying new technology and automating every job function.
Our ops organization features a director of DevOps, a director of revenue operations, an operations manager, an operations engineer and several outside contractors.
We recognized the company-wide need to implement core principles we find in modern DevOps.”
What was a recent DevOps win that resulted from your team structure?
We’ve seen many wins from applying this cross-functional group, but a recent one had us snapshotting our production product-data into Salesforce, where sales and customer success teams would have greater access to run their workflows. Transforming and streaming production data into external systems — which is the expertise of traditional DevOps — combined perfectly with the business operations skills of schema design, reporting and business analysis. The combined team was able to anticipate the user’s needs more effectively without normal departmental silos, resulting in very little rework and rapid project completion.
