Red-Team Your Own Deliverable: The Dual-Pass Review to Run Before You Send

By NATARAJA Team

Every consultant has had the experience. You reread a deck you finished at midnight, it seems fine, you send it. In the meeting a client asks one question you had not considered, and the answer is obviously missing. It was missing at midnight too. You simply could not see it, because you were the person who wrote it.

This is not carelessness. It is a structural property of self-review, and it does not improve with seniority or effort. What it responds to is method.

Why reading it again does not work

The standard fix is to reread the work with fresh eyes, usually the next morning. That helps with typos and rarely with reasoning, for a reason worth naming: the mind reviewing the argument is the mind that built it, and it retraces the path it already knows. Familiarity gets mistaken for soundness. You are not testing the argument, you are recognising it.

The second standard fix is peer review, which works better and has three predictable failures in a professional services setting. Reviewers with less seniority soften what they say. Reviewers with more seniority substitute their own view rather than testing yours. And any reviewer inside the engagement shares your assumptions, because those assumptions were formed in the same meetings. The reviewer least able to find the flaw is often the person who has been closest to the work.

None of this is a character problem. Asking a colleague to genuinely attack your thinking is socially expensive, and most firms are not organised to pay that cost on a Thursday afternoon.

The mistake inside single-pass review

Here is the mechanical problem, and it explains why "review this critically" produces such weak results.

When one reader is asked to assess something, they hold two questions at once: what is good here, and what is wrong here. Those two questions require opposite postures. Finding what is strong means accepting the premises and reading generously. Finding what is broken means rejecting the premises and reading adversarially. A single pass that tries to do both does neither properly, and typically settles into a middle register that produces polite, non-committal feedback: a few suggestions, nothing structural.

The fix is not to try harder. It is to stop asking one pass to do two jobs.

The dual-pass method

Run two separate reviews of the same artifact, then adjudicate between them.

Pass one, the empathetic reading. Review the work from inside its own frame. Accept its premises fully and give the strongest sympathetic reading available. What is genuinely strong, and why? Where it is weak, treat the weakness as an execution gap rather than a conceptual flaw, and propose improvements that honour the work's own intent. Do not attack the premises here. That is the other pass's job, and mixing them is what produced the mushy middle in the first place.

Pass two, the hostile reading. Attack the premises at full strength with no softening. Take the posture of a sceptical expert whose job is to find the reasons this should not exist. Produce numbered attacks, strongest first. Critically, each attack must carry a falsifiable test: something that would confirm or dismiss it before the work is relied upon. An attack with no test is an opinion, and opinions are what this exercise is trying to get past. Finish with the single most damaging sentence a hostile reader could write about the work.

Then synthesise, by adjudicating. This is the step most people get wrong, so it deserves a rule of its own.

Adjudicate, do not average

The temptation at the end is to split the difference: the empathetic pass liked three things, the hostile pass attacked four, so the truth must be somewhere in the middle and we will soften a few claims.

That is not synthesis, it is arithmetic, and it produces worse work than either pass alone. Averaging discards exactly the information the exercise generated, because the value is not in the balance of opinion but in which specific attacks survive contact with the sympathetic reading.

So the synthesis asks four questions:

  1. Which hostile attacks survive the empathetic reading, and which dissolve when the work's own intent is properly understood?
  2. What is the net position, meaning what the work is actually worth once the surviving attacks are accounted for?
  3. What are the ranked fixes, most important first, with an honest sense of effort?
  4. What happens next?

A surviving attack is a finding. A dissolved attack is also a finding, because it tells you that a reader coming in cold will raise the same objection, which means the deliverable needs to answer it explicitly even though it is wrong.

The detail that makes it work: keep the passes apart

If the hostile pass reads the empathetic pass first, it anchors. It starts negotiating with the positive reading instead of attacking the work, and the attacks come out softer and more reasonable, which is precisely what you did not want.

Run them independently, without sight of each other. In our own implementation this is enforced structurally rather than by good intentions: the two passes execute in parallel as separate steps, and neither receives the other's output. Only the synthesis sees both.

If you are doing this manually, the equivalent discipline is to write the hostile pass in a separate document, in one sitting, before rereading anything positive you wrote about the work.

What it looks like when it bites

We run this on our own decisions, which is the only honest way to recommend it.

Recently we put a segment decision through a governed version of this method: which type of firm to prioritise for a new offering. The analysis had produced a clear recommendation with reasonable support. The hostile pass then produced five numbered attacks, and two survived.

The first was that the recommendation pointed away from the only directly observed evidence we had, and rested instead on a capability argument, which is a statement about us rather than about demand. The second was that a prerequisite the plan depended on had never been verified.

