There is a specific kind of quiet that happens right before you click open on someone else’s design document. It only lasts a second or two, but it is worth paying attention to — because what happens inside that second decides how the whole review is going to feel, for them and for you.

Somewhere in that pause, a reviewer is choosing, mostly unconsciously, between two very different postures. One is the posture of someone looking for what is wrong. The other is the posture of someone genuinely curious about what this person was trying to build, and why. Both postures will technically get the job done. Only one of them leaves the working relationship intact afterward.

It is easy to arrive at a different conclusion earlier in a career. Design review can feel like a test you are administering: someone submits a document, you run it against your mental checklist, mark up the gaps, and send it back. It feels efficient. It feels rigorous. What is easy to miss, for longer than most reviewers would like to admit, is that it also feels cold — and that the engineers on the receiving end quietly begin writing thinner documents, asking fewer questions in the doc itself, and routing around that reviewer whenever they can.

That is the signal that pushes a lot of reviewers to rethink the whole thing. A design review is not really a gate you pass through. It is a conversation that happens to be written down first. And like any good conversation, it works best when both people feel they are building something together, rather than defending positions against each other.

So when the question comes up plainly — what is your approach to reviewing another engineer’s design? — the honest answer does not begin with a checklist. It begins with that pause. Everything else in this piece is really just an attempt to explain what should happen inside that pause, and how to turn it into something repeatable across dozens of reviews and years of a career.

On the surface, a design review looks like a purely technical exercise. Underneath the surface, it is also a small, repeated act of trust between two people — and how that act is handled shapes what shows up in every design that reviewer ever sees again.

On the surface, someone drew boxes and arrows, wrote down a plan for a database, described how two services will talk to each other, and now the plan needs a second pair of eyes before the team commits real time to building it. That framing is true, and it matters. Bad designs are expensive to discover in production. A missing failure mode found at review time costs an afternoon of discussion. The same gap found six months later, after three teams have built on top of it, can easily cost weeks.

But there is a second thing happening underneath the technical exercise, and it is easy to miss if a reviewer is only counting bugs prevented. Every design review is also a small moment of trust between two people. The author is handing over something they thought hard about — sometimes something they are proud of, sometimes something they are quietly nervous about — and asking, implicitly, is this good enough, and am I good enough? How that question gets answered — not just the words, but the tone — shapes whether that person keeps bringing their real thinking to you, or starts bringing a safer, more defensive version of their work instead.

Both outcomes are visible on real teams. On one team, junior engineers stop writing down their uncertainty in design docs, because early on, uncertainty had been treated as a weakness to be corrected rather than a normal part of thinking out loud. On another team, the opposite happens: people start writing “here is what I am not sure about” sections voluntarily, because they have learned that flagging their own doubts earns a thoughtful conversation instead of a public correction. The second team catches more problems, earlier, with less friction. The difference is not skill. It is culture, and culture is built one review at a time.

So a well-thought-through approach is not just optimising for “did we catch the bug.” It is also optimising for “did this person leave the conversation a little more willing to think out loud next time?” Those two goals usually point in the same direction, but not always — and when they conflict, the second one deserves more weight than most engineering cultures give it.

If everything in this piece had to be compressed into a single sentence, it would be this: review as someone walking alongside the author, not as someone standing at the door deciding whether to let them through.

The gatekeeper mindset shows up in small, almost invisible ways. It shows up as “approve” and “request changes” buttons that feel like a verdict rather than a conversation starter. It shows up in comments phrased as commands: “use a queue here,” “this needs caching,” “wrong pattern.” It shows up in silence about everything that is good, because the gatekeeper’s job, as they understand it, is to find problems, not to notice care.

The guide mindset asks a different question before every comment: what does this person need from me right now to make their design better, without making them defensive? Sometimes the answer really is a direct correction — some things are simply wrong, and softening them into a vague suggestion does nobody any favours. But far more often, the answer is a question. Not a rhetorical question dressed up to sound polite while secretly meaning “you are wrong.” An actual question, one where you do not already know the answer, because you genuinely do not have full context on why they made a particular choice.

