People often expect a diagnostic to produce a score: a number, a level, a position on a curve. I do not provide one for a simple reason. A score tells you where you rank, and nobody has ever fixed anything with a ranking.
What I produce is a description: what I saw, what I think causes it, what it costs you and what I would change first. I document the assumption behind every observation, so you can challenge my reasoning rather than only my conclusion. This matters because a conclusion you cannot interrogate is one you will quietly ignore.
The description is always structured around the same six dimensions.
1. Clear purpose
Everyone understands why they are doing the work and what would change if it succeeded. When this is clear, motivation and quality follow without being managed. When it is missing, no amount of process design can compensate. You get a feature factory that produces the next requested thing efficiently, but no way to know whether it was the right thing to build.
A useful test is whether the people doing the work can explain its purpose to someone outside the company — their partner or grandmother — clearly enough for that person to understand why it matters. If the explanation works only in internal language, it is not a purpose. It is a mandate.
2. Shared ownership
People feel responsible for the whole, not just their part of it. They contribute ideas and have visible influence over decisions. This is almost impossible without a clear purpose; people cannot take ownership of something whose purpose they cannot see.
You hear its absence in the language of meetings: “I assigned it to…” where you would expect “I picked this up.” When work is assigned during planning rather than pulled, priorities are quietly set by availability rather than importance.
When improvement comes only from management, the change lasts exactly as long as the person driving it remains in sight.
3. User focus
Work happens with users in the room rather than being based on assumptions about them. Teams that work this way are forgiven for an imperfect product because users would rather help improve it than go elsewhere. Teams that do not work this way deliver something technically correct, then are surprised when it is poorly received.
The question is not whether a feedback channel exists; one always does. The question is when someone last changed their mind because of what came back through it.
4. Flow
Once work starts, it keeps moving and spends most of its time being worked on rather than waiting. The purpose of flow is not speed for its own sake, but predictability, which removes the need to treat work as urgent. An organisation that can say when something will be delivered does not need a mechanism for jumping the queue.
This is also the dimension in which I watch for two risks. First, averages hide everything: the median cycle time tells you very little, while the long tail is where credibility with stakeholders quietly erodes. Second, too much emphasis on short, stable lead times reliably kills innovation because anything uncertain looks like a threat to the numbers. When the work is about speed, I measure quality and team health alongside it. Otherwise, you discover too late that you gained speed at the expense of the other two.
5. Feedback loops
I look for distinct cycles at the operational, tactical and strategic levels, each of which processes what comes back rather than merely collecting it.
Most organisations hold the meetings. Far fewer have the loops. A retrospective that generates actions with no owner is not a feedback loop; it is a scheduled venting session with good intentions. The test is whether anything downstream changes measurably because of what happened in that room.
6. Backlog clarity
A user and a developer can open the same backlog and both understand what is happening. It may sound like the smallest item on this list, but it removes an entire category of follow-up meetings and is usually the least expensive to fix.
Why six and why always the same six
I want the reports to be comparable with one another. After examining the same six dimensions across many teams, I can identify patterns that no single engagement would reveal and avoid being swayed by whatever was most vivid in the previous two weeks.
A fixed framework also protects the client from my own bias. If I went in looking for whatever caught my attention, I would find what I am already good at seeing. Using the same six dimensions every time, in no particular order, ensures that the awkward dimension is not skipped simply because it was a difficult week.
Every report I write opens with the same line, and I mean it: if anything here misrepresents your view of the situation, let us talk.