Engineering review: what a two-week audit actually looks like

A two-week engineering review is the shortest engagement I run. It is also, more often than not, the most useful — because the deliverable is leverage. A written document that lets a small group of busy people act with confidence on five or six hard decisions they have been circling for months.

This essay is about what those two weeks actually contain. Not the version you would pitch on a discovery call, but the version your team sees once we start.

Why two weeks, and not four #

Most engineering audits I have seen drift. They start at four weeks, expand to six, end up at ten, and produce a deck that no one reads because the moment to use it has passed.

Two weeks is a forcing function. It is short enough that I cannot fix anything — only see it, write it down, and hand it back. It is long enough to talk to fifteen people, walk through the production system, and read the last three quarters of planning documents. Anything longer and I start being useful in ways that obscure the actual problem; anything shorter and I am guessing.

The constraint protects both sides. You get a verdict by a fixed date. I am not tempted to confuse a report with a turnaround.

Week one — listening #

The first week is almost entirely conversations. Ten to fifteen one-on-ones, forty-five minutes each, with people across engineering, product, design, operations, and (where it matters) sales and support. I write them up the same evening in a shared private doc that only I see.

I am not running a survey. I am triangulating. The same problem described by three engineers, a product lead, and a CTO usually sounds like four different problems. My job in week one is to figure out which of those problems is the same one wearing different costumes.

Three questions I ask almost everyone:

What would you change if you could change one thing this quarter?
What is the thing you wish leadership knew, that you don’t think they do?
Where do you waste the most time?

The first question maps the visible pain. The second maps the gap between the org chart and reality. The third is the one that usually pays for the engagement, because it surfaces the boring, expensive friction that no roadmap line item ever describes.

In parallel I walk through the production system with whoever is most senior on each surface. Architecture, deploys, observability, on-call rotation, the last six months of incident postmortems if they exist. I am not looking for elegance — I am looking for whether the people who own the system can describe how it fails.

I also read planning documents. OKRs, roadmaps, all-hands decks, board updates. The official narrative is data, not noise; the distance between the official narrative and what week-one conversations surface is usually the most important finding of the whole engagement.

The weekend in between #

I take a deliberate break on the middle weekend. By Friday of week one I have a hundred pages of notes, a working theory, and a half-finished outline. Sitting with it for two days, away from the document, is the only way I have found to tell the difference between a pattern I am seeing and a pattern I am projecting.

If I cannot articulate the top three findings to a non-technical friend by Sunday evening, I am not done thinking yet.

Week two — writing #

Week two is mostly writing. The deliverable is a 12–20 page report, in four sections:

Operating model. How the company actually plans, decides, and ships — not how the org chart says it does.
Platform and architecture. What the codebase and infrastructure make easy, what they make hard, and what they make dangerous.
People and hiring. Where the leadership ladder is thin. Where the hiring funnel leaks. Where the bus-factor risks are.
Near-term recommendations. Five to nine concrete moves, ranked by leverage, with rough costs and a clear owner.

The recommendations section is the one everyone flips to first. So I write the rest of the report assuming you will read those nine bullets and then go back to understand why.

I share a draft on Wednesday of week two, get reactions on Thursday, and deliver the final report plus a 90-minute workshop with the leadership team on Friday. The workshop is not a presentation — it is a working session where we go through each recommendation, argue about it, and decide which ones move into the next quarter.

What a good report does #

The bar I hold the document to is simple.

It names the two or three things that, if changed, would unblock the most other work. A long list of fixes is rarely useful at this stage. A small list of the right fixes, in the right order, almost always is.

It distinguishes between problems that need money, problems that need time, and problems that need a single decision. These look identical from the inside of a team and require different leadership moves to resolve.

It leaves the team with shared language. Most of the value compounds in the months after I am gone — when “the platform team’s customer is unclear” becomes a phrase three different VPs can say without re-litigating it. The language is the deliverable. The PDF is just a packaging.

What it does not do #

The report does not write a new architecture. It does not fire anyone. It does not replace a CTO. It does not produce a roadmap.

Those decisions belong to the people who will live with them. My job is to make those decisions cheaper to make — by removing ambiguity about what the actual problem is and what the trade-offs are. The decisions themselves are still yours.

The most common failure mode of engineering reviews is the consultant who tries to be the answer instead of the question. I try very hard not to be that consultant. The team you build after the review is the only thing that matters; if it depends on me being there, the engagement has failed.

What changes the day after #

When a review lands well, three things happen in the next week.

A meeting that has been on the calendar for six months happens. Usually one that the founders have been avoiding because they did not have a shared frame for it. The report gives them the frame.
A hire that should have happened gets unblocked. Either because the role description was wrong, or because the seniority bar was wrong, or because the team had been pretending the work could be absorbed.
Something gets stopped. A project, a process, an org-design experiment. Stopping is the cheapest, most undervalued lever in engineering leadership, and an outside report makes it easier to do without losing face.

If none of those three things happen in the first month after delivery, I take it as a signal that the report missed — and I will say so on the 30-day follow-up call.

When this is not the right engagement #

A two-week review is not the right engagement when:

You already know what the problem is and you need someone to do the work. That is a fractional CTO engagement.
You are at fewer than fifteen engineers. At that size the operating model is “what the founder does on Tuesday” and a 16-page document is more weight than the org can usefully carry.
The leadership team is not aligned that there is a problem. A review can describe reality, but it cannot create the political will to act on it. If half the room thinks everything is fine, the report just becomes ammunition in a fight that was happening anyway.

In those cases I will tell you so on the discovery call, and we will figure out the right shape together — or I will recommend someone else.

If a two-week engineering review sounds useful, the first conversation is free. Tell me what you are looking at and we can decide together whether this is the right shape.