Software architecture · Level 7: Enterprise · Module 33b of 46

From senior engineer to architect

A senior engineer is judged on what they build. An architect, or a staff or principal engineer, is judged on what other people build because of them: the decisions teams make without asking, the problems that never happen, the direction a hundred engineers share. The technical knowledge in this track is necessary and not sufficient. This last module is about the other half of the job: the kinds of senior technical roles, writing vision, strategy and design documents, and leading people you don't manage.

1. The idea

A good player becoming a coach. The player wins by playing well. The coach doesn't touch the ball during the match: they win by choosing the system the team plays, explaining it until every player can apply it alone, spotting problems from the sideline before the score shows them, and talking to the club's owners in a language about money and seasons rather than passes. Some coaches still train with the team every day, and the best ones can still show a player exactly how.

Four kinds of staff-plus role

Module 02 described the architect's expectations and titles. Will Larson's interviews with staff-plus engineers found four recurring shapes of the role (StaffEng):

Archetype	What they do	Partners with
Tech Lead	Guides the approach and execution of one team, or a few in a focused area	One manager, sometimes two or three
Architect	Owns the direction, quality and approach of a critical area across teams	Several team leads and managers
Solver	Digs into hard, ambiguous problems and finds a path; some stay in one area, others move from one urgent problem to the next	Whoever owns the problem
Right Hand	Extends an executive's attention, borrowing their scope and authority to run parts of a complex organisation	A VP or CTO

Vision, strategy and design documents

Three kinds of writing do most of an architect's work:

Document	Answers	Horizon
Design doc (or RFC)	How will we solve this specific problem, and which alternatives did we reject?	One project
Strategy	Given our constraints today, which choices do we make again and again, and why? (Module 33a)	The next year or two
Technical vision	What does good look like in two or three years, concretely enough that teams can steer towards it?	Several years

Larson's order: write design docs; when five of them keep fighting the same battles, write a strategy; when several strategies pull in different directions, write a vision that reconciles them. A vision written first, with no designs behind it, tends to be a wish list.

What a design doc contains

Google's widely copied structure (as described by Malte Ubl):

Section	What goes in it
Context and scope	The landscape and what is being built; facts, not requirements
Goals and non-goals	What it must achieve, and what it could reasonably do but deliberately won't
The design	The overview, diagrams (Module 32), APIs and data storage, at the level the trade-offs need
Alternatives considered	Other designs that would have worked, and the trade-offs that ruled them out
Cross-cutting concerns	Security, privacy, observability and anything else the organisation always asks about

An RFC process wraps the document in a lifecycle: draft, open for comment with a deadline, decided by a named person, then recorded. The decision itself ends up as an ADR (Module 27); the RFC keeps the reasoning and the debate.

Influence without authority

Architects rarely manage the people who carry out their decisions. What works instead:

Pre-wire decisions. Talk to each person whose support you need, one to one, before the meeting. Objections raised privately improve the proposal; objections raised first in a big meeting harden into positions.
Ride the architect elevator. Gregor Hohpe's image: the architect rides between the penthouse, where business strategy is set, and the engine room, where the technology is built, and translates in both directions. Executives need options, costs and risks; engineers need the concrete constraints.
Mentor and sponsor. A mentor gives advice. A sponsor spends their own credibility on someone else: recommending them for the high-visibility project, putting their name in the room where promotions are decided. Senior people grow the organisation by doing both.
Disagree, then commit. Argue in the open while the decision is open; once it's made, support it fully, and say what evidence would make you raise it again.

2. How it works

An RFC from draft to decision

A staff engineer proposes moving the order flow from synchronous calls to events on a managed Kafka service. Watch the document change as it meets the people it affects.

One decision, three floors

The decision: move the payments database to a managed service. The same decision has to be explained on each floor, and news has to travel back up.

3. Try it yourself

Which staff-plus archetype fits you?

Answer four questions about the work you enjoy most. There's no best archetype: companies need all four, and many people move between them.

4. Trade-offs

Hands-on vs leverage

Writing code keeps your judgement current and your credibility high; every hour on the critical path is an hour not spent unblocking ten people. Code off the critical path: prototypes, tooling, fitness functions, reviews (Module 02).

Writing vs talking

Documents scale, last and can be read by people you'll never meet; conversations build the trust that gets documents read. Write the decision; talk it through before you publish it.

Consensus vs decision

Broad agreement makes a decision stick and can take forever. An RFC with a comment deadline and a named decider gets both: everyone is heard, and someone decides.

Depth vs breadth

