The Acceleration Trap: Why Constant Change Can Silence Real Progress

Change is a strategic weapon — until you use it like a machine gun. The recent piece When Change Outruns Us by Mike Fisher nails an uncomfortable truth many leaders avoid: organisations can die from motion, not just from inertia. Nokia’s story, reproduced in multiple case studies including the Harvard Business Review case, shows how relentless internal churn exhausted capability and smothered the very outcomes change was supposed to deliver.

What the acceleration trap looks like

There’s an easy mistake to make: equate velocity with progress. Board decks full of initiatives, weekly reorgs, new processes and shiny transformation programmes look like action. But action is not the same as absorption. The acceleration trap is when change outpaces an organisation’s ability to integrate it — people, systems and customers are asked to do more change than they can assimilate. The result is fragmentation, rising technical debt, and a slow erosion of morale and focus.

Key symptoms

• Reorg fatigue: teams change reporting lines or objectives so often they lose long-term focus.
• Parallel pet projects: multiple competing initiatives eat the same scarce skills.
• Adoption lag: new features or processes are launched but usage and outcomes stagnate.
• Rising debt: technical and process debt accumulates because there’s never time to stabilise.
• Compliance over conviction: teams adopt the new language and rituals, but stop testing them against what they learned last time.
• Hidden health signals: rising churn and sick leave that throughput dashboards never show.

Why Nokia matters as more than a cautionary tale

Nokia’s decline is often simplified into a story of complacency. That’s misleading. What Mike Fisher and the HBR case make clear is that Nokia didn’t stop trying — it tried too many things, too quickly. Between leadership churn, new software divisions and competing internal platforms, the company generated motion but not coherent progress. The iPhone’s arrival changed the market; Nokia’s response changed the company — repeatedly — and outpaced its capacity to learn and rewire. For product and technology leaders, the lesson is blunt: if your organisation can’t absorb change, you create brittle motion, not durable advantage.

Practical levers: how leaders build deliberate adaptation

Leaders can escape the trap by designing for absorption as deliberately as they design for speed. Here are concrete steps you can apply this quarter.

1. Measure absorption, not activity

• Track adoption and outcome KPIs for every major change — not just delivery metrics. If a new platform doubles deployment speed but adoption stalls, you’re accumulating waste.
• Introduce an absorption dashboard: adoption rate, time-to-stability, bug backlog trajectory and team wellbeing indicators.

2. Create stability windows

• Limit the number of concurrent major initiatives a product team can own. Depth beats breadth.
• Designate consolidation sprints after big launches to pay down debt and embed learning, and hold a deep retrospective after every major initiative.
• Limit structural change to a predictable cycle, for example one reorganisation window every 18 months unless something is genuinely urgent.
• Fund slack as capability: reserve deliberate capacity for rewriting docs, consolidating APIs and closing feedback loops, as a first-class line item rather than whatever is left after delivery.

3. Fund outcomes, not activity

• Shift budgets from uplift ‘projects’ to sustained product funding. Fund a team to achieve outcomes over quarters, not to ship a checkbox feature this month.
• Use small rolling budgets for experiments, with clear gates based on adoption and economic value.

4. Protect the learning loop

• Insist every initiative includes a period for adoption measurement, documentation and knowledge transfer.
• Reward teams for stable systems and customer outcomes, not just velocity.

5. Treat changes as hypotheses

• Give every operating model, metric or framework defined success criteria and a fixed window for evaluation. If a change is adopted before the previous one is understood, you accumulate debris.
• Make reversibility explicit, so that stopping a change is a decision and not an admission.

Examples that illuminate the fix

Outside Nokia, firms that survived disruptive shocks tended to slow in the right places. Apple’s early focus on an integrated product and platform for the iPhone wasn’t just engineering brilliance — it channelled company energy into a single, cohesive shift. By contrast, companies that repeatedly reorganise without consolidation (a pattern we’ve seen across industries) lose institutional memory.

Spotify’s squad health checks are a practical model of the opposite instinct: a routine that surfaces working issues and makes it legitimate to slow down when needed.

Kodak’s failure to turn an invention into a sustained business is another reminder: discovery is one thing, absorption into an operating model is quite another. See the lessons in Kodak’s history for a deeper read.

Design your change portfolio

Treat change like a portfolio problem. Balance big bets with time for integration. For every disruptive initiative, allocate a proportion of resource explicitly for post-launch consolidation and capability-building. That single governance change reduces the temptation to treat reorgs as a substitute for strategy.

Three simple rules to keep on your desk:

• Cap simultaneous major initiatives per team.
• Require an absorption plan with every change request: a readiness check on bandwidth, and a named owner for the integration work.
• Measure outcomes, not effort.

Leaders who can resist the glamour of perpetual motion and design organisations that absorb change will create durable advantage. The acceleration trap is not a call to stop improving; it’s an argument for pacing and purpose. Read Mike Fisher’s When Change Outruns Us if you haven’t already — then map the changes in your organisation into a portfolio that values recovery and learning as much as speed.

The Same Trap, at AI Speed

The pattern has a new costume. Organisations that run AI as a programme of parallel initiatives rediscover exactly this failure: plenty of motion and very little absorbed. AI Transformation Is a Loop, Not a Programme sets out the alternative, one workflow and one decision at a time, and Gall’s Law explains why the big-bang version fails. The scarcer skill now is steering rather than rowing: choosing what deserves absorbing in the first place.

Ask one question in your next leadership meeting: are we changing faster than our people can make it part of their work? If the answer is anything but a clear no, act.