This shift changes the actual content of comments, not just their tone. A gatekeeper comment says: “This will not scale past 10,000 users.” A guide comment says: “What is your expectation for traffic in the first year, and have you sketched what changes if we are wrong by 10x?” Both comments might be pointing at the same underlying concern. But the second one keeps the author in the driver’s seat of their own design, invites them to show their thinking, and very often surfaces something the reviewer did not know — maybe they already discussed this with the product team and 10,000 users is genuinely the ceiling for the next two years. A gatekeeper comment closes that possibility off before it can even come up.

None of this means being soft on substance. Designs get turned down, and they should. A well-run review can say, plainly, “I do not think this will hold up, here is why, and here is what I think we should look at instead.” Being a guide does not mean being agreeable. It means being honest in a way that keeps the other person able to hear you.

A surprising amount of what makes a review good happens before the document is opened at all. Three small habits, none of them clever, all of them easy to skip when a calendar is full.

Check who wrote it, and what they have written before

Not to judge them, but to calibrate. A design from someone who has been on the team for five years and shipped six systems like this one deserves a different kind of scrutiny than a design from someone three months into their first backend role. Not less scrutiny — different scrutiny. With the newer engineer, spend more time explaining the “why” behind a concern, because the goal is not just a better document, it is a better engineer six months from now. With the experienced engineer, you can usually skip straight to the specific trade-off in question, because they have already internalised the fundamentals and just need a second opinion on this particular decision.

Read the title and the summary twice before anything else

This sounds almost too simple to mention. Many reviewers still skip it, scanning straight into the architecture diagram because that is the part that feels like “the real content.” The problem is that without knowing what the author is actually trying to solve, a reviewer ends up reviewing the diagram against their own assumptions about the problem — assumptions that are usually wrong in some small but important way. Two minutes spent making sure the actual goal is understood saves twenty minutes of comments that later turn out to be based on a misunderstanding.

Set aside real, uninterrupted time

A design review done in six two-minute fragments between meetings produces exactly the kind of review you would expect: surface-level, reactive, focused on whatever catches the eye in the first thirty seconds rather than on what actually matters. If a design is substantial enough to warrant a written document, it is substantial enough to warrant twenty or thirty minutes of your full attention, in one sitting, without Slack open in the other window.

Every design is an answer to a question, and every answer only makes sense once you know the question. The single most common mistake reviewers make — and the mistake most reviewers make most often early in a career — is critiquing the answer without first understanding the question the author was actually trying to solve.

Concretely, this means the first full pass through a document should not be a pass for problems at all. It should be a pass for context. What is the actual scope here? What is explicitly out of scope, and did the author think about why? What constraints were they working under — a deadline, a legacy system they cannot touch, a team with limited experience in a particular technology, a budget ceiling on infrastructure spend? What alternatives did they consider and reject, and what were their reasons?

A lot of the time, this context is already sitting quietly in the document, tucked into a “background” or “non-goals” section that is easy to skim past on the way to the diagrams. Reading it slowly, on purpose, before forming opinions, changes the entire review. It is impossible to count the number of times a concern a reviewer was about to raise turns out to already be addressed two paragraphs later, or explicitly called out as a known limitation the team had already decided to accept for now.

When the context is not in the document — and often it is not, because the author has it in their head and forgot that the reviewer does not — ask before critiquing. Not as a gotcha (“did you even think about X”), but as genuine information-gathering: “I want to make sure I understand the constraints here before I comment on the approach — is the six-week timeline fixed, or is there room to revisit it if we find something significant?” That single question, asked early, often reshapes the entire rest of the review, because it tells you how much weight your concerns should carry against the reality the author is actually operating in.

There is a deeper reason this matters. A design document is never a complete representation of someone’s thinking. It is a compressed summary, written under time pressure, aimed at a particular audience, leaving out everything the author considered too obvious to mention. Treating the document as if it were the entirety of their thought process is a subtle kind of unfairness. Asking about intent is how a reviewer makes room for all the thinking that did not make it onto the page.

