Why would you want your engineers to become leaders?

Managing a team of just a few engineers and their output should be easy. You can go deep into the details of solutions and still keep a good high-level overview of everything that’s happening now and should happen in the future.

But what happens if that team grows to 20 engineers? What if the engineering department grows to a department with multiple teams responsible for different domains? The way you used to work can’t scale indefinitely, so you need to find a way to spread your workload.

Since cloning yourself is probably not an option, you will need to delegate some of the work you used to do. As a technical leader or CTO, keeping a bird’s eye view is important. Diving into the details of solutions… not so much. So how do we delegate that part of the job?

In terms of taking responsibility for a feature to be developed from start to finish, it would be great if that could be done by team members. For the goal of this blog, we’ll assume that the scope of the feature has been defined and validated by the one(s) responsible for the product development process.

Reading tip: seniority levels in software development explained

Will the real leader please stand up!

Start by having a conversation with your team and figure out who would like to be responsible for delivering the next feature. Don’t worry yet about their seniority, maturity, years of experience, etc. Being motivated to take this responsibility will be the most important aspect. Tell them they will not be left on their own and that you will be there the entire time to support them in any aspect of the project. Already having a high level of psychological safety within your team will be a big benefit here.

As a team, you agreed on who will be the first member to take the lead for the next feature. Start by setting clear, binary goals. Share the expectations you have for this process without filling in the details. They are in the lead; you are there to support. They should be able to clearly see what the end goal looks like. That was already defined by the product design team. The road towards it can still be vague. That’s something you will define together as you’re moving forward.

If you want to go fast, go alone. If you want to go far, go together.

Let’s explore some of the ways how you as a leader can support one of your engineers taking the lead in bringing a feature to life.

Talk about how much support your new leader expects from you and in what way. It could be that they want a quick check-in via video call every day to discuss progress and next steps. This keeps the feedback loop short and creates the space to help with every step. This will organically evolve into becoming a less frequent check-in until they’re on their own and just ping you when advice is needed. This is a very synchronous way of working with face-to-face feedback. If you need a more asynchronous way of working because of less compatible working schedules, you can exchange the video calls with written updates about progress and next steps. Don’t install too heavy of a process from the start — make it flexible enough so you can adapt the process whenever needed.

It could also mean you sit together for some parts of this journey. Maybe you can analyse a feature together so that they can learn from how you approach this. Or you could pair up to figure out the high-level decisions that are needed when developing this feature. In any case, it’s important that you take the role of navigator more than the role of driver. We have written some articles on this topic:

Leading the development of a feature does not mean they have to work alone. It means taking the responsibility to deliver the feature within the parameters you have set together. That most likely includes:

  • Knowing every detail of the feature’s scope
  • Doing some upfront research or analysis
  • Including other disciplines (UX, UI, QA, etc.) when needed
  • Taking decisions on the technical implementation

What’s next?

For simplicity’s sake, our examples assume a pretty linear process in which the product work has been finished before development starts. A more advanced version of this could be that you assign a multi-disciplinary team to the development of a feature. This means you include the engineer early on in the product development process and keep including the product manager throughout the development process. Ideally, this requires T-shaped people who can cross disciplines to collaborate towards the best possible solution. We also explain the t-shaped profile in this post.

In our example, we challenge you to take the lead and coach other engineers. In a bigger organization, you might coach your more senior engineers to help mold new leaders from your junior engineers. Whatever the setup, leading by example will pay dividends if done correctly. Good luck!