Diagnosing an org in two weeks

The standard move on joining a new engineering organisation is the listening tour. Thirty one-to-ones over three weeks, a notebook, a lot of nodding.

It produces something, and the something is not a diagnosis. What you collect in thirty interviews is the organisation's account of itself: a set of well-rehearsed narratives about which team is difficult, which decision was a mistake, and who left. Some of it is true. All of it is coloured by where the person sits, and the parts everyone agrees on are usually the parts everyone has agreed on for two years without anything changing.

You need the interviews. They're just not the evidence.

Read the artefacts first

Before you talk to anybody, spend two or three days with the things that can't perform for you.

The repository. Pull request open-to-merge times for the last quarter, by team. Not the average, the distribution. The long tail is where the story is. Look at how many PRs sit for more than three days and who they were waiting on.

The incident log. Twelve months. What kind of thing breaks, how often the same thing breaks twice, and how long the average one takes to resolve. If there's no log, you've learned something more important than anything the log would have said.

The calendar. Aggregate, not individual. How many hours a week does the median engineer spend in meetings, and what fraction of the engineering group is in a recurring meeting at 10am on a Tuesday. This one is uncomfortable to look at and takes about an hour with a script.

The last two planning documents, side by side with what actually shipped. The gap between them tells you whether planning is a forecast or a ritual.

The org chart against the architecture. If they don't match, work is crossing team boundaries constantly, and you'll find the pain exactly where the lines don't line up.

None of this requires anyone's cooperation, which is the point. You arrive at the interviews with questions rather than with an empty page.

Then trace five work items

This is the part that does most of the work and almost nobody does it.

Pick five things that shipped in the last quarter. Not the flagship project, and not the disasters. Ordinary work, spread across teams, ideally one that went well and one that went badly.

For each one, sit with the people who did it and reconstruct the timeline. When was it first decided? Who decided? When did an engineer start? When was the first line of code written, and when was it merged, and when did a customer see it? Where did it sit still, and what was it waiting for?

Do this in a room, on a whiteboard, with the actual dates. It takes about ninety minutes per item.

By the third one you will start seeing the same delay in the same place, and it will not be the delay everyone told you about. In my experience the answer is almost never "engineers write code too slowly." It's usually a decision that took eleven days to get made, a review queue, an environment that only one team can provision, or a piece of work that was started twice because the requirement changed underneath it.

The five-item trace has one more property that makes it worth the time: it's evidence people can't argue with, because they generated it. You're not telling a team they're slow. You're pointing at a whiteboard they helped fill in.

The three questions worth asking

Do the interviews, but stop asking people what they think the problems are. You'll get the narrative.

Ask instead:

What's the dumbest thing we do that everyone has stopped noticing? This gets you process debt. People love answering it and the answers are unusually concrete.

If I gave you one week and no other work, what would you fix? This surfaces the thing they've been carrying. It's also a good predictor of who has judgment, independent of the answer.

What did you want to tell the last person in my job, and didn't? This one is uncomfortable and you should use it sparingly. It occasionally produces the single most useful sentence of the whole two weeks.

What I got wrong for years

I used to run this as interviews plus intuition, and I was reasonably good at it, which was the problem. A confident wrong diagnosis in week two is expensive, because everything you do for the next six months is downstream of it and nobody will challenge the new person's first big call until it has clearly failed.

The specific failure mode: people describe the organisation they wish they had, or the grievance they're currently holding. Both are sincere. Neither is a system-level view, and if you interview thirty people with the same blind spot you will come away with a confident consensus that is wrong in the same direction.

Artefacts and traced work items correct for this, because a date is not an opinion.

Two weeks is the padded number

Honestly, it takes about four days. Two or three with the artefacts, one and a half tracing work items, and the constraint is usually visible by the third trace.

I put ten days in the title because that's what I'd promise someone else, and because the extra week is genuinely useful for a different reason: it's how long it takes to be confident enough to say the thing out loud to people who've been living there for three years. The diagnosis arrives early. The standing to act on it takes a bit longer.

If you're a founder diagnosing your own org rather than a new arrival, cut it further. You already have the artefacts and you don't need the standing. You need the discipline to look at dates instead of at your own memory of how things went.

Writing it down

At the end of the exercise, write one page. Not a deck.

The constraint, named in a single sentence. The evidence, in three bullet points, with numbers from the trace. The two things you're going to change first. Then a short list of things you are deliberately not touching for the next quarter, with the reasoning.

That last section is what makes the document useful rather than decorative. Every organisation you join has ten visible problems. Saying which ones you're leaving alone is the actual content of a strategy, and it gives everyone permission to stop worrying about the other eight for a while.

Then circulate it and ask people to argue with it. Some of them will, specifically and usefully, and the ones who do are worth noting.

One thing not to do

Don't change anything structural in the first two weeks to demonstrate decisiveness.

The pressure to is real, particularly if you were hired to fix something and the person who hired you wants early evidence. Resist it for ten days. An organisation will forgive a leader who took two weeks and got it right. It takes considerably longer to recover from a reorg announced in week one by someone who had not yet found out where the work was actually sitting.