Eleven Weeks to Six, With 35% Less Money
New hires currently take eleven weeks to make their first productive contribution; the target is six. The steering group meets in two weeks and expects a recommendation. The L&D team has proposed buying a new learning platform at $180,000, but this year's budget for the initiative has just been cut by 35%. While reviewing the data you notice that roughly 60% of the elapsed time is spent waiting - for system access, for three sequential approval forms, and for a manager to sign off on the onboarding plan. Actual training content accounts for about two weeks. The steering group is impatient and one member has already asked why 'we can't just buy the fix.'
1. What problem should the steering group actually be solving, and what is wrong with the framing of the platform proposal?
Read the worked answer
The proposal answers the question 'how do we deliver training faster?' The data says the question is 'how do we shorten time to first contribution?' Those are different problems with different solutions, and the first one has already been solved by the evidence.
Rough arithmetic: 60% of eleven weeks is about 6.6 weeks of waiting. Two weeks is content. If the waiting were removed entirely, the hire lands near the six-week target without buying anything. A platform that speeds up content delivery is optimising the smaller share of the problem. That does not make the platform wrong - it may still be worth buying later - but it is not the bottleneck, and buying it now would consume the reduced budget while leaving the six weeks of queue time intact.
I would restate the problem for the steering group as a single how-might-we, present the time breakdown as the reason for the restatement, and be explicit about the assumption I am making: that the waiting time is genuinely non-value-adding, not hiding a quality check that exists for a reason. That assumption is the first thing to test.
2. Design the two-week engagement that produces a credible recommendation under the budget cut.
Read the worked answer
The cut is an asset here, not just a constraint. A $180,000 solution was on the table partly because nobody had been forced to look for a cheap one.
Week one - see the process, don't workshop it. Walk one recent hire's onboarding end to end with timestamps: when each access request was raised, when each form was signed, what the hire did while waiting. Interview the last four hires and the managers who signed the forms. This produces a map of where the 6.6 weeks actually sit, which is the evidence that makes any recommendation defensible.
Week two - generate, then judge, in that order. A short session with deliberately mixed attendance: two recent hires, a hiring manager, one of the people who signs the forms. Silent written idea generation first, to stop the most senior person setting the frame. Then map ideas against three criteria agreed before scoring: effect on time-to-contribution, cost, and reversibility.
I would bring two or three options to the steering group, not one - including the platform as a 'later, not now' option with a trigger condition. A single recommendation invites a yes/no; a portfolio invites a decision.
3. A team member proposes eliminating all three approval forms entirely. How do you handle it?
Read the worked answer
Treat it as a provocation to be mined, not a proposal to be voted on - and do not evaluate it in the moment it is raised, because premature evaluation kills the next five ideas in the room.
The right sequence is to log it, keep generating, and only then test it against the pre-agreed criteria. When I do test it, the useful question is not 'is this safe' but 'which of the three forms is actually protecting something?' They are unlikely to be equal. One may exist because of a genuine compliance requirement, one because a manager wanted visibility in 2019, and one because a system cannot be provisioned without it. Stripping the third is a two-line change; stripping the first is not an option.
So the answer is usually a partial version: remove one form outright, convert one to a notification rather than an approval, and leave the compliance one in place. Then pilot it on a single role for one cohort with a named kill criterion - if access provisioning errors rise above a stated threshold, the change reverses.
What I would avoid is both reflexes: dismissing it as naive, or adopting it because it is bold. Both skip the question of what the forms were for.