Over the course of my career, I’ve seen new and experienced managers alike share the desire to stay hands on and remain close to the engineering efforts in their team.

While remaining hands-on is naturally tempting, it’s not always the most effective way to leverage a leadership position for the benefit of the whole organization.

The focus of a manager

Engineering manager roles differ across organizations, but  the expectations are consistent: People leadership, custodian of output, and delivery effectiveness.

Your experience and skill can still be effectively leveraged and of value to your team, whilst still not actively involved in the direct writing of code or solving problems. Demonstrate that you understand challenges and restrictions with problems that the team is solving. Highlight potential risks or challenges to them and suggest areas they may wish to look to address, but provide the autonomy and opportunity to do so themselves.

During critical incidents or high priority issues, you can lend your support to triaging or debugging issues. Contribution during critical moments can be effective at building trust in the team.

Focus on the long term technical development of their team by setting clear boundaries on when and how to leverage your experience, without taking over direct involvement.

Your technical experience in influencing and decision making

Being an experienced engineer gives you the ability to guide the team on realistic decision making, timelines, and resourcing allocations. Use your background to ask informed questions or seek additional information on areas you believe have yet to be explored or highlighted. 

Do so in an exploratory fashion, rather than passing judgement on the approach taken. Rather than stating challenges directly like “this solution will fail and put excess load on our services”, reframe it to something more exploratory: “Have we considered load impact and testing?”. 

In certain situations, you may choose to prototype or demonstrate a solution to solving this problem directly in the code base, but this can just as easily be achieved through careful discussion, asking questions, or pointing to available documentation and resources. Doing the latter allows for more self-guided learning and discovery, rather than relying on the manager to show the team the answers.

Mentoring and coaching

One of the most valuable skills an experienced engineer can bring  is shaping the long term career development of the engineers in their team. Speaking the same technical language can help you probe and ask questions about areas they want to develop in, and either provide direct coaching, or point to others within your team or business to pair them with for development opportunities. 

You may decide to actively play the coaching role, pairing with engineers and showing them how to solve problems. Alternatively, a clear sense of how your team members want to progress and the possible development opportunities allows you to create moments where engineers demonstrate their understanding of new skills. 

Recognizing when to step back

If you do decide to remain hands-on, there are several scenarios where you should assess if the balance of your technical contribution is the right thing for the long term health and development of the team. 

1. You’re at risk of being a single point of failure

If you possess specific knowledge of a system or process, and have been using your expertise to address this, you must recognize the need to scale yourself and ensure that this knowledge is more evenly distributed across the team. 

A core responsibility of leaders is  ensuring the long term success of the team. Being a single point of failure increases the dependency on you to solve critical issues. Taking the time to upskill, document, and transfer that knowledge allows the risk to be shared. In transitioning knowledge, you are allowing the team to solve their own issues more proactively, or suggest alternative approaches to a problem.

2. Your involvement starts to limit opportunities for growth

Be conscious of the work that you’re doing. Taking tasks that are seen as ‘very complex’ or technical can give the impression that this work isn’t available for others to do, and work that could be vital to their own progression or career development. While taking on complex tasks may feel you’re helping the team, gate-keeping this work can hinder team progression and development opportunities. 

3. Your hands on work puts you at risk of burnout

During critical projects, it can be tempting to lean in and be the extra pair of hands the team needs. But, this needs to be recognized as a short term fix. 

We often only recognize the additional strain this puts on a manager until the burnout has happened. If you do decide to take this step, ensure it’s timeboxed and you recognize how and when to step back into the support role. 

Communicate your involvement clearly to the team and take their input on which tasks require the most support. Be mindful of how you position your desire to help – make sure to avoid this being seen as a comment on their ability to do this work themselves.

Stay involved

I’ve previously written about how managers can stay involved in the engineering effort in their team whilst avoiding some of the common pitfalls of micromanagement.

From participating in technical conversations, supporting code reviews, or 1:1s, there are many ways in which you can leverage your technical background and interest to support the team that doesn’t rely on you being directly involved in the writing of code.

Final thoughts

Managers will have to decide for themselves which approach is right based on team composition or urgency of issue, and making sure you find the right balance is a continuous process. 

Finally, think about how your own skills contribute to the output of the team. I lead many cross functional teams, and try to set the expectation that being hands on across a variety of areas isn’t feasible. Leadership skills involve guiding the team, focusing on the quality of output, and streamlining processes. That can be far more effective than writing any lines of code.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.