Every January, the same ritual: new strategic priorities, a town hall, a slide with three bold words on it. And every February, the same quiet observation: daily work runs exactly as it did in December. This edition of Two for One is about why that happens — and why the problem is not that people ignore the strategy, but that the old strategy is still built into the processes they work in every day.
Strategy and processes live on different clocks. Priorities are reviewed annually, increasingly quarterly; a leadership team can change direction in a single offsite. Processes change on project time — a workflow adjustment takes months, a new approval logic needs IT tickets, a changed KPI needs a reporting cycle to prove itself. So every strategy shift opens a gap: the direction is new, but the machinery is old. And the machinery is remarkably persistent, because nobody owns the job of retiring it.
The deeper reason the gap matters is that strategy and process do not compete on equal terms. Strategy is communicated — in slides, speeches, and OKR documents. Processes are enforced — in approval thresholds, form fields, system defaults, escalation paths, and bonus formulas. When a stated priority and an encoded rule disagree, the rule wins, every day, in thousands of small decisions. An employee who has heard "speed is our priority now" will still wait for the third signature, because the workflow demands it and the strategy slide does not sit in the workflow.
Process alignment, in other words, is not a communication problem. It is a structural one — and it responds to structural treatment. Two levers close the gap: an explicit review that translates every priority shift into concrete process changes, and a process design that can absorb changing priorities without a rebuild. We will take them in turn.
Look closely at any established company and you can read its strategic history in its processes, like growth rings in a tree. The approval matrix still reflects the cost-cutting phase of three years ago, when every expense above five hundred euros needed a director. The sales process still rewards new-customer acquisition from the land-grab era, although the stated priority has been retention and expansion for two years. The reporting landscape still measures delivery volume from the scale-up phase, while the strategy now talks about quality and margin.
None of this is anyone's failure. Each of those rules was the right answer to a real problem — once. The trouble is that processes, unlike slides, do not expire. A priority that was never explicitly decommissioned keeps executing itself: the bonus formula keeps paying for the old behaviour, the workflow keeps routing cases down the old path, the monthly report keeps directing management attention to the old question. The organisation is not ignoring the new strategy. It is faithfully executing the previous one, because that is the one that got encoded.
The people in the middle learn the real lesson quickly. When announced priorities and enforced processes diverge, employees stop treating strategy announcements as instructions and start treating them as weather — something that passes over the organisation without changing how anything works. That cynicism is rational, and it is expensive: by the third unaligned strategy cycle, even a genuinely important shift gets absorbed with a shrug. We saw a close cousin of this pattern in our edition on decisions that don't survive the meeting — decisions and priorities share the same failure mode when nothing translates them into the operating fabric.
It is tempting to file this under culture — "our people resist change" — and reach for behavioural fixes: more communication, more workshops, more posters. The BPM view is less flattering and more useful: this is a structure problem, not a behaviour problem. People are doing exactly what the system asks of them. Every department is compliant with its processes; that is precisely why the misalignment is invisible in every report.
The costs are real even though no line item carries them. Strategic initiatives stall in execution, because the processes that would have to carry them still optimise for something else — the initiative gets a project team and a steering committee, while the daily volume keeps flowing down the old path. Workarounds multiply, because teams that do take the new priority seriously have to work against their own tooling; the new priority runs as an informal shadow process on top of the official one, with double effort and no visibility. And management steers blind, because the KPI landscape still measures the old priorities: if the strategy says retention but every dashboard reports acquisition, nobody can see whether the strategy is failing until the annual numbers arrive.
Perhaps the highest cost is the compound one: each unaligned cycle trains the organisation to ignore the next announcement. Strategy execution capability — the thing every leadership team says it wants — erodes precisely at the interface where priorities should become process changes and quietly do not. That interface is where our two levers operate.
The first lever is a discipline, not a tool: no strategic priority is considered adopted until it has been translated into named process changes — and equally important, until the processes serving the old priority have been explicitly changed or retired. The mechanism is a strategy-to-process review that runs on the same cadence as the strategy itself.
The review answers four questions for each new or changed priority. Which end-to-end processes carry this priority — where in the daily flow of work will it live or die? Which encoded rules currently contradict it — approval thresholds, routing logic, SLAs, bonus and target formulas, mandatory fields, report definitions? What concretely changes, with an owner and a date for each item? And what gets deprioritised — which existing rules, reports, and checks were serving the previous priority and should now be loosened or removed, so the new priority is not simply stacked on top of everything that came before?
That last question is the one organisations skip, and it is the one that matters most. Priorities are additive in slide decks and zero-sum in daily work. If "speed" arrives and the risk-era approval matrix stays, the organisation has not gained a priority; it has gained a contradiction, and the employees have gained the job of resolving it case by case. An honest review produces a retirement list, not just a to-do list.
The output of the review is deliberately unglamorous: a short process backlog — five to fifteen concrete changes, each with an owner and a deadline — reviewed at the next strategy checkpoint like any other commitment. This is the difference between announcing a direction and adopting one. A priority that survives this review exists; one that never went through it is, operationally speaking, a rumour.
The first lever fixes the translation; the second fixes the machinery, because even a disciplined review is painful if every priority shift requires rebuilding processes from scratch. Processes age better when the things that change often are designed as parameters rather than poured in concrete. Approval thresholds, routing rules, priority classes, target values: if these live as explicit, owned configuration, a priority shift becomes an afternoon of governed changes instead of a six-month project. The process structure stays stable; its settings follow the strategy.
Modularity has a second, less technical ingredient: each of these parameters needs a named owner with the authority to change it, and a lightweight, documented path for doing so. In many organisations the bottleneck is not the IT change itself but the discovery of who may decide it — by the time the question is answered, the quarter is over. A process landscape that can follow strategy is one where the adjustable parts are known, listed, and owned in advance.
And then comes verification, which is where most alignment efforts end prematurely. A changed rule is not yet a changed reality: the workflow may allow the fast path while everyone still routes cases down the familiar one. This is where process mining closes the loop. Because it reads the actual flow of cases from system data, it shows whether the new priority is visible in operations — whether expedited paths are actually used, whether retention cases now move faster than acquisition cases, whether the deprioritised checks actually stopped consuming time. Comparing the months before and after the shift turns "we implemented the strategy" from a claim into a measurement. It also exposes the local frictions that every shift produces — the team whose part of the flow still runs on old settings, a pattern we dissected in why the system suffers when every team optimizes locally.
The test principle that summarises both levers: a priority is real only when it shows up in the process data — not in the announcement, not in the handbook, and not in the kickoff workshop. If the flow of daily cases looks the same three months after the strategy changed, the strategy has not changed.
If you compared your current approval thresholds, bonus formulas, and mandatory reports against your current strategy slide, how many of them would turn out to serve a priority you officially abandoned?
When your leadership team last announced a shift in priorities, which concrete process rules changed in the following ninety days — and who could list them?
What has your organisation explicitly deprioritised in the last year — not by saying it less, but by removing a rule, a report, or a check that used to enforce it?
If speed, quality, or retention is your stated priority, would a process mining analysis of last quarter's cases show it — or show the opposite?
How many strategy cycles has your organisation been through in the last five years, and what did the daily work of a caseworker, a buyer, or a sales rep actually change in that time?
Who in your organisation owns the interface between strategy and processes — and if the answer is "everyone", is it anyone?
Strategies do not fail in the boardroom; they fail in the approval matrix, the bonus formula, and the monthly report — the places where the previous strategy still lives. Announcing a new priority while leaving the old machinery running is not strategy execution; it is a request for cynicism. The fix is structural and refreshingly concrete: translate every priority shift into an explicit, owned list of process changes and retirements, design the frequently changing parts of your processes as governed parameters, and verify in the case data — not in the slide deck — that the shift actually reached daily work. Take your newest strategic priority and ask one question this week: which three process rules would have to change for this priority to be real? If nobody can name them, that is the finding.
Because they live on different clocks: priorities can change in one leadership offsite, while process changes need projects, IT tickets, and reporting cycles. Worse, nobody usually owns the job of retiring rules that served the old strategy — so approval thresholds, bonus formulas, and reports keep enforcing yesterday's priorities long after the slides have moved on.
A recurring discipline that translates every strategic priority shift into named process changes: which end-to-end processes carry the priority, which encoded rules contradict it, what changes with an owner and a date — and which old rules, reports, and checks get retired. A priority only counts as adopted once this translation has happened.
Because priorities are additive on slides but zero-sum in daily work. If a new priority arrives and the rules serving the old one stay in place, employees inherit a contradiction they must resolve case by case. Removing or loosening outdated checks, reports, and thresholds is what makes room for the new priority to actually operate.
Process mining reads the real flow of cases from system data, so it shows whether a strategic shift is visible in operations: whether new fast paths are used, whether prioritised case types actually move faster, whether retired checks stopped consuming time. Comparing periods before and after a shift turns strategy execution from a claim into a measurement.
By turning the frequently changing elements — approval thresholds, routing rules, priority classes, target values — into explicit, owned configuration instead of hard-wired structure. Each parameter needs a named owner and a lightweight change path. Then a priority shift becomes an afternoon of governed adjustments rather than a six-month rebuild.