The Future of Strategy Execution: Cascading Automation
Strategy execution is slow for reasons that are mostly administrative. Data is scattered across systems, someone assembles it by hand, the assembly takes a fortnight, and by the time it reaches a review the picture describes a month that has already closed. Decisions are then made on stale information, and the organisation concludes that it needs a better strategy.
Automation addresses that specific problem well. It addresses a different problem, the one of deciding what to do, not at all. Being precise about which is which is the whole of this subject, and most writing on it is not precise at all.
Where the time actually goes
Watch a quarterly review cycle in a large organisation and the effort divides into three parts.
Collection. Pulling numbers from finance systems, CRM, product analytics, project tools and spreadsheets. Reconciling definitions that differ between functions. Chasing the people who have not submitted.
Assembly. Building the pack. Formatting. Writing narrative around numbers. Circulating for correction and rebuilding.
Decision. The meeting itself, where trade-offs are made and resources move.
The first two consume the large majority of the effort and produce none of the value. The third produces all of the value and is routinely compressed because the first two ran late.
That is the case for automation, and it does not require any claim about artificial intelligence to be persuasive.
What automation actually does
Collection from source systems on a schedule, so nobody assembles a pack by hand.
Aggregation of measures against objectives, with one agreed definition per measure.
Variance detection against thresholds, so that attention goes to what has moved rather than to everything.
Prompting for check-ins, and the chasing that follows.
Drafting of status summaries from raw updates, for a human to correct rather than to write.
Surfacing of the things that quietly rot: objectives with no owner, initiatives with no update in six weeks, dependencies where one side has slipped and the other does not know.
None of it is glamorous. All of it returns several hours a week per manager and, more importantly, shortens the distance between something changing and somebody noticing.
What it must not do
Here the standard account of this subject goes wrong, and the error is worth stating plainly.
The common claim is that a strategic priority set in the boardroom should instantly update objectives, budgets and tasks across every affected unit. That describes automating a mechanical top-down cascade, which is the best-documented failure mode in goal-setting practice. Cascading fails because each level writes objectives to satisfy the level above rather than the customer, and because the people who know what is actually achievable are the ones operating the system rather than the ones two levels up.
Automating that does not fix it. It reproduces it faster and with better formatting.
The distinction that holds is between distribution and translation. Distribution should be automatic: when direction changes, every affected team should know within the hour, with the affected objectives flagged and a review scheduled. Translation, meaning what this team should therefore do differently, requires local knowledge no system holds and should stay with the people doing the work.
Four things should stay human for the same reason. Deciding priorities. Resolving trade-offs between functions. Moving budget. Judging whether an initiative that is behind should be supported, changed or stopped. Each requires context the system lacks and carries accountability a system cannot hold.
What has to exist first
Automation has prerequisites, and skipping them accounts for most disappointing implementations.
A defined objective model. Objectives with a single named owner, a measure and a target, held in one place. If objectives live in slide decks, there is nothing to automate.
Instrumented measures. Every measure needs a source system and an agreed definition. This step is where implementations stall, and the reason is rarely technical: two functions calculate active customers differently, both have reasons, and somebody has to decide. That argument has to be had before any tool can help.
A rhythm that already runs. Automation makes an existing cadence cheaper. It does not create one. An organisation with no functioning review cycle should build the cycle first, on a spreadsheet if necessary, and automate once it is stable.
The sequence is define, instrument, then automate. Reversing it produces an expensive record of a process nobody trusted.
Where AI genuinely contributes
The current generation of language models is good at reading, summarising and cross-checking, which is exactly the shape of the work around execution.
Useful applications: drafting a status summary from raw updates for a human to correct; extracting commitments and owners from meeting notes; flagging where a written update contradicts the underlying numbers, which is a common and rarely caught problem; and answering questions about the current position from the underlying data rather than from a static dashboard.
Every one of those produces output a person reviews. That is the boundary. An agent with authority to act, for example to reallocate budget without approval, creates a control problem long before it creates value, and the governance question arrives before the benefit does.
Governance
Automated recommendation introduces two risks that are easy to miss.
Automation bias. Recommendations get accepted because a system produced them and the reasoning is not visible. The safeguard is a traceable path from data to conclusion, and the expectation that anyone accepting a recommendation can explain it.
Diffused accountability. When a decision came from a tool, nobody owns the outcome. The safeguard is procedural: a named human accepts or rejects every consequential recommendation and that decision is recorded.
Neither is exotic. Both are the reason financial controls exist, applied to a newer category of system.
How it fails
- Automating an unclear strategy. If nobody agrees what the priorities are, faster distribution spreads the confusion.
- Tool before process. Software purchased to solve a definitional problem records the old process at higher cost.
- Dashboards nobody acts on. Visibility without a decision cadence changes nothing, and the dashboard becomes evidence that the problem was addressed.
- Inconsistent definitions. Where functions measure differently, aggregated numbers are quietly wrong and confidently presented.
- Resistance treated as a technical problem. Automated reporting makes performance much harder to obscure. Some of the resistance is about that, and no amount of training addresses it.
A realistic sequence
- Assess how execution runs today. Where objectives live, how measures are defined, what the review cycle actually is as opposed to what the policy says.
- Define the objective model. Owners, measures, targets, cadence. Argue the definitions out and write them down.
- Instrument the measures. Connect each to a source system. Expect this to take longer than planned and to surface disagreements that were previously invisible.
- Automate collection and reporting in one division. Nothing else yet.
- Run two or three cycles and fix what breaks. The first cycle will reveal that several measures were defined wrongly.
- Add detection and prompting once the data is trusted.
- Extend to other divisions, expecting each to have its own definitional arguments.
- Introduce assistive AI last, where the data is reliable and the rhythm is established.
A first working loop in one division is one to two quarters, most of it data plumbing rather than configuration. Enterprise coverage takes considerably longer. Timelines quoted in weeks describe a software installation rather than a change in how an organisation operates.
Whether it is worth it
The discipline underneath, objectives with owners, instrumented measures, a regular review, is worth having at any size and matters more than any tool.
The automation earns its cost when the manual burden of collection and aggregation is genuinely large, which in practice means several hundred people or a portfolio spread across many systems. Below that threshold, a well-maintained shared document and a disciplined weekly meeting deliver most of the benefit at none of the cost, and saying so is more useful than selling the alternative.
The point
Automation makes strategy execution faster by removing the administrative load between something changing and somebody noticing. It does not make the decisions better, and the claim that it can is the one to be sceptical of.
Automate collection, aggregation, detection and prompting. Distribute direction instantly and leave translation local. Keep priorities, trade-offs, budget and stop-or-continue judgements with people who can be asked to explain them. Define and instrument before automating anything.
At go:lofty we install strategy operating systems and the automation around them, which means we sell this work and have an interest in it. The honest version is that most of the benefit comes from the discipline rather than from the software, and the software is worth it once the discipline exists.