Once the intent behind a design is understood, the reviewer moves through the document with a handful of lenses, roughly in this order. Not every lens gets the same weight on every design — a small internal tool does not need the same scrutiny as a system that will sit in the critical path of customer checkout — but all of them stay in view.

1. Is the problem actually framed correctly?

Before anything about the solution, ask whether the problem statement itself holds up. Sometimes a design is technically sound but solving a slightly wrong version of the problem — optimising for read latency when the real pain point reported by users was write latency, or building for a scale that marketing projects but engineering has not actually validated. Catching a misframed problem early is worth more than catching ten implementation details, because everything downstream inherits the mistake.

2. Are the trade-offs explicit, or hidden?

Every non-trivial design decision trades something for something else — consistency for availability, simplicity for flexibility, cost for latency, build time for long-term maintainability. A reviewer is not looking for designs with no trade-offs, because those do not exist. They are looking for whether the trade-offs are named out loud. A document that says “we chose eventual consistency here because the business can tolerate a few seconds of staleness on this field, and in exchange we avoid a distributed lock that would add latency to every write” tells the reader the author understands what they are doing. A document that just says “we use eventual consistency” without that reasoning leaves a reviewer wondering whether the choice was deliberate or accidental.

3. What happens when things go wrong?

The happy path in a design document is almost always well thought out, because it is the part the author pictured most vividly while designing. The unhappy paths are where real thinking gets tested. What happens when the downstream service is slow, not down, just slow? What happens when a message gets delivered twice? What happens when the retry itself fails? What is the blast radius if this component misbehaves — does it take down one feature, or does it quietly poison a shared queue that fifteen other things depend on? A disproportionate share of review time belongs here, because production incidents almost never come from the happy path.

4. Is this the simplest design that actually solves the problem?

Hold a soft bias toward simplicity, and notice when a design reaches for a sophisticated pattern — a new message queue, a new caching layer, a new microservice — before it has clearly earned that complexity through the actual requirements. This is not a rule against sophistication; some problems genuinely need it. It is a check against sophistication reached for out of habit, or because it is interesting to build, rather than because the problem demands it. Phrase this as a question rather than an objection: “What would the simplest version of this look like, and what specifically would it fail to handle?” Sometimes the answer confirms the complexity is justified. Sometimes it reveals the complexity was solving a problem that does not exist yet.

5. Can this design be operated, not just built?

A design that is elegant on paper but impossible to debug at 2 a.m. is a design that has not fully considered its own lifecycle. Look for whether the author has thought about observability — what will we actually be able to see when something goes wrong, what metrics or logs will tell us where the problem is, how will an on-call engineer who did not write this system understand it under pressure. Also look for how the system can be rolled back or turned off if it misbehaves after launch. A rollback plan that is an afterthought is a rollback plan that will not work when it is actually needed.

6. Does it handle data and security with real care?

Wherever a design touches anything sensitive — personal data, credentials, payment details, anything a regulator or a user would care deeply about — slow down. Who can access this data, and under what conditions? Is it encrypted in the places it needs to be? Does the design create a new place where sensitive data gets logged, cached, or copied that did not exist before, and if so, was that intentional? These questions matter regardless of how small the feature feels, because security gaps rarely announce themselves at the size they will eventually matter.

7. Is the writing itself clear enough to do its job?

Naming, diagrams, and structure are part of the design, not decoration around it. A component with a vague name like “processor” or “handler” often signals that its responsibility has not been fully thought through yet, because the author could not find a precise name for what it does. A diagram with arrows that do not specify direction, or boxes that mix “a running service” with “a conceptual step” without distinction, makes the design harder for the next reader to reason about, including the author’s future self. Raise these not as style nitpicks but as a genuine signal: unclear naming is very often a proxy for unclear thinking, and clarifying the name is a fast way to clarify the thought.

To say it plainly: this list is a lens, not a checklist to march through mechanically. On any given design, three or four of these will matter enormously and the rest barely at all. Part of the skill of reviewing well is learning to sense, quickly, which lens matters most for this particular document, rather than giving every design the same generic pass through every category.