Deep expertise in one area makes you the Solver for it; breadth across many lets you see how they fit (Module 02's knowledge pyramid). Architects keep one or two deep areas and grow the breadth deliberately.

5. In real projects

Make your work visible. Much of an architect's work is problems that never happened. Keep a short record: decisions you drove, documents you wrote, people you sponsored, incidents your designs prevented or contained. It's what promotion committees and interviewers ask for.

Pick a few things and finish them. The temptation at this level is to comment on everything. Choose two or three areas where you'll make a real difference this half-year and say no, kindly, to the rest.

Grow the next architects. Let others write the design docs you could write faster; review them carefully. Pair a promising engineer with a decision just beyond their reach, and sponsor them when it works.

Say it in the interview

Two-sentence answers

"How do you get teams to adopt a decision you don't control?" I write it down with the reasoning and the alternatives, and talk to the key people one to one before it goes to a group. Then I make the right thing easy: templates, examples and a fitness function.
"Tell me about a technical decision you drove." The situation and its constraints, the options with their trade-offs, how I got agreement, what we decided and the result, including what I'd do differently. One decision, told end to end.
"Vision or strategy?" Strategy is how we choose under today's constraints; vision is where we want to be in a few years. I write strategy from real design decisions first, then a vision when strategies need reconciling.

Red flags interviewers notice

Every story is about code the candidate wrote alone.
"I told them to" as the way decisions were adopted.
No example of changing their mind, or of helping someone else grow.

6. Remember it

Memory hook: "Write it, pre-wire it, ride the elevator"Put the reasoning in a document, win the key people one at a time before the meeting, and translate the decision for every floor, up and down.

How this hook works: what "write it, pre-wire it, ride the elevator" means

What the slogan means, phrase by phrase

"Write it": Design docs, strategies and vision: decisions with their reasons, readable without you in the room.
"pre-wire it": One-to-one conversations before the group decides, so objections improve the proposal instead of blocking it.
"ride the elevator": Explain in options and risk upstairs, in constraints and detail downstairs, and carry news both ways.

Why this picture fits: it's the coach's job: a written game plan, a quiet word with each player before the team talk, and a different conversation with the owners than with the squad.

The story → the concept

Coaching	The architect's job
The game plan	Strategy and design documents
A word with each player first	Pre-wiring the decision
Talking to the owners	The penthouse: options, cost, risk
Training-ground detail	The engine room: constraints and design
Picking a young player for the big match	Sponsorship

The trap it saves you from

The brilliant senior engineer promoted to architect who keeps doing the best work alone, and whose decisions no one else adopts.

7. Common mistakes

Still the best coder on the teamTaking the hardest tickets yourself makes you the bottleneck and leaves no one else able to do them.

Surprising people in meetingsA proposal whose first reading is in a large group meets defensive objections. Pre-wire it.

One language for everyoneExplaining partition strategies to the CFO, or quarterly revenue goals to an engineer with no technical consequence attached. Translate per floor.

A vision with no designs behind itAn inspiring document nobody can act on. Write strategy from real decisions first.

8. Design exercise (30 minutes)

One design doc (15 min). Outline a design doc for a change you'd like to make: context and scope, goals and non-goals, the design in five bullets, two alternatives considered, and the cross-cutting concerns.
Pre-wire it (10 min). List the four people whose support it needs. For each, write the objection you expect and what you'd change or explain.
Three floors (5 min). Write the decision in one sentence for an executive, one for an engineering manager and one for an engineer.

9. Self-check quiz

A staff engineer moves from one hard, ambiguous problem to the next as leadership directs. Which archetype?

The Solver digs into complex problems; some stay in one area, others move from one urgent problem to the next.

In a design doc, what is a non-goal?

Non-goals are plausible goals explicitly ruled out, which narrows the design.

What is pre-wiring a decision?

Objections raised privately improve the proposal; raised first in public, they harden.

How does sponsorship differ from mentoring?

Mentors advise; sponsors advocate, putting their name behind someone.

Larson's suggested order for writing?

Strategy grows from real design decisions; vision reconciles strategies.

10. Go deeper

Resource	Time	Why
Staff archetypes (StaffEng, Will Larson)	15 min	The four archetypes, with interviews from each.
Design docs at Google (Malte Ubl)	15 min	The sections, and when a design doc isn't worth writing.
The Software Architect Elevator (Gregor Hohpe)	book	Connecting the penthouse and the engine room.
What does sponsorship look like? (Lara Hogan)	10 min	Concrete ways to sponsor someone.
Writing an engineering strategy (StaffEng)	15 min	Design docs, then strategy, then vision.