An engineer brings me a design. It has a flaw I can see in thirty seconds. I point at the flaw. The review ends, the flaw gets fixed, everyone leaves satisfied, and I have made the team slightly worse.
Why that is a failure
Nothing went wrong technically. The design is better than it was. But three things did not happen:
- The engineer did not find the flaw themselves
- Nobody learned how I saw it
- Next quarter, the same class of design arrives on my desk again
I optimised for this artefact at the expense of the next ten. And because the outcome looked like success — a bug caught, a design improved, a meeting that ended early — nothing signals that it went badly. That is what makes it the mistake I keep repeating.
There is a second cost that took me longer to notice. An engineer whose designs get corrected rather than questioned learns that review is where an architect finds problems. So they stop looking as hard themselves, because that is now my job. I have accidentally trained the team to bring me first drafts.
The version that works
Slower in the room, cheaper over a year.
Ask what they considered and rejected. Most flaws are visible in the discard pile. If someone rejected the right approach for the wrong reason, that is the actual conversation, and it is invisible if you only look at what they brought.
Ask what would have to be true for this to be correct. This is the highest-yield question I know. It surfaces the assumptions the design rests on, and about half the time the engineer finds the flaw mid-sentence, because the assumption does not survive being said out loud.
Name the failure mode, not the fix. "What happens if this queue backs up for an hour?" is worth ten times "add a dead-letter queue." The first teaches a way of interrogating a design; the second teaches a fact about queues.
Let the silence sit. This is the hardest one for me. The answer usually arrives four or five seconds after I want to supply it. Filling that gap is the single most common way I undo the rest.
In practice
| Instead of | Try |
|---|---|
| "This needs idempotency keys." | "What happens if the client retries?" |
| "Split this service." | "Which of these two things changes more often?" |
| "That won't scale." | "At what number does this become a problem?" |
| "Use an outbox here." | "What happens if the write succeeds and the publish fails?" |
| "This should be async." | "Who is waiting for this, and how long will they wait?" |
The right-hand column takes about four times as long and works permanently. It also produces better designs than my answer would have, often enough that I have stopped assuming my thirty-second read was right.
The exceptions
I want to be careful here, because "always ask questions" becomes its own dogma and there are situations where it is actively wrong.
When it ships tomorrow and the flaw loses data. Teaching has a time and a place, and 6pm before a release is neither. Say the answer, fix it, and have the conversation next week.
When the engineer has asked directly. "What would you do?" deserves an answer. Answering a direct question with a Socratic one is a power move disguised as mentorship, and people can tell.
When you are the only person who knows something. If the flaw depends on context nobody else could have — a production incident three years ago, a regulatory constraint, a contractual commitment — no amount of questioning will surface it. Share the context, then the conclusion, then explain why the context mattered so it is not lost again.
When the gap is too wide. With a very junior engineer, questions they cannot answer are not a learning experience, they are an interrogation. Calibrate to what they can reach.
What I measure now
The signal I watch is not the quality of designs arriving. It is whether flaws are being caught before they reach me — whether the peer review two steps earlier is finding things, whether engineers arrive saying "I went back and forth on this and here is why I landed here".
When that is happening, the reviews get shorter and more interesting, and my thirty-second reads get less useful, which is exactly the point. The measure of an architect is not the diagram. It is whether the engineers around you can make the next ten decisions without you in the room.