A correct comment, delivered badly, does less good than a slightly-less-precise comment delivered with care. That is not an argument for vagueness. It is an argument for taking the phrasing of feedback as seriously as the technical content of it.

Questions before statements

The default opening move for anything that is not a factual error is a question. “What happens if this call times out?” does more work than “you have not handled timeouts,” even though they are pointing at the same gap. The question leaves room for the answer to be “actually, we do handle that, it is just not documented here” — and if that turns out to be true, nothing has been lost by asking instead of asserting. If the answer is “oh, good catch, we had not considered that,” the author gets to have that realisation themselves, which tends to stick better than being told.

Say what is working, specifically, not generically

“Nice doc!” at the top of a review is close to meaningless, and everyone knows it. What actually lands is specific: “I really like how you separated the retry logic from the business logic here — it makes the failure handling much easier to reason about on its own.” Specific praise does two things a generic compliment cannot: it tells the author exactly which instincts of theirs are good ones worth repeating, and it proves the reviewer actually read the document closely enough to notice, which makes the critical comments land as more credible too.

Separate “this is wrong” from “this is a preference”

Some comments are about correctness — this will actually break under a condition the design does not account for. Others are about taste — the reviewer would have structured this differently, but the author’s structure works fine too. Conflating the two is one of the fastest ways to erode trust, because an author who has been told five “preference” comments in the tone of “this is wrong” starts discounting all your feedback, including the comments that really do matter. Label the difference plainly: “this is a strong preference of mine, feel free to push back” versus “I think this one needs to change before we move forward, here is why.”

Keep the volume of comments proportionate

A document covered in forty comments does not read as “thorough” to the person receiving it. It reads as overwhelming, and it buries the three comments that actually matter under thirty-seven that do not. Before submitting a review, go back through your own comments and ask which ones genuinely change the outcome if addressed, and which ones are you indulging a preference that is not worth the author’s time to consider. Six comments that all matter beat twenty-five where nineteen are noise.

End on momentum, not on a pile of open questions

The last thing to write in a review is usually a short summary: what you think the strongest part of the design is, what the one or two things worth resolving before moving forward are, and an offer to talk it through live if that would be faster than going back and forth in comments. Ending this way turns a list of individual critiques back into a single coherent piece of feedback, and it makes clear that the goal was always to help this ship, not to catalogue everything imperfect about it.

Most reviewers are not unkind on purpose. The traps below are ones almost every reviewer falls into, sometimes more than once. Naming them clearly makes them easier to notice in the moment, before the comment has already been posted.

Reviewing the design you would have written, instead of the one in front of you

This is the trap most reviewers catch themselves in most often. There is often more than one reasonable way to solve a given problem, and it is easy to mistake “different from how I would do it” for “wrong.” The honest question to ask is not “would I have done this differently” but “does this actually fail to meet the requirements, or is it just not my instinct.” Those are very different findings, and only one of them belongs in a review as a blocking comment.

Letting seniority substitute for reasoning

“I have seen this pattern fail before” is a useful data point, but on its own it is an appeal to authority, not an argument. When raising a concern rooted in past experience, also explain the mechanism — what specifically failed, and why the same mechanism applies here. That gives the author something they can actually evaluate and push back on, rather than something they are just supposed to accept because a senior person said so.

Commenting on everything, because you can

Having access to leave a comment on any line is not the same as every line needing a comment. Nitpicking variable names in a document that also has an unresolved question about data consistency is a misallocation of attention — yours and the author’s. Before commenting on something small, ask whether it is actually worth the author’s time to read and respond to, or whether it is just something you noticed that does not really matter.

Going quiet when you actually disagree

The opposite trap is just as damaging: staying vague or non-committal about a real concern because raising it clearly feels uncomfortable, then being surprised later when the thing you were worried about actually happens. Kindness in delivery is not the same as softness on substance. If you think something is a real problem, say so clearly, even while trying to say it kindly.

Forgetting the author will read this alone, without your tone of voice

