Should Engineering Leaders Still Code?

Should I still be coding as an engineering manager, director, VP, or CTO?

This is one of the questions I’ve been asked most often throughout my journey in engineering leadership. It surfaces in day-to-day conversations, coaching sessions, and discussions with other engineering leaders. My answer has always been the same: Yes, but not in the critical path. It’s an interesting debate, especially now that engineering managers are getting back into the codebase.

I was recently sent a report by a leadership coach that explored this question in considerable detail. There were disagreements across the spectrum about what it takes to remain technically relevant, and that term struck a chord with me.

When you look at other professions where individuals spend considerable time mastering their craft before moving into management or leadership, their responsibilities almost always change. However, they generally retain a fair degree of understanding and mastery of the work itself.

Software development is somewhat different, because the field morphs and transforms so much. An engineer who worked with a particular stack 20 years ago would have to relearn a considerable amount to work with many of today’s technologies. Even something as simple as taking an application to production looks very different now.

Technical relevance has an expiration date

I’m one of those engineers.

I started working with code around 2006–2007. The world back then was very different. I wasn’t working professionally as a software developer yet, but I was a hobby programmer, tinkering with Cisco switches, setting up Apache web servers, and configuring cPanel hosting solutions.

All of this seems rather archaic to me today.

The stack has evolved. Whether that’s always been for the better is a question for another day. We’ve started creating increasingly complex systems as the problems we’re trying to solve have become more layered, and the solutions have had to catch up.

Gergely Orosz recently explored what happens to software engineering when AI writes almost all the code. It’s another reminder that the tools change, but the need for engineering judgment doesn’t disappear. A developer who has worked for the last 20 years and navigated several generations of technology has had to continuously learn, adapt, and occasionally unlearn things.

Of course, there are different profiles of engineers. There are developers who have spent decades maintaining Oracle systems and other critical infrastructure, keeping our banks and other essential services running. But there are also those working in what we call high-tech, where the technologies, practices, and expectations can change dramatically within a few years.

For engineering leaders, this creates an interesting challenge.

If your main responsibility is to influence, inspire, and guide groups of software developers towards a shared goal, you need the technical acumen and judgment that this constantly evolving ecosystem requires.

You cannot rely entirely on the technical knowledge you accumulated before moving into leadership.

What does good engineering look like?

In my opinion, if you want to be a good and effective engineering leader, you need to understand what good looks like across the work your teams do.

What does good look like when a group of engineers uses coding agents to write software? What does good troubleshooting and incident management look like? How do we build the right thing quickly, collect feedback, and expose that feedback to the people making decisions? How do we know whether we’re deploying software in a safe and sustainable way?

All of this requires an understanding of the tools, practices, and environments your teams work with.

That doesn’t mean you need to be the best engineer in every room, or an expert in every language and framework. But you need enough technical depth to understand the decisions being made, challenge assumptions, recognize trade-offs, and know when to trust the specialists around you.

You also need to understand what you don’t know.

And that understanding is difficult to maintain if you’re completely disconnected from the work itself.

Could you work as a junior developer on your own team?

We all have our own ways of learning. Some learn by reading, others by listening, watching, or doing.

I, for one, learn by doing.

Even now, I’m thinking as I’m writing this article. I need to engage with something actively for it to register. I also have a fairly short attention span, so the act of doing something while learning helps me stay focused.

When it comes to understanding engineering systems, reading architecture documents or listening to someone explain a codebase only gets me so far. I need to get my hands on the tools, run the application, understand how things fit together, and experience the development process myself.

This brings me to a test I’ve used for myself:

Could I spend a month working as a reasonably competent junior developer on one of my own teams?

Not as the leader. Not making architectural decisions. Not telling everyone how things should be done.

Just joining the team, understanding the development environment, picking up relatively simple tasks, and contributing like any other engineer.

If the answer is no, then I probably don’t understand the environment well enough to lead it effectively.

It doesn’t mean I need to know every detail of the system, or that I could replace the engineers who have spent years building it. But it gives me a reasonable benchmark for whether I’m sufficiently familiar with the work.

It also tells me something about the cognitive load on the team.

If an experienced engineer needs weeks just to get a development environment running, understand the dependencies, and make a small change, that tells me something important about the system we’ve built and the experience of the engineers maintaining it.

