top of page

The hidden cost of staying hands-on

  • Writer: Kate Wilson
    Kate Wilson
  • 6 days ago
  • 5 min read

The Engineering Leadership Report 2026 found that 37% of engineering leaders are doing more hands-on technical work than they were a year ago.


In a recent LeadDev article, Engineering managers have a new job description, Ferit Topcu uses the term “player-coach” to describe this changing version of the engineering manager role. Engineering managers are still responsible for the people and team dimensions of the role, but they are increasingly expected to retain technical depth and contribute more directly.


Topcu offers a useful way of deciding when to get involved. Managers can pick up small, unplanned work themselves, investigate complex or unclear problems and leave planned work to the team.


That last distinction is important.


Staying close to the technology is not the same as keeping the most interesting work.


When the boundary begins to shift

There are understandable reasons why engineering managers remain hands-on.


Most moved into leadership because they were good engineers. Technical work is familiar, and the results are often clearer and more immediate than the results of leadership. A prototype works or it does not. A problem gets solved. There is something tangible to point to at the end of the day.


Proof-of-concept work is also interesting. It offers the chance to explore something new without inheriting all the complexity that comes later. For a manager whose days are otherwise filled with meetings, competing priorities and people issues, it may be one of the most enjoyable parts of the role.


They may also believe they are helping. They can get the work done quickly, reduce the risk and keep their technical knowledge current.


None of those choices needs to be unreasonable in isolation. The problem appears when they become a pattern and the manager repeatedly keeps the work containing the most uncertainty, creativity and opportunity.


The team is left delivering the familiar, business-as-usual work, regardless of the experience and capability within it.


This is not about suggesting that routine work is unimportant or beneath more senior engineers. Every team needs people willing to maintain what already exists. But if the developmental work consistently stays with one person, the effects reach beyond the immediate allocation of tasks.


Proximity is not ownership

Topcu argues that managers can build trust by understanding the work in meaningful detail. When they know the system, technical conversations become more useful and problems can surface earlier.


I agree. A manager who understands the reality of the work is better placed to support the team than one who operates entirely at a distance.


But technical proximity does not require the manager to own every important technical task.


They can read the code, pair with someone, investigate a problem, review the thinking or help the team work through difficult decisions. They can remain technically credible without becoming the person who always gets the newest or most visible work.


The distinction is whether their involvement creates more capability around them or replaces it.


The work carries more than the task

A proof of concept is not only an interesting technical problem. It often brings access to new technology, exposure to senior stakeholders and the opportunity to influence future direction.


It is also where people learn to work with ambiguity. They make decisions without having all the information, test assumptions, explain their reasoning and find out what happens next. In other words, it is where they develop judgement.


When a manager repeatedly keeps that work, they are not just deciding who completes a task. They are also influencing who gets the opportunity to learn, be visible and demonstrate their capability.


This is particularly difficult for experienced team members. They may already have the skills to take on more, but find themselves unable to prove it because the opportunities never come their way.


Over time, this can become self-reinforcing.


The manager takes the work because they have the most experience. The team does not get the opportunity to build that experience. When the next piece of work appears, their lack of experience becomes the reason the manager needs to take it again.


The manager becomes increasingly essential, while the team becomes less able to operate without them. It can look like strong technical leadership from the outside, but it is not building capability underneath.


When people stop putting themselves forward

The report also found that 41% of engineering leaders believe their team is less motivated than it was a year ago. The data does not establish a connection with managers becoming more hands-on, but the way work is shared may be one part of the wider picture.


Motivation is often treated as something that sits entirely within the individual. If someone appears less engaged, the assumption may be that they need to become more positive, proactive or ambitious.


But people also respond to the conditions around them.


They may initially put forward ideas, volunteer for more responsibility or ask to become involved. When those attempts repeatedly lead nowhere, they begin to adjust their expectations.


They may continue to deliver the work they are given perfectly well. What changes is their willingness to offer more. They stop suggesting ideas, asking for stretch opportunities or contributing the extra thinking that they no longer believe will lead anywhere.


That does not necessarily mean they have become less capable or ambitious. What looks like a motivation problem may partly be a response to how opportunities for ownership and development have been shared.


Over time, they may decide that the only way to find more interesting work or continue developing is to look elsewhere.


Looking beyond the motivation problem

This matters in coaching because someone may arrive describing a loss of motivation, confidence or direction. It can be tempting to focus immediately on what they need to change.


Perhaps they do need to be clearer about their ambitions or more direct in asking for opportunities. But it is also important to understand the context.


What has changed about the work they are doing? Where are the opportunities to learn and exercise judgement? Have they asked for more ownership, and what happened when they did? Does the way work is allocated match what the organisation says about development and progression?


Coaching is not about persuading someone to feel more positive about a situation that is not working for them. It can help them understand the pattern, test the assumptions they have made about it and decide what they want to do next.


That might mean asking to lead the next proof of concept, taking ownership of the discovery work, presenting a recommendation to stakeholders or agreeing a pairing arrangement in which the manager supports without taking over.


It can also help someone recognise when they have made reasonable attempts to change the situation, and decide for themselves whether staying is still the right choice.


A more useful version of hands-on leadership

Engineering managers do not need to stop being technical. There will be moments when their direct involvement is exactly what the situation needs.


The distinction is whether that involvement is deliberate or simply the default.


Managers can remain close to the work without owning all of it. They can create appropriate checkpoints, review the thinking, pair with someone less experienced or allow another engineer to lead while they provide support.


They can also look across the team and make conscious decisions about who needs the next opportunity, rather than allocating work only on the basis of who can complete it fastest.


Developing someone will rarely be the most efficient option in the short term. If the manager always takes the work because they can do it more quickly, the team never reaches the point where they can do it independently.


The aim is not for engineering managers to leave their technical experience behind. It is for their technical contribution to increase the capability of the team, rather than replace it.

Comments


bottom of page