If a system needs champions to beg people to use it, the system is wrong. Not the people.
Every stalled rollout gets explained as resistance to change. Almost none of them are.
People adopt tools that give them time back and avoid tools that add steps to something that was already working — which makes adoption a design problem, and a solvable one.
Why adoption is a design outcome, not a campaign
The pattern is familiar enough to be predictable. The system goes live with training sessions and a champions network. Week one is busy. By week three, logins have thinned and the old spreadsheet has quietly reappeared, and someone schedules more training.
More training rarely fixes it, because training is a bandage applied to a design wound. If people need persuading to use something built to help them, the honest reading is that it didn’t help them — it added steps to a Monday that was already full. Adoption isn’t measured in logins. It’s measured in Mondays getting better.
The starting question decides everything downstream.
Process-first asks: how do we build the system? You map the current process, build to fit it, then work to make people comply with it.
People-first asks: what are people carrying that they shouldn’t have to? You find the grind, remove it, and uptake happens because the work got lighter — no campaign required.
Same budget, same technology, completely different result. People-First Technology makes the full case for why adoption is designed rather than demanded.
Two ways to introduce the same system.
Process-first
Compliance- Map the current process, then build to fit it
- Uptake enforced by policy, training and reminders
- Champions push usage; progress tracked manually
- When it stalls, the answer is more comms and more oversight
- Plateaus once the novelty fades, and the workarounds return
People-first
Relief- Ask what slows people down, and remove that first
- Uptake happens because the work got lighter
- The team uses it because Monday is easier
- When it stalls, you look for steps still to remove
- Compounds, because each improvement buys belief for the next
Stop buying adoption. Start removing friction — the fastest route to a system people use is one that took work away from them in the first fortnight.
Why the friction is already visible if you go looking for it
You don’t need a requirements workshop to find it. You need three questions and an hour with the people doing the work: what part of the week do you dread, what workaround do you use that nobody taught you, and what one thing would you change tomorrow?
Write the answers down verbatim. The user’s language is the requirement — the moment you translate it into system language you lose the detail that made it solvable. Then look for the fingerprints: a task done daily, a process explained to new starters with an apology, a person who has to be interrupted for the same decision five times a day, data hand-copied between two systems, an undocumented workaround everybody uses, and morale that dips on the heaviest days. Workarounds are user-built proofs of concept. Someone has already designed your first release; they just did it in a spreadsheet.
The sixty-minute friction hunt
How to find the first thing worth building without commissioning a discovery project. Swipe through.
Why a perfect department can still produce a broken customer journey
Every team can hit target while the customer has a miserable time. Ten green dashboards, one unhappy customer — because the delays and the losses mostly don’t happen inside teams. They happen in the corridors between them, where work changes hands and nobody owns the handover.
Your org chart is not a value chain. Departmental optimisation makes each room more efficient at its own contribution, which is exactly why the leaders who build lasting capability start from what’s right for the business as a whole. The fix is unglamorous: measure the corridor, not just the rooms. Handoff time. Cross-team rework. One customer-facing lag metric that nobody can improve alone. And name an owner for the corridor — an owner, not a committee.
The myth: if every team hits target, the business wins. The reality: the handoffs decide the result — build the road, not just faster cars. Read Breaking Down Operational Silos →
The corridor problem, in two essays
Why the gaps between teams cost more than anything inside them — and how to design the flow of information across them.
Essay
Breaking Down Operational Silos
A perfect silo still creates a broken journey. What it takes to fund the corridor rather than the rooms either side of it.
Read →Essay
Mapping Interactions for Seamless Information Flow
Follow the information rather than the org chart, and the real shape of the business — and its bottlenecks — becomes visible.
Read →
Why politics fills the space where learning should be
Something happens in the minute after a release doesn’t go as expected, and whatever happens in that minute sets the culture for every release afterwards. If the first question is who did this, people learn that imperfection is ammunition — so the next release is smaller, later, over-documented, and the data that would have fixed the problem goes quietly underground. Blame is a full-time job with no deliverables.
The organisations that build lasting capability treat discovery as part of the cycle. Their version of that minute is a script: what changed, what did we learn, what do we try next, by when, and who owns it. Five questions, one owner, twenty minutes. It sounds procedural. It is the difference between a team that ships and a team that hides.
Small proof beats big promise.
This is also why release size is a cultural decision, not just a delivery one. A failed small release is early data. A failed big release is a budget conversation — and everyone in the room knows it in advance, which is precisely why big releases attract the politics.
Perfection is delay with better lighting. Users believe what they touch, not what they are told, and the fastest way to end a two-month argument is a two-week test that produces one number everybody agreed to care about beforehand.
The costliest version of this pattern — the one that looks like quality standards and is really fear — is set out in The Hidden Pitfall in Software Development and in The Fear of Shipping.
Why leadership is direction, not control
Leaders who try to define everything from the top produce great theory and poor practice. The detail of how work should happen lives with the people closest to it, and the leaders who build capability that lasts set the outcome and the guardrails, then hand the nuance over.
That isn’t a lowering of standards; it’s where standards actually get enforced, because the people who own the decisions are the ones who see the consequences. The warning signs of over-control are measurable: decisions waiting on one calendar, escalations rising, user testing slipping because the users were never really trusted with it. Vision, not supervision. Guardrails, not guard dogs — and the practical version of that split is in Direction at the Top, Decisions at the Edge.
Why the real constraint is your capacity to change
Technology is rarely the bottleneck. The organisation’s capacity to absorb change is — and unlike a budget, it doesn’t expand because the plan demands it. Scope is a load you are placing on human beings, and it is finite in exactly the way a training programme is finite: volume, intensity, recovery.
Treated as a budget, it becomes manageable. Decide, out loud and each quarter, how much of your delivery capacity goes to new capability versus improving what exists. Cap the number of concurrent streams — two is the working maximum for most businesses, three if each has a strong owner. Timebox releases so a team can absorb one before the next arrives. And name a single person accountable for adoption on each release, not for delivery of it.
If your people are tired and your dates keep slipping, the plan is wrong. Not the people. Slow scope isn’t a weakness; it’s the only way big change ever gets finished — Your Capacity to Change Is the Real Constraint turns that into something you can set, cap and measure each quarter.
Next: how to pick the first win — Where to start → All insights → Book a conversation →