Should I be coding as a Staff+ engineer?

Is this even the right question?

I have a confession: I don't love coding (anymore). I used to love all aspects of coding when I was doing it day-to-day, even the more mundane tasks, such as refactoring to keep a codebase clean, setting up builds just right to achieve reliable continuous deployment and delivery, or finding and fixing flaky tests. I was also really fast, even if I do say so myself. However, as an architect/tech lead now, I find myself spending more time on design, coordinating across teams and engineers, and only occasionally coding. I still enjoy solving problems with code and get urges to write some, but I find jumping into production-code programming in existing large systems is a frustrating experience. That's not to say the codebases I've worked on are bad; they simply differ from what I'm accustomed to and how I would approach code.

Throughout my time as a staff and staff+ engineer, questions have come and gone about 'Should I be coding'? Phrasing is added to evaluation criteria for performance reviews. The CTO or other senior leadership gives subtle (or not-so-subtle) hints, suggesting that regular coding by all engineers and managers fosters greater empathy for the in-the-trenches engineers.

My initial gut reaction is, 'Why am I being told to code more when I find it less enjoyable?', 'I'm a pretty expensive code monkey.', 'What can I do with this empathy from coding occasionally?'

Generally, if coding ends up in a performance review criteria, complaining is not productive or valuable. Instead, it's better to understand, 'What problem is leadership trying to solve?', 'What don't I like about the request?' then find the middle ground.

What problem is leadership trying to solve?

In short, it is all about being a better translator between leadership and engineers. Gregor Hohpe talks about the 'architect elevator' in his book (and you can easily replace architect with senior engineering IC). In short, our role is to "travel the elevator up and down the org". We take high-level messages from leadership and translate them to specifics for engineers. We also summarise messages from engineering so leadership can understand and avoid getting bogged down in details.

So, by being close to the code, we can:

• Foster stronger relationships with engineers, improving our communication skills. We are fighting in the trenches, not giving orders from afar.

• Better communicate direction (both business and architecture) to engineers. Some engineers need to talk code to understand abstract concepts.

• Surface problems and Keep The Lights On (KTLO) cost to leadership based on first-hand experience.

• Provide better estimates for work to leadership for their planning.

What precisely don't I like about coding now?

After some introspection, my reasons for not loving coding are:

• Being deeply immersed in code requires a different focus from working on multiple projects and is undoubtedly distinct from tackling more strategic problems. i.e. I can't effectively do broad work (as a tech lead) and deep work (as a developer) simultaneously.

• I am more productive and valuable when working on other broad-shaped, ambiguous problems. While there are specific environments where the most challenging issues reside in the code (and I tip my hat to the deep engineers who work on them), most of us don't work in those environments; instead, we focus on more business-oriented problems. i.e. There are coders around who are faster than I now.

• I enjoy working on codebases that align with my coding style (e.g., strong typing, appropriate use of unit vs integration tests, and packaging and modules that match domain-specific needs). Coding 'style' is up to the code owners, and there are limited changes I can make if I'm just dropping into code.

• If I'm writing production code, I should be on call for it. That's challenging as an architect/tech lead spanning multiple teams (which roster am I on?) and is another aspect of focusing deep vs being broad (if I'm on call working in-depth on issues, I can't also focus on strategic or high-level design work).

I'm sure others have different perspectives; these are just my feelings.

What is the middle ground?

I find that I can be a better translator if:

• I understand the system by documenting a domain model in collaboration with engineers, reading design documents, and skimming the code base. Note that it is a smell if I need to read a lot of code to understand the system.

• Pair with engineers on designs, pseudo-coding where necessary. This includes reviewing pull requests that set up frameworks and patterns.

• Observing and asking questions at operational reviews.

In short, I don't need to code to be a better bridge between leadership and engineering. However, to satisfy either my or the company's urge for me to code, I should strategically choose the problems I code on:

• Prototyping to demonstrate the feasibility of an idea or to identify areas of improvement.

• Tooling or infrastructure improvements that help many teams out but aren't owned by a team (and hence are rarely prioritised).

• Specific non-time-critical features that give a sense of the system, i.e. touching or integrating with core components. I don't find much value in working on some random isolated feature or bug fix (except perhaps to avoid unnecessary escalation about why it can't be fixed quickly).

What about vibe coding with AI?

Vibe coding with tools like Cursor is all the rage at the moment. How does this affect whether you should be coding?

It doesn't change any of the arguments I present above, though it does make coding in those strategic areas I suggested much faster. I've found these tools great for prototyping, where I don't care about code quality and need to work with unfamiliar technologies (read: front-end code). They also seem great for navigating large, established codebases and making small and/or well-defined changes that senior engineers have time to work on.

Summary: What value are you bringing to your organisation?

So, if you feel like you're being forced to code, take a step back and find a way to address the root problem of becoming a better translator. You can then have a productive conversation with your manager about what it means to code as a staff+ engineer.