In my last role, I was responsible for an engineering organization of around 100 people maintaining Windows, macOS, iOS, and Android applications, several web applications, a browser extension, and some substantial Java, Python, F#, and Go services.

One of the first things I did was invest time in understanding how these different stacks worked.

I didn’t jump in and start contributing to production code. Instead, I spent time with the teams, effectively onboarding as a junior developer and understanding their environments.

And I didn’t do this all at once.

I spread it over six or seven months, digging into different areas as the work demanded it. Sometimes I needed to understand a release process. Sometimes I wanted to understand a technical decision, a recurring problem, or why a particular change was taking longer than expected.

The goal wasn’t to become proficient in every codebase. That would have been unrealistic.

The goal was to understand enough to ask better questions, recognise problems, and make better decisions.

Of course, the test scales differently for an organisation’s size. A CTO in a 5000 people org doesn’t need hands-on familiarity with every repository; they do need a credible method for understanding technical reality through their leaders and engineers.

Coding agents change the equation

I’ve written before about why AI hasn’t changed everything yet. One of the biggest challenges remains understanding where work belongs in increasingly complex systems.

With coding agents becoming increasingly capable, I believe this technical familiarity is becoming even more important for engineering leaders, not less.

Some software can now be written largely by agents. Straightforward, well-understood functionality, routine implementation work, and tasks with clear requirements and boundaries are increasingly good candidates for delegation.

Other work requires considerably more human judgment.

Architecture, complex trade-offs, decisions involving security or reliability, and choices that affect the long-term maintainability of a system require a deeper understanding of the problem and its consequences.

The distinction isn’t always as simple as CRUD versus complex software. Even reviewing AI-generated code requires understanding the requirements, architecture, security implications, and long-term maintainability. A relatively straightforward feature can have serious consequences if it touches sensitive data or critical infrastructure.

Martin Fowler makes an interesting distinction between agentic engineering and vibe coding. Generating code and understanding the software being built are not the same thing.

But the important question is: How do you know which work can be delegated to agents and which work needs greater human involvement? I think that’s increasingly becoming a leadership decision.

This is consistent with DORA’s research on AI-assisted software development, which suggests that AI tends to amplify an organization’s existing strengths and weaknesses.

You need to understand your stack, your codebase, and the capabilities and limitations of the tools your teams are using. Otherwise, how do you make informed decisions about where to invest engineering resources? How do you know whether a team needs another engineer, better tooling, a different architecture, or simply a better way of using the tools already available?

You can’t make these decisions effectively if you’ve become completely detached from the technology.

And coding agents offer another interesting opportunity. They make it easier for engineering leaders to explore codebases, understand unfamiliar technologies, and experiment with ideas without necessarily becoming responsible for delivering production features.

So I don’t necessarily see getting closer to the code as taking time away from leadership.

I see it as an increasingly important part of it.

Write code, but don’t become the critical path

There is, however, an important distinction between understanding the work and becoming responsible for delivering it.

If you’re a VP of Engineering contributing to a service, it doesn’t automatically mean you’re helping your team or that you’re somehow in the trenches. This is not war. And honestly, we should probably stop using war analogies to describe one of the least physically demanding professions around.

Sometimes, by inserting yourself into the implementation, you’re actually preventing your team from developing the skills and confidence to do the work independently. You might also be creating dependencies on yourself, confusing ownership, or becoming a bottleneck in decisions that your engineers should be making.

I think this is where ego can get in the way.

As engineering leaders, many of us spent years developing our technical abilities before moving into leadership. Writing code is familiar, tangible, and often more immediately rewarding than navigating organisational dynamics, resolving ambiguity, or helping people grow.

It’s tempting to return to the things we know we’re good at.

And with coding agents making it easier to write software, that temptation might become even stronger.

But your job as a leader isn’t to prove that you can still write good software. It’s to create an environment where your teams can consistently build good software without depending on you.

That requires knowing when to get involved and, perhaps more importantly, when to get out of the way.

You should understand which decisions need the collective judgment of a group, which can be made independently, and which are premature because the idea or the problem hasn’t developed enough yet.

You should understand the code, the tools, and the environment your engineers work in.

And if writing code helps you develop that understanding, then by all means, write code.

Just don’t let your ego put you in the critical path.

I’d be happy to hear what you think about this. I don’t have comments enabled on my blog, but I tend to prefer Hacker News for these kinds of discussions. If you have thoughts or disagree, I’d be interested to hear them.