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.

When discussing the opportunity to step into leadership roles with individuals on and off my team, folks have expressed apprehension, thinking they'd have to wave goodbye to writing code as an individual, and 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, what do you mean this isn't my job? 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, and as such it's your job to ensure that the team delivers what it needs to for the organization, and 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 why this isn't your job.

Why doing it all isn't your job

Explicitly, it’s not your job as the team lead to do all of the 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 them 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 never allowing your team to become more capable.

This is likely going to feel a bit painful at first, because 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 may even slip through. This is part of the process. Make another pass through after they do if needed to coach them through what they missed, and how they can do better next time.

How to avoid doing it all

Understanding why this isn't your job, and why the following 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 bit of 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 brittonbroderick@gmail.com.

let img = document.querySelector(".article-image") img.style.paddingRight = "20%"; img.style.paddingLeft = "20%";