Why Enterprise Transformation Fails Between Strategy and Execution

Strategy rarely fails in the boardroom. It fails on Tuesday morning, when a team decides what to work on next.

Most transformation programmes I have seen did not fail because the strategy was wrong. They failed because nothing in the daily work changed. The strategy deck was approved, the OKR tree was published, the roadmap was presented in a town hall. Then the next sprint was planned the same way as the one before: by urgency, by seniority, by whoever escalated loudest.

Research puts the share of strategic plans that fall short in execution somewhere between 60 and 90 percent (Hrebiniak, 2006; Candido and Santos, 2015). After more than a decade in enterprise transformation across FMCG, automotive R&D, automotive software and financial services, and several years of doctoral research on strategy implementation and OKRs, I no longer believe this is a motivation problem or a communication problem. It is a design problem. The gap between strategy and execution is a gap in the routines, artefacts and rhythms that connect the two.

The gap is not where we look for it

When a transformation stalls, the usual diagnosis points upward or outward. The strategy was too vague. Leadership was not aligned. People resisted change. The framework (SAFe, OKRs, Scrum at scale) was the wrong one.

These explanations share one assumption: that implementation is a single decision to execute, taken once, after which the organisation follows. In practice, implementation is not an event. It is an ongoing accomplishment, produced every week through recurring patterns of action: planning meetings, backlog refinement, check-ins, reviews. Organisational scholars call these patterns routines (Feldman and Pentland, 2003).

A routine has two sides. There is the routine as it is described, in process maps, playbooks and templates. And there is the routine as it is actually performed by people under time pressure. Strategy usually changes the first side. Transformation requires changing the second.

This is the space where enterprise transformation fails: not in formulation and not in the teams, but in the connective tissue between them. Below are five failure points I have observed repeatedly, and what helped close them.

Failure point 1: Planning and execution run on different systems

Planning routines produce artefacts that express intent: strategy decks, OKR trees, PI roadmaps. Execution routines run on other artefacts: Jira boards, sprint backlogs, team calendars. They also run on different selection criteria. In planning, the question is “what matters most?”. In execution, the question is “what is urgent, who is asking, and how senior are they?”.

When these two systems are only loosely coupled, ad-hoc requests win by default. Not because people ignore the strategy, but because nothing in the execution system tells them to prefer it. Debates about priorities then pivot on hierarchy instead of agreed rules, and silos generate rework.

In an 18-month OKR rollout I led in an HR function of about 250 people in an automotive software organisation, the turning point was a simple rule inscribed into the tooling: no work item could enter sprint planning without a field linking it to the current planning increment and a key result. “No PI/OKR tag, no sprint entry.” The decisive question in planning shifted from “who wants this?” to “which strategic priority does this serve?”.

The lesson: strategy becomes executable only when it is mirrored in the metadata of daily work. If your key results cannot be found in your backlog, they are not being implemented.

Failure point 2: Weak signals, no implementation climate

Introducing a practice is not the same as making it normal. People decide whether to take a new practice seriously by reading signals around them: Is this expected? Is it supported? Is it rewarded? When the answers are unclear, the practice survives only on paper.

Research on implementation climate (Klein and Sorra, 1996; Weiner et al., 2011) and on HR system strength (Bowen and Ostroff, 2004) helps explain why. A system sends strong signals when it is:

• Distinctive: visible, relevant and backed by people with legitimate authority.
• Consistent: the same message across tools, meetings, rewards and leadership behaviour.
• Consensual: senders, from senior leaders to team leads, agree on what the practice is for.

In my research I describe this as an OKR implementation climate: a shared perception that using OKRs is expected, supported and rewarded. Without it, organisations drift into two predictable failure patterns. The first is symbolic adoption: OKRs are written, reviewed once a quarter, and ignored in between. The second is KPI dominance: the old metric and bonus system keeps steering behaviour, and OKRs become a parallel reporting exercise.

The lesson: a framework does not create a climate. Signals do. Leadership attendance, consistent templates, aligned incentives and visible role models matter more than the quality of any single objective.

Failure point 3: Cadence breaks, and rival rhythms take over

A template, a dashboard or a planning rule only has authority when there is a recurring occasion to use it. A review that does not happen cannot enforce anything. This is why cadence is not administrative overhead. It is the mechanism that gives every other element its moment to work.

In the HR rollout, the cadence consisted of a 60-minute weekly cross-team operational review, a monthly check-in for mid-cycle replanning, and a two-day quarterly planning event with retrospective, prioritisation and joint planning. Senior management attendance at the quarterly events stayed at 95 percent or higher.

The strongest evidence for the role of cadence came from a failure. In October 2022 one monthly check-in was skipped. The effect cascaded: retrospectives slipped, mid-sprint additions increased and selection criteria softened. One missed meeting weakened the whole system for weeks.

A second threat was a rival rhythm. The parent company’s financial reporting cycle competed for the same teams’ time and attention. As long as two calendars claimed authority, the OKR cadence lost. The conflict was resolved only when the CHRO intervened and aligned the rhythms.

The lesson: protect the cadence before you optimise the content. And map every competing cycle (budget, bonus, reporting) before launch, because the strongest calendar wins.

Failure point 4: Structure blocks consensus before behaviour can

Some transformations fail despite competent, well-intentioned leaders. I analysed one such case: a cross-functional transformation in a card products division of about 170 people. The diagnosis was clear, the interviews were open, the intent was there. The transformation still did not take hold.

