A DevOps transformation is not magic. Any company can do it. What makes the difference is who you put on the first team — because that team has to deliver the proof that DevOps actually works in your context.
Start Small, Then Pick the Team#
Before you choose people, choose the right project. Start with something small to medium in size. Decisions have less impact, fewer stakeholders need to be aligned, and the team can move fast enough to build momentum. With a manageable scope on the table, you can be deliberate about who joins the team — instead of grabbing whoever happens to be available.
Generalists Before Specialists#
The golden rule when staffing a DevOps team is generalists before specialists. A team of T-shaped people who can pick up build, test, deploy, monitor, and respond to incidents will outperform a team of deep specialists who hand work over a wall. DevOps is about closing loops, and loops close faster when the same people can pull the next thread.
That does not mean you ban specialists. It means the centre of gravity is generalist, with specialists pulled in for specific problems. If your first team is mostly siloed experts, the silos will follow them into the new way of working.
Innovators, Early Adopters, and Respected Voices#
The team needs three kinds of people. Innovators who genuinely want to try a new approach. Early adopters who will follow them quickly and bring others along. And at least one or two people who carry weight across the company — engineers or leaders that others listen to. The first two give you energy. The third one gives you credibility. Without credibility, every result you produce will be dismissed as a special case.
Free Them From Everything Else#
The new team needs to be freed up from any other work. No part-time DevOps experiments. No “they will help on the side.” If people are split across multiple commitments, the transformation gets the leftover hours, and leftover hours are not enough.
Where you can, put them in the same location. Co-location is not mandatory in 2020-and-beyond, but reducing communication friction matters more in the early phase than almost anywhere else. They are inventing a way of working — they need to be able to turn around and ask each other questions.
Exempt Them From the Old Rules#
Be willing to exempt the team from corporate rules and guidelines wherever possible. Change requests, ticket-driven handoffs, mandatory architecture review boards — these processes were built for the old way. If you force the new team to live inside them, you are testing whether the old process can survive DevOps, which is the wrong experiment. The right experiment is whether the team can deliver value faster and safer with a new way of working. You will reintroduce governance later, redesigned around what the team learns.
Critical Mass#
Once the first team has delivered the requested improvements on the first product, pick the next product and start again. As more teams transform, you reach critical mass. Alliances form, success stories spread, and further transformations get easier — because now you have proof, not promises.
Key Takeaways#
- Pick the project, then pick the team. Small to medium scope keeps the experiment honest and the feedback loop tight.
- Generalists before specialists. Closing loops needs people who can pick up the next part of the work, not pass it on.
- Mix innovators, early adopters, and respected voices. Energy plus credibility is what makes results stick.
- Free the team from everything else. Part-time DevOps does not work. Full focus or no focus.
- Exempt them from old rules. Test the new way of working, not whether the old process can survive it.
- Repeat until critical mass. Each transformed product makes the next one easier.