Diagnosis before action
A reported issue should not automatically become a task, and it should never automatically become a judgement about an employee. The whole method is one sequence, and the first half of it is the part most programmes skip.
Discover → Diagnose → Prioritise → One owner → Sprint → Measure → Verify → Learn
What this looks like in practice
Customer callbacks keep going out late. It looks like somebody not caring.
Discovery finds three things instead. Nobody owns the handoff between the technician and the office. The queue sorts newest first, so the oldest request is the one nobody sees. And the person answering has no authority to resolve the two questions that make up most of the calls, so each one waits for a manager.
The first intervention names an owner, fixes what the queue shows, and sets a decision limit. Callback performance gets reviewed afterwards against the baseline. If a supported employee, with the conditions fixed, still knowingly ignores the agreed standard, that is addressed separately and as a conversation between people.
Clarity before accountability. Define the outcome, the standard, the owner, the authority and the support before judging anybody’s performance against it.
Agree what a worthwhile 90 days looks like
Interview the owner. What must improve, what still requires them personally, what already works, what has been tried. Agree scope, access, confidentiality, and what would make this worth doing.
Understand, and validate
Listen to employees, managers and selected customers. Observe the work. Review the processes, roles, technology and measures that already exist. Establish baselines, and study what works exceptionally well as deliberately as what fails. At day 30, agree the diagnoses and who owns what.
Implement, and learn
Pilot the highest-value changes. Clarify roles, train people, track a small set of outcomes. Brief weekly reviews of progress, blockers, evidence and capacity. At day 60, decide what to keep, adjust, stop or expand.
Standardise, and verify
Test whether the improvements hold in normal work. Update the processes to match what people actually do. Confirm adoption, and demonstrate that the backup can genuinely perform the work. Day 90 review, final report, and a prioritised roadmap for what comes next.
The sprint ends. The practice does not.
Verified standards and unresolved work carry into the next cycle. Priorities and capacity get reassessed, measures and ownership revisited. The next ninety days begin with what the last ninety taught the business.
A sprint is never a mandate to change everything at once. Choose a few things that matter, respect the capacity that exists, and learn before expanding.
How an engagement begins