At some point, many senior engineers quietly transition from building things to managing the building of things. This transition is often presented as growth. Sometimes it is. Often it is the beginning of a slow professional collapse.
There is a career transition that happens quietly, usually between
year five and year ten of an engineering career, that nobody talks
about honestly.
The engineer starts getting pulled into more meetings. Their opinions
are sought on architecture decisions. They review more code than they
write. They spend increasing amounts of time on documents, on planning,
on the work of coordination rather than the work of building. Their
title changes. Their calendar fills up. Their pull request count drops
toward zero.
Everyone calls this growth. The engineer accepts that framing because
it comes with a raise and an increased sense of importance. The team
benefits because the engineer's experience is now multiplicative rather
than additive. The organisation is satisfied because the senior
headcount is being leveraged correctly.
And then, two or three years later, the engineer sits down to build
something and discovers that they cannot. The tools have moved on.
The frameworks they knew have been superseded. The muscle memory
of debugging and building and shipping is gone. They know what good
looks like but they have lost the ability to produce it directly.
They have become, without intending to, a person who talks about
engineering rather than one who does it.
Why it happens
The pull away from coding is not malicious. It is structural, and
it happens because the incentives all point in one direction.
Senior engineers are expensive. Organisations naturally want to
extract maximum value from expensive headcount. The most visible
form of leverage is influence: one senior engineer who reviews
code, answers questions, and makes architectural decisions affects
the output of five junior engineers. One senior engineer who
writes code produces the output of one engineer, perhaps with
higher quality. The leverage calculation is obvious and it is wrong.
It is wrong because it treats engineering skill as static. It
assumes the senior engineer who stops building remains as capable
as the one who keeps building. This is not how skills work. Engineering
is a practice. It requires continuous exercise. A surgeon who stops
performing operations and moves into medical administration is
not available to the hospital as a surgeon five years later. They
have different skills now. Valuable skills. Not surgical ones.
The same is true for engineers. An engineer who has not written
production code in three years, who has not debugged a live incident
at the code level, who has not sat with a new framework and built
something real with it, has a different skill set than they did
three years ago. They have institutional knowledge. They have judgment.
They can read a system design and identify its weaknesses. They cannot
build the system.
The organisation pays for what it believes is a force multiplier and
gets something valuable but different from what it expected. The
engineer pays with capability they did not intend to give up.
The judgment without craft problem
There is a specific failure mode that emerges from this transition
that is hard to see from the inside.
An engineer who has stopped building retains their judgment about
what good looks like, formed from their experience of building.
This judgment is real and useful. The problem is that it begins to
degrade in specific ways that are not immediately obvious.
Good engineering judgment is not abstract. It is grounded in the
current reality of what is possible, what is fast, what is painful,
and what breaks. This reality changes constantly. The abstractions
shift. The tooling improves. The performance characteristics of
systems change as the underlying platforms evolve. The things that
were hard five years ago are sometimes easy now. The things that
seem easy from a distance are sometimes newly hard in ways that
only become apparent when you try to build them.
An engineer who is actively building updates their judgment
continuously through contact with this reality. They try something,
it does not work the way they expected, they update their model.
They read the error message. They hit the limitation. They find
the workaround. This continuous updating is not dramatic. It is
the normal texture of building software. But it keeps the judgment
calibrated.
An engineer who is not actively building is running on cached
judgment. Their model of what is hard and what is easy, what is
fast and what is slow, is a snapshot from whenever they last
built things seriously. This snapshot becomes less accurate over
time, but the degradation is invisible to them because they have
no direct contact with the current reality that would reveal the
gap.
The result is opinions that are confidently wrong in ways that
only become apparent when someone tries to implement them.
# The kind of thing a cached-judgment engineer might propose:
# "Just add a caching layer in front of the database,
# it's straightforward, shouldn't take more than a day."
# What the engineer building it discovers:
# Cache invalidation for this data model requires
# tracking relationships across four entity types.
# The cache stampede problem on cold starts needs handling.
# The serialisation format needs versioning.
# The TTL strategy needs to account for consistency requirements.
# Testing the cached paths needs a different test infrastructure.
# What was "a day" is three weeks of careful engineering.
# The estimate came from judgment that had not been updated
# by the experience of actually doing it recently.
This gap between proposed and actual is one of the most common
sources of friction between senior engineers who have stepped back
from coding and the engineers who implement their proposals. The
implementers know the gap exists. The senior engineer often does not.
What gets lost that nobody mentions
The obvious loss when an engineer stops coding is technical currency.
The tools move. The frameworks change. This is real but it is
also recoverable with deliberate effort.
The less obvious losses are harder to recover.
The ability to estimate honestly. Estimation requires recent
experience of how long things actually take. An engineer who has
not built anything in two years cannot accurately estimate how long
it will take to build something now. They can produce a number.
The number will be wrong in ways that are hard to detect until the
project is underway. The engineer will believe the number because
it matches their cached sense of how long things take.
The ability to detect complexity from code. A senior engineer
reading code knows when something is more complex than it should
be. This knowledge comes from writing code and feeling the
difference between something that reads cleanly because it is
clean and something that reads cleanly because the complexity
is hidden. After years without writing code, this sense dulls.
The code review becomes shallower. The questions become more
high-level. The subtle architectural problems that would have
jumped off the page become invisible.
The credibility to push back effectively. An engineer who
is actively building earns credibility with their team through
demonstrated competence. When they say a design is wrong, the
team believes them because they have seen the engineer be right
before in ways that were verifiable. An engineer who has not
built anything in years makes the same claim but with a different
credibility structure. They may be right. The team has fewer
ways to verify it.
The feel for what is genuinely hard. Some things are hard
in ways that are not obvious from a design document. Race
conditions that only appear under specific timing conditions.
Data corruption that emerges from an edge case in a serialisation
format. Performance problems that only manifest at production
data volumes. An engineer who is building regularly encounters
these and updates their internal map of where the hidden complexity
lives. An engineer who is not building loses this map gradually,
replaced by a more abstract and less accurate version.
The engineers who avoid this
The senior engineers who do not fall into this pattern share
something in common: they have made an explicit commitment to
staying in contact with building, and they have made it in a
way that is visible enough to be protected from schedule pressure.
This takes different forms for different people.
Some reserve a portion of every week for writing production code.
Not prototypes. Not experiments. Production code that ships and
runs and breaks and gets debugged. The amount varies but the
commitment is treated as non-negotiable in the same way that
a weekly architecture review is non-negotiable. It goes on the
calendar. It survives meeting requests.
Some rotate through on-call rotations. Being on call forces
contact with the operational reality of the system. You are
not reading about incidents. You are debugging them. The debugger
does not care about your title. It shows you the stack trace.
You have to read it. This contact with reality is valuable
precisely because it bypasses the abstraction layer that
seniority tends to insert between an engineer and the system.
Some maintain personal projects or contribute to open source
with genuine commitment, not for portfolio reasons, but as
a way of staying in contact with the experience of building
without the organisational pressures that cause the drift in
the first place.
The common thread is deliberate, protected time for building
that is treated as a first-class responsibility rather than
something that happens when there is space in the schedule.
There is never space in the schedule. Space has to be created
and defended.
# An approach some senior engineers use to stay current:
# Build the tooling you wish existed for your team.
# Not a proof of concept. Not a demo.
# A tool that your team uses in production.
# This has several properties that make it effective:
# 1. It forces contact with the current state of the tools
# 2. The output has real users who will tell you when it breaks
# 3. The scope is usually small enough to complete
# 4. The domain is something you understand deeply
# 5. It produces something valuable rather than just exercises
# Examples that fit this pattern:
# - Internal CLI tools for deployment workflows
# - Monitoring dashboards the team actually uses
# - Code generation tools for boilerplate reduction
# - Test helpers that reduce the friction of writing tests
# - Performance profiling scripts for the specific system
# The anti-pattern is the proof of concept that lives in a branch
# and is shown at a demo and never runs in production.
# That touches code without the accountability that makes it useful.
The honest conversation about titles
There is a version of the senior engineer transition that is
genuinely right. Some engineers find that the leverage work,
the architecture work, the mentoring and the writing and the
planning, is where they create the most value and where they find
the most satisfaction. They grow into staff or principal roles
and they are genuinely excellent at them. They maintain enough
technical currency to keep their judgment calibrated, even if
they are not writing production code every week.
There is another version that is happening to engineers who
would rather be building but are being pulled away from it by
a combination of organisational incentives and social expectations
about what seniority looks like. These engineers are losing
something they valued, substituting something they value less,
and calling it career growth because that is the available
vocabulary.
The engineering industry does not have good vocabulary for
the engineer who wants to be deeply senior and deeply technical
simultaneously. Individual contributor tracks exist at many
companies but they are often treated as consolation prizes
for engineers who were not good enough for management, rather
than as the legitimate and valuable career paths they should be.
The engineers who want to stay close to building need to name
this explicitly, to themselves and to the organisations they
work for. Not "I am not interested in management" which sounds
like a limitation. But "I am most valuable and most effective
when I am close to the code and I am going to protect that."
This is a statement of professional judgment, not of career
limitation.
Organisations that understand this will make space for it.
Organisations that do not will slowly pull the engineer away
from the thing that made them valuable in the first place,
and be confused about why the force multiplication stopped
working.
The recovery
For engineers who have drifted and want to return, the recovery
is not complicated. It is uncomfortable, and it takes time, and
that is all.
The first step is accepting that capability has decayed. This
is the hardest part. An engineer who has been treated as an
authority for several years has to sit down with a codebase
or a tool they do not fully understand and feel incompetent
for a while. The internal experience of this is uncomfortable
regardless of how much intellectual acceptance there is.
The second step is building something small and finishing it.
Not learning a new framework theoretically. Building something
that ships and runs. Small enough that the finish line is
visible. Real enough that it has users and breaks and requires
debugging.
The third step is doing this consistently enough that the
muscle memory returns. This takes months, not weeks. The
calibration of judgment to current reality takes longer than
the recapture of technical mechanics, because it requires
enough accumulated experience with the current state of things
to have a reliable sense of where the hard parts are.
None of this is dramatic. Engineering is a practice and like
all practices it responds to consistent effort over time.
The engineer who drifted and then returned, who has both the
accumulated judgment of years of experience and the current
calibration of active practice, is genuinely rare and genuinely
valuable.
Most do not make the return. The drift feels like growth.
The calendar stays full. The meetings require the same preparation
as building used to require. The work feels substantial because
it is substantial. The specific thing that was lost does not
announce its absence loudly.
It is just gone, quietly, while nobody was looking.
The best time to notice this is before it is very far along.
The second best time is now.
Top comments (0)