The Missing Layer Between Strategy and Software
Why companies struggle when they jump from strategy directly into implementation without designing the execution model.
There is a pattern I have seen in enough companies that it now reads as a single story. Leadership sets a strategy. The strategy is good. The team buys or builds the software the strategy seems to call for. A year later, the business is still moving work through spreadsheets, Slack threads, and weekly catch-ups. Handoffs are manual. Ownership is unclear. Nobody can answer “where is this work right now” without asking someone.
The software is not bad. The strategy is not wrong. Something in between is missing, and the missing thing is doing the harm.
Strategy is not execution
A strategy can describe what the company is choosing to do. The markets it enters. The customers it serves. The outcomes it is trying to produce. The investments it is willing to make. The bets it is unwilling to take.
What a strategy cannot do, on its own, is describe how work moves through the company. It does not say which team picks up the request first. It does not say what state the case is in when finance has to be involved. It does not say what a reviewer is looking at when they make a decision, or what they are allowed to decide.
Strategy is intent. Execution is behavior. The distance between the two is larger than most leadership teams treat it.
Software is not the operating model
The other half of the failure is the assumption that picking the right software closes the gap. Pick a CRM, a workflow engine, an ERP, a BPM tool, a low-code platform. Run an implementation. Now the strategy can land.
It does not, in this form, work. Software supports execution. Software does not, by being installed, produce:
- Clear workflow boundaries. Where one piece of work begins, where it ends, where it stops being someone else’s problem.
- Decision rights. Who is allowed to approve, reject, escalate, override.
- Data ownership. Which team owns the source of truth for the customer, the contract, the policy, the case.
- Validation rules. The criteria a piece of work has to satisfy at each stage before it is allowed to proceed.
- Role-specific interfaces. The views and tools each role needs to do their part of the work, not a single grid for everyone.
- Exception handling. What happens when the API fails, the document is missing, the customer changes their mind, the regulation moves.
- Operational visibility. The live picture of where work is, how long it has been there, and whether it is moving.
These have to be designed. The tool can enforce them. The tool cannot invent them.
The missing layer
Between intent and behavior is a layer most companies do not name. I call it the execution model. It is the formalized description of how the business actually operates. It is not a slide. It is not a process map. It is a small set of artifacts with real teeth.
The execution model has parts.
- Value streams. The few real flows of value the business runs. Not the org chart.
- Roles. Not job titles. The operational roles that act inside workflows. A reviewer, an approver, an escalation owner, an integration owner.
- Workflows. The executable units. Each with a clear beginning, a defined end, and the steps in between.
- Business objects. The things workflows operate on. The loan, the claim, the contract, the case. With lifecycles and explicit states.
- Interfaces. The views each role uses to do their work, and the contracts between systems.
- Rules. The conditions that govern routing, approvals, eligibility, pricing, escalation.
- Validation points. The places where human judgment is required, with input, decision shape, SLA, and authority.
- Metrics. What good looks like at each step. In-flight counts, time-in-state, decision rates, exception rates.
- Governance. Who can change which part of the model, and how those changes propagate.
Together, these define how the business is supposed to operate. They give the software something to encode and the people something to operate inside.
Why this matters
Without the execution model, every company still ends up with one. It is just unnamed and unmanaged.
The unnamed version is built out of spreadsheets, recurring meetings, Slack channels, SaaS tools no one has reviewed in eighteen months, custom scripts owned by one person, and a thick layer of tribal knowledge. It works, in the sense that the business still runs. It does not work, in the sense that it is invisible, fragile, and impossible to onboard into.
The cost shows up in predictable places. Onboarding takes a quarter instead of a month. Cross-team handoffs drop work. Audits become heroics. Strategic decisions get diluted because the leadership team and the operating team are reasoning from different mental models.
The pattern is not lack of effort. It is lack of a shared model. People work hard inside a structure they cannot see.
A Business Operating System
This is what I mean when I use the phrase Business Operating System. Not a single platform. Not a dashboard layer. A formalized execution model, structured enough to operate from and explicit enough to evolve.
It is the layer that connects strategy to reliable operational behavior. The strategy can change. The operating model is the thing that has to translate the change into new boundaries, new roles, new validations, new metrics. The tools encode the resulting model. The model is upstream of all of them.
This is what makes the difference between companies whose strategy ships and companies whose strategy slides. The companies that ship the strategy take the operating model seriously as its own artifact. They invest in it. They version it. They make changes to it deliberately, not by accident in a Jira ticket.
Closing
Strategy and software are visible. The leadership team sees the strategy. The engineering team sees the software. The layer between them is the one nobody owns by default, which is exactly why it tends to be where the trouble lives.
The gap between strategy and software is where most operational complexity hides. Name it, design it, version it, and most of the symptoms the company has been treating as separate problems start to dissolve.