Something you could say lightly out loud, with a smile, can read as blunt or cold in writing, stripped of tone. Reread anything that could be taken the wrong way and ask whether it would still feel okay if you imagined the author reading it at the end of a long day. When in doubt, add a little more warmth in the phrasing than feels strictly necessary, because writing tends to lose warmth in transit.

Not every disagreement deserves the same amount of resistance. Over time, most reviewers settle into a rough, informal way of deciding how hard to push on any given point — and the three questions below are the ones that end up doing most of that work.

Things that touch irreversible harm — permanent data loss, a security gap that exposes user data, a decision that will be extremely expensive to unwind once other teams build on top of it — get your firmest, most persistent pushback. Say clearly that you do not think we should move forward without resolving this, and explain exactly what you are worried about and what evidence would change your mind.

Things that are easily reversible — a naming choice, an internal code structure, a decision that only affects one small, self-contained service — get raised once, as a genuine suggestion, and then let them go. The cost of being wrong about these is low, and the cost of turning every one of them into a standoff is high: it teaches the author that every review is a negotiation to be won or lost, rather than a chance to get a second opinion.

In between those two ends, be honest about your own confidence. If you are fairly sure and the stakes are moderate, say so plainly and ask the author to convince you otherwise. If you are genuinely unsure — which is more often than most reviewers used to admit — say that too. “I am not confident this is actually a problem, it is more of a gut feeling, take it for what it is worth” is a completely legitimate comment to leave, and it is far more honest than dressing up a hunch as certainty.

A single review is a small, contained interaction. But reviews, done consistently over months and years with the same people, become something larger: the foundation of whether people trust you enough to bring you their half-formed, uncertain, still-being-figured-out thinking, instead of only the polished version they are confident will survive scrutiny.

The engineers with whom the strongest working relationships tend to form are, almost without exception, the ones whose early, rough drafts you got to see — because they trusted that showing you an unfinished idea would not be held against them. That trust does not come from being an easy reviewer. It comes from being a consistent one — someone whose feedback is honest, proportionate, explained, and always aimed at making the work better rather than making a point.

It is worth thinking about this every time you are tempted to leave a sharp comment because you are tired, or busy, or mildly annoyed that something obvious was missed. The review in front of you is one data point in a much longer relationship, and it is rarely worth trading a moment of feeling clever or right for a slow erosion of someone’s willingness to show you their thinking early.

There is also a quieter, longer-term dividend that is easy to overlook: reviewers who have consistently been kind, honest, and useful over years tend to be the ones colleagues quietly reach for on the hardest, most sensitive designs — the ones with real risk, real ambiguity, or real interpersonal weight. That reach is rarely announced. It just shows up, one meeting invitation at a time, and it is almost never given to reviewers whose past comments taught the room to be careful around them.

Here is the short version of everything above — the ten checks most reviewers can hold in their head across almost any design, and use as a quiet self-audit before hitting submit.

One review, told plainly, that captures the difference between reviewing the design in front of you and reviewing the design you would have written — and why asking one question first turned a critique into a genuinely useful conversation.

A few years ago, an engineer on the team — still fairly early in their career — sent over a design for a notification system. It was ambitious. It had a queue, a fan-out layer, retry logic, and a dead-letter path for messages that failed repeatedly. On a first read, the reviewer’s instinct was that it was over-engineered for what the team actually needed in the next six months.

Instead of writing “this feels like overkill,” the reviewer asked what had shaped the design. It turned out the engineer had been on call during an incident, months earlier, where a much simpler notification system had silently dropped messages for two days before anyone noticed, because there was no dead-letter path and no way to see what had failed. Nobody had told them to build all this complexity in. They had built it because they had personally felt what happens when a system does not have it.

That context completely changed the review. The complexity was not accidental or naive; it was a direct, reasoned response to something they had lived through. The comments shifted from “do we need all this” to “let us make sure the dead-letter path itself has a clear, documented recovery process, since that is the part that actually saved you last time.” The design shipped close to its original shape, and it held up well. If the reviewer had led with their first instinct instead of asking, they would have pushed a talented engineer to strip out the exact protection that their hard-won experience had taught them to build.

