If you’re just getting started with DevOps, there are several team organizational models to consider.
A few key points to keep in mind as you design your team structure:
-
The organizational model you start with should change as you add more people, different DevOps roles, and more projects. Expect to keep iterating as you go.
-
The ultimate goal of DevOps is to spread the message, tools, and processes throughout the company so that, eventually, everyone is working “the DevOps way.” At some point, if your approach is successful, DevOps as a separate group will disappear.
-
The model you begin with should depend on how many projects or products you’re working on, the size of your teams, and the size of your company.
-
Keep your team size small, with three to eight people max. Some experts say up to 12 is OK, but that’s a bit large for the “two-pizza” rule.
Why building a DevOps team is important
Even though DevOps is arguably the most efficient way to get software out the door, no one actually ever said it’s easy. So building the right DevOps team is a critical step in the process.
The right DevOps team will serve as the backbone of the entire effort and will model what success looks like to the rest of the organization. There is no “one size fits all” however – each team will be different depending on needs and resources.
5 examples of DevOps team models
Here are five DevOps organizational models to consider as you get going, according to Matthew Skelton and Manuel Pais, experts who wrote a book called Team Topologies about this topic and then updated the book with a related microsite. Their work is a must-read for anyone who’s trying to figure out which DevOps structure is best for their company.
1. Dev and ops co-exist, with a “DevOps” group in between
This can be a good interim strategy until you can build out a full DevOps program. The DevOps team translates between the two groups, which pretty much stay in place as they currently are, and DevOps facilitates all work on a project.
Just don’t keep this structure in place too long. You don’t want to reinforce the separate silos as they currently exist for any longer than absolutely necessary.
2. Dev and ops groups remain separate organizationally but on equal footing
This is also a reasonable place to start: Everyone collaborates but can specialize where needed. Common tools will go a long way to helping facilitate good communication. In this model, several dev teams can be working on different products or services.
Make sure teams communicate regularly. Invite a rep from each camp to the other’s meetings, for instance. And appoint a liaison to the rest of the company to make sure executives and line-of-business leaders know how DevOps is going, and so dev and ops can be part of conversations about the top corporate priorities.
3. Create one team, maybe “no ops”?
In this model, a single team has shared goals with no separate functions. The reason it’s called “no ops” is because ops is so automated it’s like it doesn’t actually exist.
This level of automation is so “aspirational” that many experts express caution about this approach. To eliminate any hands-on tasks, teams would need extensive machine learning and artificial intelligence solutions, and a flat, streamlined organization that prioritizes communication and workflow. TL;DR: NoOps may not ever be a reality.
However, don’t use this as an excuse to do away with the ops team. You are going to need those folks. Devs can’t do it all.
4. Ops as infrastructure consultants
This model works best for companies with a traditional IT group that has multiple projects and includes ops pros. It’s also good for those using a lot of cloud services or expecting to do so.
Here, ops acts as an internal consultant to create scalable web services and cloud compute capacity, a sort of mini-web services provider. In our 2021 Global DevSecOps Survey, a plurality of ops pros told us this is exactly how their jobs are evolving — out of wrestling toolchains and into ownership of the team’s cloud computing efforts. Dev teams continue to do their work, with DevOps specialists within the dev group responsible for metrics, monitoring, and communicating with the ops team.
5. DevOps-as-a-service
You may decide your organization just doesn’t have the internal expertise or resources to create your own DevOps initiative, so you should hire an outside firm or consultancy to get started. This DevOps-as-a-service (DaaS) model is especially helpful for small companies with limited in-house IT skills.
Using DaaS in the short term offers another advantage: the opportunity to learn from your outsourcer how to eventually create your own internal DevOps team.
Make sure you understand the outsourcer’s security landscape and your own responsibilities in this area, as you would with any outside firm. The difference here is that the team, processes, and software the outsourcer plans to use will be deeply embedded in your company’s infrastructure — it’s not something you can easily switch from. Also ensure that the outsourcer’s tools will work with what you already have in-house.
Finally, keep a keen eye on costs and understand how the outsourcer will charge for its services.
Other organizational DevOps schemes include:
A two-tier model, with a business systems team responsible for the end-to-end product cycle and platform teams that manage the underlying hardware, software, and other infrastructure. DevOps and SRE groups are separate, with DevOps part of the dev team and Site Reliability Engineers part of ops. This model requires a mature operations and development culture.
Whichever organization model you choose, remember the idea of DevOps is to break down silos, not create new ones. Constantly reevaluate what’s working, what’s not, and how to deliver most effectively what your customers need.
Key characteristics of a successful DevOps team
Here are some key charecteristics that you can expect to find in a well running DevOps team:
- Collaboration. A DevOps team may have as few as 2 members to as many as 12 or more.
- Communication. Nothing creates more bottlenecks on a team than members who don’t talk to each other, and DevOps projects always have a million moving parts. Document progress in a project thread, have regular meeting syncs or check in via Slack to keep team members up to speed and discuss any hurdles to avoid burnout or major delays.
- Team autonomy. Work together, but also be able to work alone.
- Willingness to iterate. Nothing will be perfect the first time, or even the second. In fact, a lot of DevOps work is just about making continuous, as-needed improvements to existing work, or replacing something that is no longer working for the original purpose. Keep on iterating!
- Fast feedback, high empathy and trust. DevOps can feel like a whirlwind. Be mindful and respectful of the difficulties your teammates may be dealing with, be ready to give and receive feedback quickly, and trust each other for an optimal outcome and pleasant work environment.
Getting started with DevOps
There are a few steps to follow in order to get started on the planning and development of your DevOps team. Here are some pointers:
1. Create a roadmap. Start with the basic goals, add in wish list items, and write it all out attaching a timeframe as needed. The map should include a list of action items broken down by priority and who is responsible for completing each step.
2. Ensure buy-in, and maybe add a champion. Evangelize DevOps to the entire organization. Some teams find having a dedicated DevOps champion can help.
3. Select the solution. Consider the budget, needs, and knowledge levels to make the best technology choices for the team.
4. Automate processes where appropriate. DevOps doesn’t work without automation and for many teams, automation is the top priority. Look at areas where you can reduce manual work.
5. Set up monitoring. Have a process for monitoring security, metrics, and everything in between. Track progress. Always be able to give stakeholders a status update.
Johanna Ambrosio is a technology writer in the greater Boston area.
