Coach & Captain - a pattern for team leadership
Photo by Nathalie Jolie on Unsplash
This is our story of how we managed team and technical direction by splitting the team and tech leadership, from the Tech Lead’s perspective.
A Team Lead’s responsibilities range from overseeing technical direction, delivery and supporting their direct reports. In one of my previous companies, this incredible work load led to burnout and multiple Team Lead resignations. So we decided to experiment with implementing Team and Technical leads within the same team to combat the workload. This is how it went (from the Tech Lead’s perspective). I call this “Coach and Captain”.
The previous role of the Team Lead
All of our teams had a Team Lead. This was a developer who had moved into a management position. All the developers in a team reported to the Team Lead. This person was not only a line-manager, expected to have regular one-to-ones with everyone in their team, but also was responsible for:
- Architecture & technical product direction
- Software Product delivery and co-ordination of work across the different products - working with Product Managers
- Technical mentorship to improve skills & practices
This includes:
- being in every meeting about work planning, updates, story creation, team logistics & recruitment
- talking with users & clients
- researching technology, tools & vendors
- recruiting and reviewing staff.
- reviewing and improving team relations and processes, and the list goes on.
We had fairly large teams. My team varied between 6-8 people over the span of 2 years. This size worked well for us as we maintained all of our own infrastructure, wrote and deployed all our own code and were on-call for everything we built.
Due to the number of responsibilities and meetings the Team Leads had, there were many scenarios where they were simply not available to the team.
“So the seniors were available weren’t they?”. The seniors were definitely available, however, half our team was senior and each person had their own ideas about direction and implementation choices, which took time to resolve and often involved the lead’s input to finalise. With the amount of responsibilities, three Team Leads reached breaking point and resigned within a few weeks of each other.
Introducing Tech Leads
Clearly the stress of taking on all that responsibility caused our leaders to burn out. Management finally made the decision to split the line management and technical responsibilities (better late than never?). Each team would have a Technical Lead as well as a Team Lead. The Tech Lead would take on the Technical Strategy & Direction, tooling & practice oversight and, in my team, career-development work. The Team Lead would remain the line manager and main communication liason. The tri-vector was completed with the Product Manager whom was responsible for Product direciton, priorities and business comms. Between the three roles, besides over Christmas, there was to be delivery and communication continuity. In simplistic terms “The What” was owned by the PM, “The When” by the Team Lead and “The How” by the Tech Lead.
Our Coach and Captain
Our Team Lead was not a coder. They had run their own start-up for a technical product and although they didn’t code, had a good grasp of architecture and data & behaviour flow. Importantly, they knew what it took to deliver a software product. The way they worked, reminded me a lot of a sports coach. They don’t ‘play’ with the team ‘on the field’ but are directing from the sidelines, looking at the wider game in play. Our new manager made sure the things the PM wanted to happen were co-ordinated and communication was constant. They made sure to actively listen to each person, providing advice on personal well-being and generally taking care of them within the organisation. They were an excellent communicator and their experience in navigating politics (which exists everywhere, let’s not kid ourselves) and understanding priorities in the broader context of the wider business, greatly helped the team understand the context and true impact of their work. They were also a good mediator and worked with each person to improve their ability to work within a team. They really brought home to me, the true value of communication, facilitator and mediator skills - things they don’t teach you in dev school.
The Tech Lead ‘played on the field’ with the team, and would lead the technical day-to-day. The Tech Lead sat with the team almost all week, was available for reviews, oversight, direction & judgement calls and coded with the team. Unlike the previous Team Lead who was bogged down with meetings and logistics, the Tech Lead was much more available which means decisions were made more quickly, work unblocked and technical re-direction was able to happen rapidly. Technical direction and ways of working were important in this role and I encouraged a lot of collaborative practices like pairing or ensembling where the team felt comfortable doing so.
What did the team think?
As this Team and Tech Lead worked well together, the team enjoyed the leadership configuration because they felt that their needs as people and technologists were able to be addressed. The team’s motivation and output improved greatly overall. The Tech Lead availability sped up technical work. Some decisions were more clearly scoped for the Team or Tech Lead but others were not which required the other to be consulted. This did not burdon us greatly as the Leads communicated daily if not more than that, but its worth calling out. It is clear that if there is not trust between the 2 Leads, this configuration could greatly slow a team’s delivery speed. Luckily in our case, this trust was in place and the 2 Lead’s were highly aligned on goals and processes. As time went on, the need for consultancy between the two became less as well.
What I learned as the Tech Lead
I’ve been asked a few times if I would consider a Team Lead position but I haven’t wanted to remove myself from the codebase just yet. I very much enjoy still building software, and I’m fully aware that Team Lead roles take you away from the code, at least in a mid-sized company and up (my preferred company sizes). I’ve also been inside many teams where a Technical Team Lead (TTL) could be absent from the team for hours and days and though a Senior Developer is perfectly capable of making a tactical decision, they may be missing context in overall strategy (either by their choice or due to culture). In addition, I personally gained a lot of insight from working with someone who had more experience with the other aspects of the business. It was incredibly insightful to get feedback on how I was coming across, where I needed to be clearer and what certain situations truly meant (translating ‘business speak’). Getting perspective on the wider business and the timely feedback on my leadership was invaluable.
So they took over all the admin while you did the fun stuff?
This is feedback I received after presenting this topic in a talk. It amused me because the sentiment was similar to the complaints made by the old Team Leads, and other Team Leads I’ve worked with before. But I would warn against thinking about it like this. This distribution of work does not take away from the fact that the Tech Lead should be as informed about the teams’ overall functionality, progress, delivery, etc as they would be if they were also the Team Lead. Vice versa, the Team Lead needs to understand the high-level technical strategy, constraints and skill requirements, as well as the Tech Lead does, even if they don’t implement.
Don’t senior++ engineers cover this?
My experience of working with Staff or Principal Engineers is, although they have a big impact on technical strategy (which our Tech Leads managed along with the Senior VP of Tech), they usually do not reside on a team and are not directly responsible for looking after products. Although I have no doubt that these roles vary widely across organisations, this is my current experience. There can also be multiple engineers at this level, which brings us back to the tie-breaker problem. The Tech Lead is the tie-breaker and if done skillfully, hard feelings can be avoided. I don’t see this role as being in contrast to grades as it is more of a role than a grade.
What about an actual Coach or Scrum Master?
Having worked with Scrum Masters and Developer Coaches, the immediate difference here is accountability. I know this can be a touchy subject but to make it simple - Scrum masters and technical or process coaches are there temporarily to improve a way of working, skill set, etc and then leave once some metric has been reached. The best Scrum masters I’ve met, have said to me, “if I do my job well enough, you won’t need me anymore”. This is great, sometimes you just need them to get things back on track. But this coach is not a temporary team member with a short term directive. They are just as accountable for the team’s performance as the rest of the team is. Personally this leads to trust with the team - this person is everyone’s line manager at the end of the day.
Where would you use this?
Not all organisations would require or benefit from this set-up, but ours did. In smaller teams where the management aspect is less time-consuming, and the TTL is keen to code at least 50% of the time, a split would probably be a burden than a help. If the Team Lead is in the role to show technical prowess as well as manage process, they will clash with a Tech Lead. You’ll also be in trouble if the Lead’s do not get along or trust each other. Also if the team is quite small, your Tech Lead can probably handle Team Lead responsibilities with some training (if they don’t have experience). In my opinion, development teams of 6 people or more, could certainly benefit from this set-up as the technical work demands attention and you’re likely to have more associate to mid-level engineers than seniors in a larger team (in my experience, larger teams are lighter on seniors). Also, if the technical work is very demanding, it can be very difficult for a Technical Lead to keep up with Technical Strategy & code quality as well as maintain a high-level of engagement with each team member. It’s also useful: - in difficult teams that are not quite working well together - you have a talented Technical Leader but they don’t want to line manage. - you have immature developers who are technically gifted but need guidance on working within a team and taming their ego. Our team benefited from an improvement in dedicated time from both Leads, continual
An option
Having a Coach and Captain won’t suit every team, never-mind every business but it provides an alternative team leadership set-up, where the right combination of skills can result in a team whose people are not affected by an over-loaded Technical Team Lead, virtually guarantees continuity of communication & productivity and provides another avenue for developing Developers into Leaders by showing them and coaching them, rather than it simply being the next career step and having them go in blind. Personally, the experience changed my life, and it ultimately made me a better leader and engineer.