Doing it all is not your job, Team Leader!
In a leadership role your job is to grow your team and deliver value. You can't do that if you're too busy trying to do it all.
I was discussing the opportunity to step into leadership roles with an individual on my team.
I don't want to be stuck doing nothing but technical specifications and code reviews... And meetings...
I understand where they were coming from. I'd had those thoughts myself. Thinking I'd have to wave goodbye to the joys of writing code and solving difficult technical problems. That the age of endless specification of requirements and code review would begin.
This is not your job.
What do you mean?
You may be saying
I've been designated team lead? There's a non-zero chance I'm also the most senior member of my team!
True, you were designated the team lead. As such it's your job to ensure that the team delivers what it needs to for the organization. To develop the capabilities of the members of the team so that they can continue to meet the needs of the organization.
Rather than exploring what your job is, here we're just going to break down what your job isn't.
Why doing it all isn't your job
Explicitly, it’s not your job as the team lead to do all of the architecture, technical specification work, specification review, and code review.
In fact, you’re actively hurting the team if you do this. To become Senior, members of the team also need to be given the opportunity to do each of these things and get better at it.
If you're always the first one to put up a code review, the first one to review a specification, or the only one to write a specification, you're robbing the team of the opportunity to grow and improve.
Put more bluntly, if you do all of this, they will never be given the opportunity to grow into seniors on the job. This means that your workload will never get lighter. Because you're preventing your team from becoming more capable.
This is going to hurt at first. Other members of the team probably aren't as skilled at building out a technical specification, or reviewing code. Some things you would have caught will slip through.
This is part of the process. Make another pass through after they do, to coach them through what they missed, and how they can do better next time.
How to avoid doing it all
Given that you understand why this isn't your job, and why this behavior is in fact bad, here are a few strategies to make the transition easier:
- Set limits on the number of code reviews you do, specs you write, and review per day or week. If necessary, explicitly tell the team that you've hit your limit for the period, and you need them to step up to the plate.
- Consciously ensure that you're not the first one to review some pieces of code, or specifications.
- Assign work that needs to be specified to other members of the team. Review it.
- Assign bugs to other members of the team to diagnose. Walk them through why you triaged it with the priority that you did.
- If you're not comfortable with the level the team executes these tasks, take the time to pair with them on it. Or if you're unable to pair with them when they're working on it, review it. Even if it ends up being a meta-review.
Doing this will also ensure you continue to have time to write code as an individual contributor. By taking these steps the age of writing code doesn't have to end yet.
Agree? Disagree, thinking I'm dangerously wrong? Either way I want to hear about it. @brit_broderick or email@example.com.