A note on leading teams

2 minute read

bike on empty road

Making the jump from developer to Technical Lead is intense. For me, it was a total trial by fire - From one day to the next, I suddenly became responsible for a team of 8 developers.

Truth be told I was 100% making it up as I went along - some of what I did worked, and some of it totally fell flat. With the benefit of hindsight, I thought I would write down some of what I learned.

Your team’s wellbeing is your primary responsibility

Your job is to enable your team to do their best work. This entails primarily:

  1. Increasing their happiness. This means giving them time to implement the right solutions, but also taking time as a team to hammer our problems and creating a framework for distributing workloads - silos of knowledge are a killer of productivity AND happiness.
  2. Allow them to focus on code quality. Yes, sometimes you have to compromise here, but it shouldn’t be your default position to get something delivered because of a business deadline. Learn to work with the product manager to shuffle things around and re-prioritise constantly.
  3. Increasing their productivity by creating a distraction-free environment. Keep team meetings to a minimum, don’t accept ad-hoc requests for work into a sprint, and don’t allow external stakeholders to define individual team members’ backlogs.
  4. Holding regular sprint meetings - standups, planning and retro - at pre-defined times. Predictability means a team member can plan their work accordingly.

Your job is all about managing relationships

Yes, your title might be Technical Lead, but 95% of your job is going to be about ensuring the relationship between you and your team, you and your Product Manager, you and your manager, and crucially, between your team and the rest of the business are running as smoothly as possible.

You technical contribution will be significantly reduced

Your job is to understand the big picture architecture, and communicate that to your team in a way that enables them to deliver. You will probably have plenty of opportunity to write code, but most of it will be low-hanging fruit and bugs. Your ability to go in-depth on a technical problem will be vastly reduced.

Be a knower of people, not a knower of things

There’s no way you’ll be able to understand your entire problem space. Instead, make it your job to know which team member is well versed with which areas. When someone asks you a question you can’t answer, you should be able to point them at the person who does.

Be prepared to answer the same question over and over again

It’s part of the job. If you find the same question gets asked many times, consider putting together architecture diagrams or documentation that you can quickly refer people to.

Understand and maintain the roadmap - Always

Priorities are constantly shifting, and only by understanding the roadmap will you be able to see where you can move things around. You also need to be able to communicate this to your team, so that they understand how their work contributes to the bigger picture.


There’s loads more to write on this topic, in particular around how an effective team dynamic doesn’t just spring up overnight - it takes lots of iteration and hard work - but I’ll leave that for another post.

Updated: