Dirty hands, full hands
“If you do not climb a high mountain, you will not know the height of Heaven.” — Xunzi
A conversation with one of my clients went something like this:
Me: Have you worked on the internal process redesign and automation we discussed two weeks ago?
Client: Nah, we had some rapid fire that ate all my time.
Me: Was there no one else who could have solved it?
Client: Yeah, maybe, but... They would’ve been slower and we needed to act fast.
It was a reasonable answer. There had been a problem, somebody needed to solve it, and my client knew how. Handing it to someone else would have required explanation, supervision, and the patience to watch them move more slowly. In the moment, doing it personally was the fastest and safest option.
Meanwhile, the internal redesign intended to reduce exactly this kind of operational pressure remained untouched. The urgent work won, and the work that might have prevented future urgency lost. Again.
I see versions of this pattern often in my coaching work. Leaders are expected to build strategy, improve systems, and develop the organization around them. Yet their days fill with operational problems they can solve more quickly than anyone else. The immediate work offers completion and visible progress. Strategy is foggy. Delegation creates more work before it creates less, which feels impossible under the current (and constant!) time pressure. Recently, I started noticing the same pattern in a growing debate about engineering management.
The same trap, wearing engineering clothes
At the Craft Conference in Budapest this June, I heard versions of the argument that engineering managers should do less people work, become more technical and deliver like everyone else in their teams. Engineering managers have also told me privately that upper management is pushing them in this direction.
“More technical” can mean different things, but sometimes it is very literal: write code, review pull requests, and personally contribute to delivery. With agentic coding, the expectation can become even broader. Managers should help their teams develop a new way of working with agents, understand the technology, guide the transition, and also use the tools to deliver more themselves.
I think the rationale is valid. A manager cannot guide an agentic transformation entirely from a slide deck. They need enough direct experience to understand what changes when agents enter the workflow, where the apparent speed is misleading, what new review burden appears, and which skills the team needs to develop. Getting your hands dirty can be an important part of learning. It is simply not the full picture. Dirty hands help you understand the work; keeping them permanently full may stop you from doing your own.
Technical ≠ producing code
When I hear that engineering managers should become “more technical,” my first question is what technical means. In many EM roles, technical judgment never disappeared. It shows up when the manager understands the architecture well enough to notice a risk being waved away, understands users well enough to ask the question that improves a decision, or translates an engineering concern into consequences the business understands. None of this produces a commit with the manager’s name on it.
Coding and code review may be part of the role, too. A young team without experienced technical leadership may need more direct guidance. A mature team, on the other hand, may need the manager to stay close enough to understand the tradeoffs without taking the decision away from the people making it. An incident can change the equation again. There is no single correct mixture hiding inside the word “technical.”
Why the concrete work keeps winning
Many companies seem to be in productivity fever, chasing the beloved 10x improvement that appears whenever ordinary ambition is no longer exciting enough. I have written before about the problem with confusing output value and productivity. AI reduces the cost of producing things. It does not automatically reduce the cost of coordination, judgment, or maintaining whatever we produced so enthusiastically.
I see why this looks attractive from higher up. When agents speed up production in the middle of this productivity fever, asking everyone — including managers — to contribute directly seems like an obvious way to capture more output. The part I think we are undercounting is the work that never becomes a satisfying spike on the dashboards: a conflict that did not escalate or the changing role that became clearer after several conversations. We tend to notice this work only after it has not happened for long enough.
Even if agent-heavy organizations eventually need fewer people or different management structures, the transition is happening through humans facing changing roles, pressure to learn, and uncertainty about their future. This may actually require more leadership attention, not less. And that does not mean defending every management activity currently on the calendar. Some status meetings and approval rituals deserve to disappear. I would happily help them pack. The question is whether we are removing management theatre or the work through which people find clarity and enough support to adapt.
The organization supplies only one side of the pull. Technical and operational work can feel wonderfully concrete, particularly for managers who built their careers through technical expertise. A bug is fixed. A pull request is reviewed. At least something happened. The code may be difficult, but it is difficult in a language they trust. People and organizational work rarely behaves so politely. A difficult conversation may create more uncertainty before it creates less. Strategy can consume an afternoon and leave behind three arrows on a whiteboard and a vague concern that one of them is pointing the wrong way.
This is where the two pressures become uncomfortably cooperative. The company asks for visible technical contribution, and the manager has a legitimate reason to return to work that feels like home. One extra review here, one urgent task there. The difficult conversation moves to next week. The strategy work waits for the mythical afternoon without interruptions. Nobody needs to decide that management no longer matters. It simply keeps losing these smaller battles.
This also creates what I think of as context switching squared. Writing code and managing operate at different altitudes. Deep technical work requires continuity; management is interruption-rich and concerned with the conditions around the work. Moving between them is possible, but expensive. When the manager is pulled away from code, somebody still owns the half-finished thought, the review waiting for attention, or the technical decision dependent on their availability.
Before stepping in, ask yourself
When technical involvement is becoming part of the role, I think three questions can help managers distinguish a useful intervention from a drift in the wrong direction.
What problem am I solving?
Sometimes the answer is clear. You need direct experience with an agentic workflow before deciding how the team should use it. A design carries serious organizational risk and you need to understand the tradeoff well enough to support the decision. The team has a temporary capability gap, and your involvement can unblock learning.
But sometimes the technical task is solving a different problem: the need to demonstrate relevance, respond to an undefined expectation from above, or escape a management problem whose progress is difficult to see. The task may still be useful, but let’s be honest about which need is driving it.
Why me, and for how long?
Do you have context, authority, or capability that nobody else currently has? Or are you taking the work because you can complete it faster?
“They would be slower” is useful information, but it is not automatically a reason to keep the task. Someone learning will often be slower. Delegation has an upfront cost, especially when the manager has spent years becoming unusually efficient at rescuing the system from the dependency built around them.
There are moments when speed genuinely matters. When the house is on fire, protecting customers may be more important than creating the ideal learning opportunity. The problem begins when every deadline is treated like a wildfire, and the exception becomes the operating model.
A time-boxed experiment can be a sensible way to understand agentic coding. Reviewing a critical design or temporarily helping with a capability gap may be exactly the right contribution. Repeatedly owning critical-path features creates a different dynamic: the manager becomes a delivery dependency while still being expected to manage the dependencies around everybody else.
The difference is rarely visible in one task. It appears in repetition. Who owns the work after a month? Who is waiting for whose decision? Can you step away without slowing the team?
What am I displacing?
Managerial work does not disappear while the manager codes. It waits, usually inside other people. The one-to-one still needs attention. The vague performance concern is still becoming a pattern. The hiring decision remains unresolved. The team still lacks clarity about who owns what. The strategic question is still sitting in a document nobody wants to open because it contains no satisfying checkbox.
Before accepting technical work, name the price: what will move and what will be dropped.
Have the role conversation
These questions can help managers examine their own choices. They cannot resolve a contradiction created by the role itself. Managers should not be expected to privately absorb an impossible combination and then improve their time management until physics becomes more cooperative. If technical delivery is being added from above, the tradeoff needs to become part of the conversation with upper management.
That conversation needs to become concrete:
What outcome are we actually seeking: technical learning, better decisions, code production, or delivery ownership?
Is this a temporary intervention or part of the permanent role?
What existing responsibility will be reduced or removed, and who will own the work that remains?
How will success be evaluated beyond visible personal output?
These are not defensive questions. They are role-design questions. “Do more of everything” is not a role design. It is a wish made standing in front of a whiteboard.
Managers also need to be willing to challenge their own answers. It is easy to say that leadership work is essential while spending half the week in meetings that could have been an email, or perhaps a brief moment of collective silence. Protecting people management does not mean protecting every activity historically performed by a manager. It means being clear about the outcomes the organization still needs and who will create them.
The work still waits
My client probably did solve the urgent problem faster. I did not challenge that part. What stayed with me was the price: two weeks later, the redesign intended to reduce the recurring pressure had not moved. The one-time rescue worked. It also kept the need for another one-time rescue firmly in place.
An engineering manager may be exactly the right person to write some code, review a difficult change, or explore a new tool deeply enough to understand it. The technical task is not automatically the problem. The question is what had to wait for it — and whether the team will need the manager in the same place again next week. Adding technical delivery without removing anything is not a role redesign. It simply makes the role less possible.
Because the people work waits too. Someone continues working with an expectation nobody has clarified, or carrying ownership nobody has properly assigned. These problems rarely send a notification while they are still cheap to address. By the time they demand the manager’s attention, they are usually no longer small.
Food for Thought
What technical work do you need to experience directly in order to lead it well?
What work do you keep because other people would initially be slower?
Which leadership responsibility has no clear owner while you deliver?
If more technical delivery has been added to your role, what has explicitly been removed?
I would love to hear about your personal experiences.