Most operational dysfunction gets diagnosed in the wrong room.

Leadership looks at a program that has stalled and concludes the team is too slow, or does not care enough. That diagnosis is almost always wrong, and it is wrong in a specific, repeatable way: it blames the people doing the work for a gap in process and accountability that usually starts with leadership, or with leadership's absence from the conversation.

The Gap Diagnostic exists because the fix does not start with the team. It starts with a listening tour that treats every conversation, starting before any engagement is even signed, as data rather than formality. Senior leadership gets asked first, not because they have the answer, but to test whether the team is even aligned on what the problem is. A wide variance in their stories is the first finding, not noise to filter out. From there the tour widens to the people closest to the work, asked directly and independent of what leadership believes.

Laid side by side, those accounts rarely tell one story. They form a spectrum, leadership's account, middle management's account, and the account of the people doing the work, and the widest gap in that spectrum is where the real system failure is hiding. That is the second stage: Map the Gap. The fix gets built there, with the people closest to the work rather than for them, and the last stage hands the system back with a cadence the organization can run on its own, because no process stays correct by itself, only a team that has been shown how to keep it current does.

Two recent pieces worked through pieces of this directly: why an operator who has actually held the P&L argues differently from someone who has only advised on it, and why the Listen stage treats the C-suite's account as one data point, not the brief. Both are live on LinkedIn now.

One more note worth flagging here rather than saving for later: a podcast appearance is now booked and the prep is written. More on that once the show airs.

If a program in your world looks stalled right now, the question worth asking before any reorg is simple: whose account of the problem are you building the fix from, and have you checked it against anyone else's.