When You’re Expected to Lead and Still Do the Work

There’s a version of leadership development advice that goes something like this: the sooner you stop doing the work and focus entirely on leading others, the better. Hand things over, step back, trust your team, and measure your success through what your people produce rather than what you produce yourself.

It is good advice. It’s advice I give myself. For a lot of managers, it is exactly what they need to hear.

But… it assumes that the manager’s job is to manage, full stop. And that staying close to the technical work is a habit to break rather than a responsibility to balance.

For a lot of tech managers, that assumption isn’t quite right.

In many tech teams, especially in smaller companies or fast-growing ones, the expectation is not that the manager steps away from the technical work entirely. The expectation is that they do both.

They review code, contribute to architecture decisions, pick up tickets when the team is stretched, and stay close enough to the work to be useful when something goes wrong. This isn’t a failure to transition into leadership. It is the job as it has actually been defined.

If anything, that expectation is growing. With AI tools making it easier for managers to contribute technically again, some teams that had drifted toward more hands-off leadership are finding themselves pulled back toward a player-manager model. Whether that is a good thing is a separate question. But it means the advice to simply stop doing the work and start leading fits the reality of fewer and fewer tech managers, not more.

The problem isn’t staying hands-on. The problem is what tends to happen over time when the line between doing and leading starts to blur.

When a manager is expected to contribute technically, there is always a legitimate reason to spend another hour on a technical problem. The pull toward that work is strong, and the justification is always available. This is the work, this is part of the job.

And it is. Up to a point.

What many managers find, sometimes only in hindsight, is that the doing gradually crowded out the leading. It’s not all at once, and never because of one big decision, but gradually, one reasonable choice at a time.

The 1:1s got shorter or less frequent because there was a deadline, a difficult conversation got postponed because there was a deployment, and the time that was supposed to go on thinking about the team’s direction went instead on a technical problem that was urgent and concrete and, frankly, more satisfying to work through.

This isn’t laziness or a lack of care about leadership. It’s almost the opposite. It happens to managers who are conscientious, who want to be useful, who find it genuinely uncomfortable to feel like they are not contributing tangibly.

I recognise it because it happened to me.

For most of my career, contributing technically was how I knew I was doing a good job. It was tangible, immediate and honest. Either the thing worked or it didn’t. The problem was solved or it wasn’t. There was no ambiguity.

Leadership is different. A conversation with a struggling team member might not show any visible result for weeks. Thinking carefully about team dynamics, or about how to structure work so that two people who don’t quite gel don’t end up on the same project, produces nothing you can point to. A good day of leadership can look, from the outside, like nothing much happened.

So when I was expected to keep doing some of the technical work as well as leading the team, I gravitated toward the technical work. I wasn’t trying to avoid my leadership responsibilities. But the tech work was familiar. It gave me something concrete to show for the day. And the leadership work felt uncertain and slow in a way that the technical work didn’t.

The leading got done, but it got the time and attention that was left over. Which was rarely enough.

If you’re in a hybrid role, the useful question isn’t whether you should step away from the technical work entirely. In many cases, you shouldn’t. Your team may need you to stay close to it.

The question is whether you are making a deliberate choice about where you spend your time, or whether the doing is simply winning by default because it is easier to justify, more immediately satisfying and less uncomfortable than the leadership work.

Those are different situations, and they need different responses.

If you are staying technical because it genuinely adds value, because you are making conscious decisions about which problems need your involvement and which ones don’t, that’s a legitimate way to work. The goal is not to become a manager who never touches the work. It is to be intentional about it.

If you are staying technical because the leadership side of the job is harder and less rewarding and you have a reasonable excuse to avoid it, that is worth being honest with yourself about. The team is still being managed, but probably not as well as it could be.

The difference between those two things is not always obvious from the inside. But it tends to show up in where your team’s problems are. If the technical work is going well and the people side keeps throwing up issues that never quite get addressed, that is usually a sign.

It does not mean scheduling every hour or applying some fixed ratio of doing to leading.

It means occasionally stepping back and asking an honest question about where your time has actually been going, and whether that reflects a genuine choice or just the path of least resistance.

It means noticing when a technical problem is pulling you in because you genuinely need to be involved, and when it is pulling you in because the alternative is a conversation you have been putting off.

It means recognising that the leadership work, the slow, less tangible, harder to measure work, is not less important because it is less visible. It is often more important. It just does not feel that way in the moment.

The hybrid role is not a problem to be solved. But it does require more self-awareness than a role where the boundaries are clearer. The doing will always be there. The question is whether the leading gets the same chance.

For a lot of tech managers, doing both is simply the job. The question isn’t whether you should be hands-on. It’s whether you’re choosing where to be hands-on, or whether you’re defaulting to it because it’s comfortable.

The doing will always feel more immediate. The leading will always be harder to see. Being aware of that gap is usually enough to start closing it.

The balance between staying technical and leading your team is something that comes up regularly in my work with tech managers. If it’s something you’re navigating, you might find it useful to read more about leadership coaching, or about why high performers often struggle when they move into management.