"Sit on this and rotate!"

--Suggestion from a project manager to two relatively senior developers on a team in need of a tech lead [1]

Last week I finished my second eight-week stint as technical lead of a medium-sized team of ThoughtWorkers. Patrick Farley and I alternated in the role over the last seven months or so, switching between development and tech leading at each production release. As we're both approaching one year on the project (and therefore roll-off) I've now handed the reins over to someone new (Paul Gross) who will likely rotate with another team member if the team continues to release on a similar schedule.

Rotating the tech lead position isn't a standard practice on ThoughtWorks projects, but it's worked out really well for us, so I thought I'd document it a bit.

Pro

The simplest and most obvious benefit of rotating the role is knowledge sharing. The tech lead will be exposed to aspects of the release process and production deployment (including lots of people and groups in the organization) that the rest of team shouldn't be concerned with if they're to continue developing new functionality at maximum velocity. While it's important to protect the team from distractions where practical, it's also important not to create a one-person knowledge silo. (What's your truck number?) Rotating the role means that you've likely got more than one person available who's been through the whole cycle, without having had to simultaneously dedicate multiple capable developers to work that's largely about always being available for a context switch to ask or answer the right questions.

Besides specifically spreading knowledge relevant to the current project, rotating the leadership role also creates more well-rounded developers, giving them some of the experience necessary to lead other teams. Whether in the context of a consulting organization or a company employing developers for its own projects, this is hugely valuable for everyone involved. The developers don't just benefit from being in multiple roles: they also get to see how a number of other people deal with the same issues. (Even the devs who don't rotate into the lead role benefit from that.)

Rotation also helps keep the lead's technical tools from getting dull. This goes for general development chops as well as knowledge of how the team's systems work. During my runs I knew a lot about what was coming up in terms of requirements, and I was always there for team tasking sessions when the shape of the implementation was generally hashed out, but once something was being implemented I generally only learned more about things that came up in team-room discussions or where the pair working the story sought my advice. No good developer wants to become an ivory-tower architect, and rotating back to a role where you can focus on making the rubber meet the road is a great way of making sure it doesn't happen.

There's also a therapeutic advantage to rotation. The tech lead, like the project manager but to a lesser extent, bears responsibility for the work of a whole lot of people, and that can be exhausting and frustrating. I was extremely fortunate to have an incredible team behind me, so when it came to their work I felt comfortable trusting them to deliver on reasonable commitments. But our application was in production, with new releases rolling out regularly, and that meant lots of external groups playing a vital role in our team's delivery.

Or not.

It's a sad fact of enterprise software consulting that we're often brought in because an organization's had difficulty delivering reliably. They probably haven't identified all the causes of their difficulties, and many are likely outside the scope of what our team can remedy. The development group and business sponsors may be completely aligned on maximizing delivery value while minimizing process overhead for the project, and we may achieve incredible results in developing working software that meets the business need. But that only gets you so far before you need to coordinate with the release management group, the configuration management group, the database development group, the database infrastructure group, the quality assurance group, the network design group, the network support group, the network monitoring group, etc. Chances are the organization's difficulty in delivering has had a lot to do with the way these organs have worked together (or against each other). Our software has to work its way through the same system to deliver actual value. Certainly we can try to influence these groups to streamline their processes, but if our charter is to develop software, this is a delicate balance. The orchestration of dozens of informal conversations, formal meetings, ticketing system requests, and emails to achieve seemingly simple goals can be hilarious and even fun (when it all goes right) but it's decidedly not technical leadership, and it's easy to burn out.

Rotating the lead role could also pay off if someone doesn't work out. There are a couple ways rotation mitigates the pain and project risk introduced by a bad technical lead. First, the struggling lead has at least one former leader whose experience and advice they can draw on to try to improve as well as to directly supplement their own efforts. Failing that, the worst case is that a former lead is reinstated, which will likely be a far greater comfort to the customer than having someone new brought in. The security of having past leaders available makes this a great way to let someone stretch into a more senior role than they've had before without betting an entire project on their success.

Con

What are the downsides to rotating developers through the role? The only one we've seen is that you have to bring someone new up to speed more frequently than you otherwise would. Though the cost here is not negligible, I think it's justified, particularly in a consulting situation where eventual roll-offs and transitions are inevitable.

How

As far as how to do the transition, we tried it two ways.

The first time we rotated, Patrick was focusing on our initial release to production, but we also had a bunch of new stories for upcoming releases that needed to be estimated and have some open questions resolved. It was too much for one person, so I focused on the upcoming stories while he dealt with the production roll-out. As support work on Release 1 quieted down, we shifted developers over to work stories for Release 2. The upside of that was there were enough hours in the day for Patrick to get production straightened out without collapsing from exhaustion, while stories for Release 2 got the attention they needed. The most immediate downside was that I hadn't been exposed to much of the release and deployment process, so as we began dealing with production support, I had to lean on him more than I would have liked, sometimes pulling him out of normal development work.

When the next rotation came up, we felt it would be inefficient having us once again simultaneously acting as tech leads for different releases, so we did more of a hard cut-over. This reduced confusion among the client and the team regarding who to talk to about what, but it may not have been practical if we hadn't both already had deployments under our belts. The cut-over felt good, so we've stuck with that since.

Try it?

Here's some background on the scenario where it worked for us. Our team size has varied: during the time we've been rotating we've had between seven and ten developers, two to three business analysts, a dedicated iteration manager only briefly, and a project manager/client principal mostly but not entirely dedicated to our project. Before we started, the client organization already had a large body of software in production and established processes for release and deployment.

Another thing to keep in mind that might be important for any team looking to try this is that Patrick and I had worked together for months before the team down-sizing that led to the rotation. We'd developed a strong mutual respect, each feeling that the other was capable of succeeding in the role. We were also both happy to take a normal development role on a team with the other leading. It's hard for me to see the rotation succeeding without that, and it may be the most difficult element to recreate on another team.

Obviously there are lots of other factors that may have helped this work for us. Your mileage will vary. For what it's worth, both our Client Principal and Patrick have said they want to try something similar at other projects, and I do too, assuming we seem to have the right ingredients.

Have you been in situations where rotating team members through leadership positions might have helped? Have you tried it? Let us know. Thanks.

[1] No, no one really said that.