Neither attack was comfortable and both were correct. The first changed the recommendation. The second changed the sequencing, and when we went and checked the unverified prerequisite, it turned out to be already working, which was itself worth knowing.

That is what a working dual-pass review produces: not reassurance, and not a demolished draft, but two or three specific things you would have been embarrassed to be asked about in the room.

Put the surviving objection in the deliverable

Here is the part that converts an internal quality step into a client-facing advantage.

When an attack survives, the instinct is to quietly fix the deliverable so the objection no longer applies. Sometimes that is right. Often the objection cannot be eliminated, only acknowledged, and the strongest move available is to state it in the deliverable and answer it.

A memo that names its own strongest counter-argument and addresses it tells a client something no amount of polish can: somebody genuinely tried to break this before sending it. It also removes the most dangerous meeting dynamic in consulting, which is a client raising an objection the consultant has visibly not considered.

Where the objection stands unanswered, say that too. "This recommendation rests on an assumption we could not verify, and here is what would settle it" is a sentence that builds more trust than any confident summary.

The warning: do not outsource the challenge entirely

There is a cost to this method that is easy to miss, and our Executive Guarantees Brief on The Stairway Effect names the mechanism. Intuition is not innate; it develops when predictions repeatedly meet consequences. Reliable judgment before complete explanation is available is a capability that gets built by being wrong and noticing.

If you run a hostile pass, skim the output, patch the three flagged sentences and send, you have improved the deliverable and learned nothing. Worse, you have moved the calibration loop outside yourself. The consultant who engages with why the attack landed keeps building judgment. The consultant who treats the review as a checklist gradually stops developing the instinct that made them worth hiring.

So the discipline is: read the attacks that survive and ask why you did not see them. That question, asked honestly a few dozen times, is most of what professional development actually consists of.

Related, and relevant if your review only ever confirms: a signature that never amends anything has become ratification rather than judgment, which is the pattern our brief on Decision Displacement describes.

Frequently asked questions

How do you review your own work objectively?

You cannot, in a single pass, because the mind reviewing the argument is the one that built it and will retrace the path it already knows. What works is separating the job into two passes with opposite postures: one that accepts the premises and finds the strongest sympathetic reading, and one that attacks the premises and produces numbered objections with a falsifiable test attached to each. Then adjudicate between them rather than averaging. The separation is what creates the objectivity, not effort or distance.

What is a red-team review of a deliverable?

A red-team review deliberately adopts the posture of a hostile expert whose job is to find reasons the work should not exist, rather than a colleague offering suggestions. In practice it produces numbered attacks ordered by strength, each with a test that would confirm or dismiss it, and ends with the single most damaging sentence a critic could write. It is not the same as proofreading or a quality checklist, both of which assume the argument is sound and check the execution.

How do consultants quality check their deliverables before sending?

The reliable sequence is three steps, in this order. First a hostile pass on the reasoning, because a well-checked document with a broken argument is still wrong. Second a factual clearance: claims checked against their sources, numbers reconciled across the document, and language audited for claims stronger than the evidence supports. Third a named person who reviews and signs, recording what they amended. Most firms do the second step and skip the first and third, which is why the errors that reach clients tend to be errors of judgment rather than errors of fact.

Should the hostile review and the positive review be done separately?

Yes, and they should not see each other. A hostile pass that has read the positive one anchors on it and negotiates instead of attacking, producing softer objections. Run them independently and let only the synthesis step see both outputs. If you are doing it manually, write the hostile pass first in a separate document, in one sitting.

Can AI red-team my own work?

It can, and this is one of the tasks it is genuinely well suited to, because the barrier to a good hostile review has always been social rather than intellectual. A model has no relationship with you to protect and no seniority to defend, so it will attack the premises when asked, which most colleagues will not. Two cautions. Instruct it to attack rather than to review, since a generic review request produces the same mushy middle a human gives. And engage with the attacks that land instead of just patching them, or you will improve the document while your own judgment quietly decays.

Where NATARAJA fits

The method above is a protocol on our platform rather than a prompt you have to remember. The two passes run as separate governed steps that cannot see each other, the synthesis adjudicates rather than averages, and every run leaves an attested record of what was attacked and what survived. That record is useful twice: once for the deliverable, and once as evidence to a client that the work was genuinely tested.

If you want it applied to a live deliverable, request a governed pilot and bring something you are about to send.

Related reading: AI for Consultants for the wider operating model this fits inside, and the agentic AI governance framework for how governed steps work underneath.