Why is technical *breadth* said to matter more than technical *depth* for an architect, and what are the risks of that trade?
answer
- Pyramid: know / know-you-don't / don't-know-you-don't
- Breadth = middle band; architects live there
- Depth needs maintenance and decays
- Depth is borrowable, breadth isn't
- Frozen caveman: designing from one old trauma
basics
~20 sAn architect's job is choosing between options, so knowing that many options exist and roughly what each costs is more useful than mastering one. Depth still matters — but it decays, and you can borrow depth from specialists; you can't borrow the knowledge that an option exists.
solid answer
~60 sRichards & Ford model knowledge as a pyramid with three bands: **stuff you know** (technologies you can use hands-on today), **stuff you know you don't know** (you've heard of it and know when to look it up), and **stuff you don't know you don't know** — the vast base. A developer's value is measured by the top band: deep, current, hands-on expertise. An architect's value shifts to the *middle* band — breadth — because architecture is fundamentally about selecting among alternatives and making trade-offs, and you cannot evaluate an option you don't know exists. The most dangerous band is the bottom one: unknown unknowns are what turn into surprise rewrites. The trade has real costs. The top band requires maintenance; every hour spent maintaining stale expertise is an hour not spent widening breadth. Ford's advice is to let some depth go stale deliberately rather than fight to stay the deepest expert. The risk is the architect who is broad but shallow — makes plausible-sounding decisions that fail on details only a specialist would have known. Mitigation: stay hands-on somewhere, and treat depth as something you *borrow* by consulting the specialists on your teams before committing.
go deeper
Just get the core idea across: architects need to know that many options exist so they can choose well, while developers need to master the ones they use. Depth is still valuable.
Describe the three-band knowledge pyramid explicitly and explain why the architect's value shifts toward the middle band — you can't evaluate an option you've never heard of.
Add the economics: depth requires maintenance and decays, depth is borrowable from specialists, breadth isn't. Discuss the risks (broad-and-shallow decisions, lost credibility) and your concrete strategy for staying hands-on without becoming a bottleneck.
Treat it organizationally: your job is the organization's collective knowledge portfolio, not just your own. Where do you need deep specialists on staff versus consultants? How do you systematically convert unknown-unknowns into known-unknowns across teams (post-mortem culture, advice process, cross-team rotation)? How do you counter expertise bias in decision-making at scale?
## The knowledge pyramid Richards & Ford visualise an individual's technical knowledge as a triangle: ``` /\ stuff you KNOW / \ (hands-on, current, you could build with it today) /----\ / \ stuff you KNOW YOU DON'T KNOW / \ (you've heard of it, know roughly what it's for, /----------\ know you'd need to research it) / \ / \ stuff you DON'T KNOW YOU DON'T KNOW /________________\ (everything else — by far the largest area) ``` - **Top band (know).** Technical depth. This is what a developer is paid for and what interviews for developer roles probe. It has a hidden cost: **it requires maintenance**. Expertise in a fast-moving technology decays within a couple of years unless you keep using it. - **Middle band (know you don't know).** Technical breadth. You know that event sourcing exists, roughly what problems it solves, and what it costs — enough to put it on a shortlist and then research or delegate. You couldn't implement it from memory, and you don't need to. - **Bottom band (don't know you don't know).** The invisible majority. These are the technologies, failure modes, regulatory constraints and alternatives you never even consider — and therefore never evaluate. Every unpleasant late-project surprise lives here. ## Why the architect's value shifts to the middle Architecture is *selection under constraint*. The work is: enumerate viable options → understand each one's trade-offs → choose the one that best serves the ranked quality attributes → record why. Step one is gated entirely by breadth. If you have never heard of a transactional outbox, you will invent dual writes and lose messages. If you don't know CRDTs exist, your offline-sync design will be a homegrown last-write-wins that silently drops edits. Crucially, **depth is borrowable and breadth is not.** If you know an option exists, you can pull in the specialist, read the docs, or run a spike — you can acquire depth on demand. But nobody can tell you about the option you never asked about. This asymmetry is the whole argument. A second reason: an architect who is the deepest expert in something tends to become a **bottleneck** (all work in that area routes through them) and to suffer **expertise bias** (the tendency to reach for the tool you're best at). ## The costs and risks — this is a trade-off, not a free upgrade **1. Broad-and-shallow decisions.** Trade-offs often turn on details visible only from inside a technology: the actual consistency guarantee a database provides under its default isolation level, how a queue behaves on redelivery, what a framework's threading model does under load. An architect operating purely on marketing-level knowledge makes decisions that are right in the slide deck and wrong in production. **2. Loss of credibility.** Teams follow architects who can hold a technical conversation at the level the team works at. An architect who can no longer read the code loses the ability to influence, and drifts toward the **ivory tower** anti-pattern. **3. Slower feedback.** Depth in something is what lets you sanity-check a decision quickly by building a small thing. Without any hands-on capacity, every validation is a request to someone else, and the loop lengthens. ## How practitioners manage the trade - **Deliberately let some depth go stale.** Ford's phrasing: stop trying to maintain expertise you no longer use; the maintenance cost is what prevents you widening breadth. This feels like loss and is usually correct. - **Keep one or two areas deep**, ideally cross-cutting ones the architect naturally touches (data, distributed systems, security, the delivery platform). - **Stay hands-on somewhere off the critical path.** Spikes, proofs of concept, tooling, pairing, on-call. You get feedback without being a delivery bottleneck. - **Borrow depth systematically.** Before any significant decision, consult the people who work in that area daily. This is the mechanism behind the *advice process*: whoever makes the decision must first seek advice from affected parties and from those with relevant expertise. - **Attack the bottom band on purpose.** Read broadly outside your stack, review post-mortems (yours and public ones), attend to what adjacent industries do. Every conversion of an unknown-unknown into a known-unknown is direct risk reduction. ## Related anti-patterns worth naming - **Frozen caveman anti-pattern.** An architect whose every design is refracted through one traumatic past experience — insisting on multi-region active-active for an internal admin tool because a datacentre once burned. The tell is risk assessment untethered from current, actual probability. Antidote: quantify the risk (how likely, how costly, versus mitigation cost) rather than arguing from anecdote. - **Résumé-driven architecture.** Choosing technology for its value on your CV rather than its fit. Breadth without discipline enables this — you know about many shiny things. - **Expertise bias / law of the instrument.** "To a man with a hammer, everything looks like a nail." Deep specialists promoted to architect without widening breadth reproduce their one system everywhere.
- If breadth matters more, should an architect stop coding entirely?No. Some hands-on work is what keeps decisions grounded and preserves credibility with teams — Fowler's Architectus Oryzus. The practical resolution is to stay hands-on in ways that don't make you a delivery bottleneck: spikes and proofs of concept, tooling and cross-cutting work, pairing, code review, and production on-call. What you give up is being the *deepest* expert, not being a practitioner.
- How do you actively shrink the 'don't know you don't know' band?Deliberate exposure outside your current stack: reading widely rather than only in your ecosystem, studying public post-mortems and incident write-ups, reviewing other teams' and other industries' architectures, attending talks about problems you don't currently have, and — most effectively — asking specialists 'what would you have expected me to ask?' before finalising a decision. Every unknown-unknown converted into a known-unknown is risk removed before it becomes a rewrite.
- What is the 'frozen caveman' anti-pattern and how do you counter it?An architect who filters every decision through one memorable past failure, so designs are shaped by irrational risk assessment — e.g. demanding multi-region failover for a low-stakes internal tool because of a decade-old outage. Counter it by forcing risk to be quantified: what is the actual probability, what is the cost if it happens, what does the mitigation cost, and does the business consider that trade worthwhile? Anecdote loses to arithmetic.
A general practitioner versus a cardiac surgeon. You want the surgeon's depth when you already know it's your heart. But the GP's value is knowing that a thousand conditions exist and recognising which specialist to send you to — a brilliant surgeon who assumes every chest pain is cardiac will miss the ones that aren't. The GP still needs enough medicine to know when the surgeon's plan sounds wrong.
saying these in an interview costs you the question
- Claiming breadth means depth is worthless — an architect with no hands-on grounding loses credibility and misses decisive details.
- Trying to remain the deepest expert in every technology the organization uses; the maintenance cost crowds out breadth and makes you a bottleneck.
- Evaluating technologies from marketing material without any hands-on validation or specialist consultation.
- Assuming the biggest risk is what you know you don't know — the dangerous band is what you don't know you don't know.
- Choosing technology for career value rather than fit (résumé-driven architecture).
- Designing around one dramatic past incident without quantifying current probability and cost.