Lesson 4 of 4

From Senior Developer to Solution Architect

The specific habits that make a strong senior developer and the specific ways each one has to change. This is the transition the track is built around.

10 min read

The transition fails in a recognisable way. A strong senior developer becomes an architect and keeps doing what made them strong — going deep, solving the hard problem personally, having the best answer in the room — and finds that none of it is working. The skills are not wrong. The unit of work changed, and habits calibrated for one unit misfire in the other.

What changes

Dimension	Senior developer	Solution architect
Unit of work	A feature, a service, a sprint	A system, a programme, two to three years
Definition of done	It works, it is tested, it shipped	Teams can keep changing it safely without you
Optimises for	Correctness and elegance in the code you control	Least-bad outcome across constraints you do not control
Handles ambiguity by	Asking for the requirement to be clarified	Deciding under it, and naming what would change your mind
Source of credibility	Depth — you know this system best	Judgement — your calls hold up over time
Failure looks like	A bug in production	A design that was fine on day one and unmaintainable by month twenty

Each row is a strength that becomes a liability when the scope of consequence widens.

The four habits that need recalibrating

Strengths that misfire at the new scope

1
Solving it yourself
As a developer, taking the hardest problem is leadership. As an architect it is a bottleneck — and worse, it removes the growth opportunity from the person who should be taking it. The recalibration: your job is that the problem gets solved well, not that you solve it. Take the problem only when nobody else can, and then hand it back as soon as they can.
2
Going deep
Depth is what made you trusted. The architect version is knowing exactly how deep to go on any given question — deep enough to make the decision defensibly, and not one hour deeper. Learning to stop at "sufficient for this decision" feels like sloppiness for about a year, and it is the difference between covering three teams and covering one.
3
Being right
Correctness stops being sufficient. A correct design nobody adopts has less value than a good-enough design three teams implement well. The recalibration is to treat adoption as part of the design problem rather than as someone else's implementation detail.
4
Preferring code to conversation
Many engineers moved into this work partly because code is more tractable than people. The role is roughly 30% communication and it cannot be delegated. The good news is that it is a learnable skill with concrete techniques, not a personality trait — the previous lesson is entirely about those techniques.

Two paths into the role

Deep specialist route

Arrives via deep expertise in one domain — data, security, distributed systems.

Immediate credibility with engineers
Genuinely strong technical judgement in the specialism
Spots the class of failure others miss
Tends to over-apply the specialism to problems that do not need it
Often underweights organisational and delivery constraints
Communication is usually the weakest muscle

Choose when: You are already here. The development priority is breadth and the communication techniques, and the specific discipline of noticing when you are reaching for your specialism because it is yours.

Broad generalist route

Arrives via breadth across many systems and a strong grasp of the business.

Sees the whole value chain and the real constraints
Communicates naturally with non-engineers
Comfortable deciding with incomplete information
Credibility with engineers has to be earned rather than assumed
Risk of designs that are sound on a diagram and painful to build
Can miss failure modes that need depth to see

Choose when: You are already here. The development priority is enough depth to be wrong less often, and staying close to the code so your estimates of difficulty stay honest.

In practice

A first ninety days that worked

A senior developer of eight years was promoted to solution architect across four teams in a logistics company. She had written most of the routing engine and knew it better than anyone.

Constraints

Four teams, none reporting to her
Two teams had never worked with an architect before
A major replatforming decision was due in month four
She was still the only person who understood the routing engine

Decision

Spend the first six weeks deliberately not proposing anything. Pair with each team for a week, read the last two years of incidents, and interview the operations and commercial leads about what actually hurt. Simultaneously, hand the routing engine over: pair-program the two hardest areas with two engineers until they could carry it.

Why

She had credibility on the routing engine and none on the other three systems, and the replatforming decision would need all four. Proposing early would have spent credibility she had not yet earned. Handing over the routing engine was urgent for a separate reason — she could not be both the architect and the single point of failure for a critical component.

What it cost

Six weeks of looking, to some observers, like she was not doing anything, and one uncomfortable conversation with a manager who wanted architectural output by week three. What she found in the incident review — that 60% of production incidents traced to one integration nobody owned — reframed the replatforming decision entirely. That would not have surfaced from a diagram or from a month of meetings, and it was worth considerably more than six weeks of proposals.

Three months into the role you notice you are in eleven meetings a week and have written no code and no ADRs. What has gone wrong?Reveal

You have become a coordinator rather than an architect. Meetings expand to fill an architect's calendar because everyone wants an opinion, and attending is the easiest way to feel useful. The correction is mechanical: identify which meetings produce a decision you are accountable for and decline the rest, in writing, with an offer to review the outcome asynchronously. Then protect two blocks a week for reading code and writing decisions. If the calendar leaves no room to think, the thinking will not happen, and thinking is the job.

Key takeaways

The transition fails when developer habits are applied at architect scope, not from lack of skill.
Solving it yourself, going deepest, and being right all need recalibrating for the wider blast radius.
The feedback loop stretches from hours to months, so written reasoning becomes the only way to grade your own judgement.
Adoption is part of the design problem: a correct design nobody implements has no value.
Hand over the component you personally built; you cannot decide impartially about a system you are holding up.