Senior Engineers Spend Less Time Coding

Dev Leader Weekly 118

Dec 06, 2025

TL; DR:

You WILL spend more time on other things now
... Coding time WON’T be zero!
Check out the livestream (or watch the recording) on Monday, December 8th at 7:00 PM Pacific!

Why Senior Engineers Spend Less Time Coding

If you’re early in your software engineering career, you might imagine that the higher you climb, the more complex code you’ll write. The gnarlier the systems, the more interesting the technical challenges, the deeper the architecture.

And yes, the complexity does increase… But the amount of time you spend writing actual code?

That almost always goes down. Well, at least proportionally to some of the other things you’re going to be doing in your role.

Recently, I talked about this on Code Commute in response to a Reddit post. A senior developer said that for the past few weeks, they’d only written a handful of trivial code changes and spent the majority of their time writing docs. They understood that senior roles come with non-coding responsibilities, but they were starting to feel like something was off. You can see my thoughts on this here:

Here’s the thing: They’re not wrong to question it. There is a shift in responsibilities as you grow more senior, but it shouldn’t turn you into a full-time document factory either.

Let’s dig into why this shift happens, what the healthy version looks like, and where things can quietly go off the rails.

The Senior Engineer Responsibility Shift

As you move toward senior, staff, and principal levels, your impact is less about your individual code output and more about how you influence systems, teams, and direction.

That means your responsibilities expand into areas like:

Mentorship and developing others
Aligning architectural decisions
Coordinating across teams
Creating clarity in ambiguous spaces
Designing systems before they exist
Writing documents that help others move in the right direction

None of that is specifically coding.

And that’s the point. Your company is paying you for your thinking, judgment, and ability to guide others -- not just your keystrokes.

But here’s the nuance: Your coding time decreases, but it shouldn’t disappear.

When someone says, “If I’m writing code as a staff engineer, I’m the bottleneck,” my reaction is pretty simple:

I don’t buy that -- at least not without a lot more context.

If my principal engineers weren’t writing code at all, we’d have a major problem. Leadership still requires technical depth. It is much more difficult to meaningfully influence architecture or design if you’re never hands-on with the system.

So yes, the ratio of coding to non-coding shifts. But it’s not supposed to flip to 100% non-coding.

When the Balance Feels Wrong

The story that kicked this off involved a senior engineer doing:

Weeks of document writing
Only a few trivial PRs
Virtually zero meaningful coding
Lots of back-and-forth with reviewers
A cycle that dragged on and on

This can happen, but it isn’t automatically normal.

A month spent on a technical document can be reasonable for huge initiatives, but in most cases, it signals inefficiencies.

Where do these inefficiencies come from?

1. A lack of early alignment

If stakeholders aren’t on the same page before deep technical docs get written, the feedback cycle becomes endless.

A 30-minute meeting with a one-page outline could avoid weeks of pointless rewrites. This is especially painful when you’re getting conflicting feedback.

2. Reviewers responding at wildly different speeds

You get feedback from two people right away. You wait days for a third. A week goes by before the last person replies.

Suddenly, the entire design doc timeline is dictated by the slowest responder.

And this same pattern destroys productivity in code reviews:

“I’m blocked waiting for so-and-so to review my PR.”
“They haven’t responded in a week.”

This isn’t a single person’s fault -- often they’re overloaded, or juggling unrelated priorities. But the system is flawed if one person’s delay pauses everyone else.

3. Over-documentation

This might sound spicy, but here we go: Some teams write way too many documents.

I don’t mean architecture docs are bad. They’re essential in many situations.

But I do question whether every decision needs a multi-page document, rounds of comments, and heavy asynchronous debate.

Sometimes, a 20-minute conversation clears more ambiguity than a two-week doc review cycle.

This is probably my startup background showing. My bias is toward action and discussion over polished artifacts. Big tech tends to bias toward writing. The truth usually sits somewhere in the middle.

4. Processes growing without intention

Teams often adopt tools or workflows that accumulate overhead over time:

Too many reviewers
Too many required documents
Too much async back-and-forth
Too little synchronous communication

None of this is malicious.
It just slowly expands until it becomes normal.

But when seniors start doing only coordination work, something needs to be recalibrated.

Coding Still Matters -- Especially for Senior Engineers

There’s a misconception that senior and staff engineers should move away from coding entirely.

Wrong.

Without some significant regular coding, it is very difficult to:

Lead technical and architectural strategy for your product/service
Mentor others on technical aspects effectively
Deeply understand real system constraints required in your role

The further you drift away from implementation, the more disconnected your decisions become.

I say this as an engineering manager who does NOT write code for the systems by teams build. I focus on things at a much higher level, but by doing this:

I may never understand the code as deeply as engineers on the team
I may never understand the tech debt and architectural drift as well as engineers on the team
... I will always rely on the engineers on my team to help influence and drive important technical decisions.

It doesn’t mean I don’t play a part in that, but it means I’m not making those decisions in a vacuum.

Coding is not the only way you provide value, but it is a necessary part of staying grounded technically.

So if you’re a senior engineer who enjoys coding and you suddenly find yourself writing zero code for long stretches?

Yes -- it’s worth raising the concern.

Healthy Senior Engineer Work Mix

A reasonable mix (varies by team, scope, and company) might look like:

30–60% coding (complex features, prototypes, high-impact work)
20–40% design + documentation
10–30% mentorship + collaboration
10–20% cross-team alignment, reviews, planning

Does this shift depending on the quarter, project, or initiative? Absolutely.

Do those numbers add up to 100% if you take all the mins or all the maxes? Absolutely not.

Will these change for the same person depending on their active projects? Absolutely.

Is this a perfect mix that applies to everyone? Absolutely not.

But if coding has dropped below ~10% for long periods and you don’t want it to, there’s likely a systemic issue worth addressing.

When You Should Speak Up

You should raise the concern if:

You’re doing endless document cycles without progress
You’re being pulled into too many planning or alignment tasks
You feel like you’re drifting away from technical depth
You’re losing excitement or engagement because you’re not coding
You’re being treated like a project manager instead of an engineer

This isn’t about complaining. It’s about protecting your long-term effectiveness.

Good engineering managers want their senior engineers to be able to focus their time.

A Final Thought

As you become more senior, you will spend more time doing things that are not coding:

Writing docs
Designing systems
Unblocking others
Aligning teams
Mentoring
Facilitating clarity

That’s normal. That’s part of the growth path.

But when the balance tips too far, when you’re spending all of your time in docs and none of your time engineering, that’s a sign to pause and reflect.

Not because writing docs is bad.
Not because alignment isn’t important.
But because senior engineers still need to build.

Your impact expands, but your technical foundation must remain strong.

If you find yourself drifting too far from coding, don’t ignore the feeling. It’s often the first signal that something in the system -- not you -- needs adjustment.

Dev Leader Weekly

Discussion about this post

Ready for more?