The Best Team Structures for DevOps Success

Agile is taking the world by storm. Businesses of all shapes and sizes are seeing the benefits of embracing DevOps and moving to adopt a more agile culture. A number of high-profile companies have had great success in applying DevOps, including streaming giants Netflix and Spotify.

We’d like to tell you that everything is rosy but, while some are celebrating, others are struggling. The reason? It’s often the way they’re working.

Getting the formation of teams and structures right in order to implement DevOps efficiently isn’t easy but it’s absolutely key to a successful DevOps adoption.

So, what exactly is the best way to work?

To answer that, we need to look at what companies are doing. Whilst there are many ways you could structure your teams, we typically see three types in our work with clients:

1. Platform Engineering

In this scenario, the Platform Operations Team sits inside the different business units (e.g. mortgages or payments) to help the teams in that unit adopt different working practices. This provides a wider holistic view to the different business units.

The team comprises developers, QAs and release engineers who are responsible for building out platform availability, upgrades and providing new services. There would be an overarching Platform Engineering team to ensure consistency across business units. They may sometimes be referred to as SREs (Site Reliability Engineers) but the responsibility is a far wider reach as they need to enable business units as well.

Pros

• Unified and consistent – a singular message across the board
• Maintain control and flexibility into individual teams with different ways of working

Cons

• Takes time to adopt and build
• Resource required to learn about the different business units – gathering the different requirements and building a platform to support everyone
• If implemented incorrectly the “enabler” becomes a single point of failure – if they can’t enable others, they have to do the work personally and become a bottleneck

2. Virtual Teams

This is a way of organizing around virtual teams. The idea is to take people from each of the business units and form one single virtual team where the high-level strategic and tactical decisions are made.

The virtual team can then take information from the business units to bring out a holistic view of what each unit needs and wants, using that to build out the practice.

Rather than being a dedicated platform team, it is designed to leverage existing knowledge within the teams themselves.

Pros

• People are empowered to make their own decisions
• They have free rein over how they go about tasks because they know the business units
• It can sometimes be faster as they already understand what they want to do in their business units

Cons

• Risk of individual business units implementing strategic decisions made by the virtual team differently
• Uneven balance of transformation within the company as teams work at different paces
• Can create anarchy between teams as there is little to no collaboration. This is particularly problematic with business units that need to integrate with each other
• Possible duplicated effort – if one team has done it already then another team may not know because virtual teams not running effectively

3. Teams Based on Functions

This is a much more traditional way of working. Instead of being formed by business units, the process is built on different specialized functions such as developers and sysadmins. 

Rather than attempting to create a collaborative model, this method is extremely linear – you start with the developer to build out the practice, following which it is pushed out to the different functions. All the teams have their own champions and essentially do their own thing independently of other teams.

Pros

• At a granular level, adoption can be faster within the smaller practices, but this isn’t necessarily reflected in the overall speed of adoption
• Individuals own their own responsibilities

Cons

• Miss out on a holistic view of what’s going on end-to-end – teams are only concerned with their own area
• Linear organisation means you can do all your development work, move into the QA stage and only then realise that there are issues that need to be solved - and that you need to go back to the development phase.

Which Structure Should You Use?

All businesses need to adopt the strategy that works for them. The three we’ve outlined above are some of the most common ways of working that we’ve seen our clients use and that we’ve used to help transform our clients’ organizations.

In our experience, the method that’s both most successful and quickly adopted is the first –Platform Engineering. It has a number of advantages: with this team structure, people can jump teams or manage multiple business units depending on the resources and requirements of the businesses.

In addition, this structure provides the most consistency thanks to its dedicated team. In more regulated environments where governance and regulation compliance is key, a central team can ensure compliance across the organization.