Case files and field notes from inside real organizations.
The Stated Problem
Tools live and a documented path in sixty days.
Read →Fourteen Offices, One Standard
40% less variation; the federal review closed with no further items.
Read →The List Came Out Next Week
Audit pass rates up 25%, violations down 30%.
Read →Everything Was Urgent
Incomplete requests dropped within the first month.
Read →The Stated Problem
Why the first explanation is almost never the real one.
Context
A growing technology organization wanted to expand advertising support for a group of third-party sellers. Ownership looked clear on the org chart, leadership supported it, and the customer need was well understood. Every attempt to move the work forward ended the same way:
"We can't support that."
The explanations were reasonable: limited capacity, a difficult legal review, competing priorities. None were false. None explained why progress had stopped.
What we found
The work was led from inside the organization. We used value stream mapping to trace how requests actually moved, and talked to people well beyond the immediate stakeholders. Two things surfaced.
- Knowledge and responsibility had separated. A former manager who built the original program still carried nearly a decade of context. People who no longer owned the work were still the ones everyone called when it broke.
- The current teams were protecting constraints no one had written down. Legal exposure, compensation structure and operational capacity shaped nearly every decision, and none of it appeared in project documentation.
The resistance wasn't arbitrary. It was rational. Organizations protect more than processes. They protect incentives.
The reframe
We stopped asking how to persuade the team to participate and started asking what would have to be true for them to participate safely. Resistance stopped looking like obstruction and started looking like information.
What we built
- Decision-tree guidance, developed with subject matter experts, that turned the resistant team's expertise from a barrier into a requirement.
- A reconstruction of the historical knowledge from multiple sources, captured as a documented operating path.
- Parallel support paths that reduced dependence on a single stakeholder group while keeping the expertise that already existed.
Result
Within sixty days, the tools were live, sellers could reach support they previously couldn't, and the organization had a documented operating path that no longer depended on one team's cooperation. The relationships stayed challenging, but the work was moving again, and the organization understood why it had stopped.
When an organization tells you, "We can't," treat it as the beginning of the investigation, not the end of the conversation.
Fourteen Offices, One Standard
Why "every office is different" is usually the symptom, not the cause.
Context
A statewide agency of more than 10,000 employees ran its work through 14 autonomous offices. A federal requirement called for annual compliance audits and training, plus an annual report to federal reviewers explaining the agency's processes and what had improved. The reviewers could audit as well.
In practice, audits happened ad hoc or every other year. Some offices went more than a year without one.
What we found
The team's explanation was reasonable: 14 autonomous offices with different geographic needs. The real cause was simpler. There was no standard. Each office had built its own approach, so there was nothing consistent to adjust for local needs.
The differences between offices were real. But they had nothing to be exceptions to.
The reframe
We put the standard first and layered each office's specific requirements on top of it. To get there, we met with points of contact from 20 different units. We asked about their pain points, where their knowledge had gaps, and how their work connected to the compliance program. Then we showed each team how the standard served the thing they were already accountable for.
What we built
- One compliance framework for every office, with room for local requirements inside it.
- An annual training built to support that framework.
- Execution tracking and audit checkpoints, so gaps showed up before the auditors found them.
- A single point of contact for federal audits, with one consolidated report documenting every change.
Result
Variation in how offices delivered the program fell by 40%, measured by how many offices and teams had adopted the changes and completed training by their next audit. After the consolidated report and supporting information went to federal reviewers, the agency received a letter confirming that no further items were needed.
When every group says it's a special case, check whether there's a standard for them to be special against.
The List Came Out Next Week
Why a report that tells you what you missed isn't a control.
Context
A state health agency's inspection bureau was responsible for more than 100 healthcare facilities. Every week, leadership received a report listing the facilities that had not been audited. If a facility was on that list, it had already been missed. The report reached everyone in the chain, up to the bureau's senior leadership.
What we found
The problem wasn't the missed audits themselves. It was timing. The report was accurate, but it arrived the week after the miss, so it recorded failures and couldn't prevent them.
What we built
We put every facility into a single spreadsheet, with the date of its last audit and the date its next one was due. Each row was coded by status:
- Red: past due.
- Yellow: coming up soon.
- Green: already audited.
Instead of learning about a miss from next week's report, the team could see it coming and act first.
It worked well enough to spread. We worked with the bureau's management and its IT director to define the inputs so the tool could eventually be automated, and it was adopted across the bureau.
Result
Fewer facilities showed up on the weekly list. Because audits happened on time, facilities arrived at each re-audit or annual visit already knowing their prior deficiencies and what they'd done well, so they came better prepared. Audit pass rates improved by 25% year over year, and violations fell by 30%.
The best operating mechanism is often the one that lets you see the problem a week before the report does.
It started with a simple motive: nobody wanted their facilities on that list.
Everything Was Urgent
Why a prioritization problem looks like a capacity problem.
Context
A support organization served thousands of sellers through hundreds of customer success managers. Every manager had a seller with an urgent need and a good reason it should come first. Requests arrived through chat, email and side conversations, often incomplete. The team doing the work couldn't tell what mattered most, and requesters couldn't tell where their request stood.
What we found
It looked like a capacity problem. It was a prioritization problem. There was no shared definition of "priority," no required information, no criteria for saying no, and no one with the authority to settle a conflict between two legitimate requests.
What we built
- A seller scorecard, so requests could be compared the same way every time.
- An intake form with routing and priority flags, so the right information arrived with the request.
- Decline criteria with pre-built materials, so a "no" was consistent and still gave the requester somewhere to go.
- A standard operating procedure, so the process would survive changes in people.
Result
Incomplete requests dropped within the first month. The team was later restructured, and the tools stayed in place.
A prioritization model doesn't eliminate conflict. It gives teams a shared way to make tradeoffs.
Eventually two teams will both have a legitimate claim to go first. That's why it needs an escalation path: who decides, what they need to know, how fast, and what happens when priorities change.
Short-form observations
Recognize something here?
Tell us what's stuck and we'll tell you honestly whether we can help.