The reason was structural. One group of leaders owned the budget; another depended on it. Their interests were opposed on any practice that required shared ownership of priorities. No amount of coaching, training or workshops could produce agreement, because the governance architecture did not permit it. Ownership claims competed, and every new routine became a negotiation about money.

Comparing this case with the HR rollout showed something important. Consensus is not one success factor among several. It comes first. Where senders agreed, consistent cadence and visible role modelling followed. Where consensus was blocked, neither consistency nor visibility developed. This echoes Kerr’s (1995) classic warning about rewarding A while hoping for B, applied one step earlier: to the conditions that allow a shared climate to form at all.

The lesson: check budget and accountability symmetry before you start. If the people who must agree on priorities do not share a budget or joint accountability, redesign governance first. Behavioural interventions come second.

Failure point 5: Learning is discussed, but not inscribed

Most transformation programmes run retrospectives. Far fewer change anything because of them. Insights are captured on a board, discussed, and then lost when the next cycle starts from the same default.

Get natalia startseva’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Learning sticks only when it is written back into the artefacts people use. In the HR rollout, retrospective actions were carried over into the next cycle’s agenda by rule, and recurring insights were built into updated templates and checklists. Each cycle started from an improved baseline rather than from zero.

The failure case was equally instructive. The role of the change ambassadors was repeatedly identified as needing a formal job profile. It was never inscribed into the HR system. As a result, the knowledge about how the role worked depended on individuals and dissolved over time.

Learning loops were the most fragile element of the whole system. A governance setup can create the occasions for reflection. It cannot produce the reflective stance itself. That requires leaders who treat retrospectives as decision points, not as rituals.

The lesson: if an improvement is not reflected in a template, a rule, a role description or a tool configuration, it has not been retained.

What closes the gap: OKRs as a governance bundle

The most useful shift in my own thinking was to stop treating OKRs as a goal-setting technique and start treating them as governance. OKRs work when they are part of an interdependent bundle of three elements:

1. Selection rules that mirror strategic priorities into workflow metadata, so the backlog itself privileges strategy.
2. Readiness gates such as Definition of Ready and Definition of Done, which make prerequisites explicit before work starts or is declared finished.
3. Cadenced reviews that create recurring decision occasions, weekly, monthly and quarterly, with a rule that carries retrospective actions forward.

The bundle is carried by people and by things. People: leaders who show up, and a network of change ambassadors. In the HR case this was 21 internal ambassadors and five external facilitators, who could refuse a sprint entry by pointing to an agreed rule instead of personal authority. Things: templates, Jira validators, dashboards and calendars that make the rules hard to bypass.

When this worked, change followed a recognisable sequence:

1. Transparency and goal clarity came first. People could see the priorities and understand them.
2. Commitment and focus followed. Teams began to say no to work that did not serve a key result.
3. Cadence discipline stabilised the system. Of all mechanisms, this one proved to be the master mechanism.
4. Learning loops retained what worked, and remained the most fragile step.

It was not frictionless. I observed four recurring forms of resistance: resistance to the tool, resistance rooted in professional identity, claims of operational exceptionalism (“our work is different”), and fear of surveillance. None of them was solved by stricter enforcement. Each required adapting the bundle to how the work was actually organised.

A checklist for the space between strategy and execution

Before the next transformation kick-off, these questions are worth more than another strategy workshop:

• Can every key result be found as a tag or field in the team backlogs?
• Is there a rule that decides what enters a sprint, and does it reference strategic priorities?
• Do the people who must agree on priorities share a budget or joint accountability?
• Which competing cycles (budget, bonus, financial reporting) will compete with the new cadence, and who has the authority to align them?
• Is the cadence protected, including when it is inconvenient?
• Who carries the rules into daily work, and is that role formally described, resourced and recognised?
• Where does a retrospective insight end up: in a template, a rule or a role, or only on a board?

Enterprise transformation does not fail because organisations lack strategy. It fails because strategy stays in the documents that describe work instead of entering the systems that perform it. Closing that gap is less about inspiration and more about design: rules, rhythms, roles and artefacts that make the strategic choice the default choice.

Natalia Startseva is an organizational transformation coach, and an external PhD candidate at the University of Innsbruck researching strategy implementation, and OKRs.

References

• Bowen, D. E., and Ostroff, C. (2004). Understanding HRM-firm performance linkages: The role of the “strength” of the HRM system. Academy of Management Review, 29(2), 203–221.
• Candido, C. J. F., and Santos, S. P. (2015). Strategy implementation: What is the failure rate? Journal of Management and Organization, 21(2), 237–262.
• Feldman, M. S., and Pentland, B. T. (2003). Reconceptualizing organizational routines as a source of flexibility and change. Administrative Science Quarterly, 48(1), 94–118.
• Hrebiniak, L. G. (2006). Obstacles to effective strategy implementation. Organizational Dynamics, 35(1), 12–31.
• Kerr, S. (1995). On the folly of rewarding A, while hoping for B. Academy of Management Executive, 9(1), 7–14.
• Klein, K. J., and Sorra, J. S. (1996). The challenge of innovation implementation. Academy of Management Review, 21(4), 1055–1080.
• Weiner, B. J., Belden, C. M., Bergmire, D. M., and Johnston, M. (2011). The meaning and measurement of implementation climate. Implementation Science, 6, 78.