Category Whitepapers and Guides
DevOps Team Structures
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 far wider reach as they need to enable business units as well.
2. Virtual teams
This is a way of organising 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.
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 specialised functions such as developers and sys admins.
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.
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’ organisations.
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 organisation.
Here at ECS Digital we’re always happy to talk about what we do, why and how. If you’re interested in finding out how we can help you, please do get in touch.