Well Qualified vs Uniquely Qualified
When I was a backend team lead, I would sometimes jump in and help during sprints by writing code or diving into operations. Occasionally I would even be the best person for the job because I had domain knowledge for that service or sub-system.
So why do I always prioritize dev work dead last on my list of to-dos?
Missed Learning Opportunities
I think many will jump to this first reason. It’s not that I didn’t want to help; it’s that by taking tasks (particularly those with which I have significant experience), I’m not allowing other engineers to learn. Letting (and encouraging) engineers work on new parts of the system is an investment in:
An engineer’s wellbeing and career as they learn new tools and techniques
The health of the team by distributing knowledge of less well-known system components
Faster delivery of future features in this part of the system
The thing about investment is there is an upfront cost. Slower development now means fewer features, bug fixes, or tech debt payments going out the door.
These are tradeoffs team leads need to make. An investment right before a big release or under tight deadlines might not be the best choice, though there’s never a perfect time to make these investments.
Where can you get the highest return on investment? How can you spread learning across your team? Can you buy time from product management to make these investments by highlighting hazardous parts of your system? There are many ways to work in this investment (you’ll never be “given” time to do this work, you always have to fit it in somewhere), but this isn’t the biggest reason I prioritize dev work dead last.
Hummingbirds
Hummingbirds are uniquely qualified to drink nectar out of long, thin flowers. There’s more competition for other flowers they’re also well qualified to drink from.
Uniquely Qualified
As described above, team leads may be well qualified to pick up certain types of work. For no dev work, however, is the team lead uniquely qualified. The rest of the team can pick up any dev work, it’s just a matter of how quickly they can get it done (the whole section above), not if they can get it done.
I really want to focus on this point. Team leads (or any job role, for that matter) are bottlenecks for any work they are uniquely qualified for: there’s nobody else that can perform the work. As quoted by Gene Kim in The Phoenix Project:
“Any improvements made anywhere besides the bottleneck are an illusion.”
Improving efficiencies of other work that a lead is well qualified for (by jumping in and helping) is an improvement in an area that’s not a bottleneck. A leader should help with other work only after they complete work they’re the bottleneck for.
For a team lead, there are many tasks that only the team lead can perform:
Perform Agile ceremonies to keep the work and team moving forward
Working with other team leads to identify and unblock cross-team dependencies
Plan future tasks with product management and engineering leadership
Coach and mentor individuals on the team
Architecting or working with the system architect to design future parts of the system (though engineers should review this work)
The work above is what the team lead is uniquely qualified for. It’s part of the job role. If a leader spends their time on dev work, there is a significant risk that some of the tasks listed above go undone. If, instead, the team lead prioritizes the work above, then it’s possible some dev work isn’t complete, but the rest of the team can help fill in those gaps.
Conclusion
One of the biggest challenges with prioritizing uniquely qualified work over well-qualified work is that the latter category is often more visible when it’s not done. Delayed features, long-standing bugs, and ugly burndown charts stick out to management. In contrast, stagnated career development, unhappy engineers, and knowledge bottlenecks are subtle and take longer to show their actual costs.
The core challenge for a team lead is just that: short-term investments in the team, product, and architecture result in the long-term health of the product, better employee happiness, and lower risk to future features. Recognizing and communicating this can be challenging, but I believe that’s what separates good leaders from the great.
Choose your investments wisely and think about what work you’re uniquely qualified for that you’re passing up each time you crack open your IDE. How could you multiply the force of your team instead of just adding to it?
If you’re interested in learning more about becoming a force multiplier for your team, send me a note at brian@connsulting.io or schedule a time to chat at https://calendly.com/connsulting.
Related Content