It is a review worth thinking about often. Not because it is dramatic, but because it is such a clean example of how much a single question, asked before a single judgment, can change — both for the document in front of you and for the engineer on the other end of it.

Short, honest answers to the questions that come up most often when engineers start taking design review seriously as a discipline of its own, rather than as an incidental part of the job.

What if you disagree with the author and cannot resolve it in comments?

Move it to a live conversation, ideally with a shared doc or whiteboard open, as early as possible. Written back-and-forth is efficient for small clarifications, but disagreements that involve real trade-offs almost always resolve faster, and with less residual tension, in a fifteen-minute call than in a twelve-comment thread. If you still disagree after talking it through, be clear about whether this is a “I need to be convinced” blocker or a “I will defer to you, noted for the record” preference, and say so explicitly rather than leaving it ambiguous.

How do you review a design in an area you are not an expert in?

Honestly, and out loud. Say plainly, “I do not have deep experience in this area, so take my comments as an outsider’s questions rather than expert judgment.” That framing actually tends to produce good reviews, because an outsider’s honest confusion often points at places where the design assumes knowledge the reader will not have — which is valuable information regardless of the reviewer’s expertise. What is worth avoiding is pretending to expertise you do not have, because that produces confident-sounding comments that are sometimes just wrong.

Should junior engineers review senior engineers’ designs?

Yes, and it is one of the more underrated practices a team can adopt. A junior engineer’s questions often expose exactly the assumptions a senior engineer has stopped noticing they are making, because those assumptions have become invisible through years of familiarity. The best thing a senior engineer can do with a junior reviewer’s question is answer it seriously, even when the answer feels obvious, because the act of explaining it out loud is often where a gap gets noticed.

How long should a design review actually take?

Long enough that you could explain the design back to the author in your own words afterward. For most documents that is somewhere between twenty minutes and an hour, depending on scope. If you cannot summarise what the author is trying to do and why, in a sentence or two, you probably have not understood it well enough yet to review it fairly.

What do you do when asked to review something under real time pressure?

Say what you are confident about and flag what you have not had time to fully verify, rather than rushing to produce a false sense of completeness. “I have looked closely at the data model and I am comfortable with it. I have not had time to think through the failure modes as carefully as I would like — flagging that as a gap in this review, not a sign-off on that part” is far more useful, and more honest, than a fast review that quietly skips the hard parts without saying so.

Does written asynchronous review work as well as a live session?

For most small-to-medium designs, yes — and it has the advantage of giving both the reviewer and the author time to think without the pressure of an in-progress meeting. For larger designs, or ones with real disagreement, a hybrid works best: a first async pass in the document, then a short live session to resolve anything that would otherwise take ten comment threads to untangle, then a final async pass to capture what changed and why.

How do you handle a design you cannot approve, without discouraging the author?

Be direct about the “not yet,” specific about the “why,” and clear about the “what would change my answer.” A design turned down with those three ingredients tends to feel like useful information, not a personal setback — because it gives the author a concrete next move instead of a vague sense of having failed. Vague rejections are the ones that discourage; specific ones almost never do.

If there is a single thing worth taking from all of this, it is that reviewing someone’s design is a form of care, not a form of judgment, even when it involves disagreement.

The technical parts of this — checking for failure modes, questioning complexity, thinking about operability — are learnable skills, and they get sharper with practice and with getting a few things wrong along the way. The harder part, the part that actually determines whether people trust you with their unfinished thinking, is the posture underneath all of it: whether you are reading someone’s work looking for reasons to say no, or reading it looking for the version of it that gets to say yes, safely.

Nobody gets this right every time. Some weeks a reviewer is tired, or rushed, or a little too sure of themselves, and it shows in a comment they later wish they had phrased differently. But simply holding the question — am I being a guide right now, or a gatekeeper? — in mind before typing catches most of the moments that would have gone the wrong way. That is really the whole approach, underneath everything else in this piece. Every technique, every checklist item, every rephrased comment is just an attempt to make that one question easier to answer well, consistently, review after review.