The Operating Model Every Enterprise Services Org Is Missing
By Rahul Jindal · 8 min read
Walk into the operations function of any large enterprise — HR, IT, Finance, Customer Operations — and you will find roughly the same five capabilities, run as five disconnected silos. There is a strategy team that publishes a deck once a quarter. A transformation team running projects nobody can list from memory. An automation team building bots in a corner. A content team that publishes intranet pages. A knowledge team that owns the help center. Five org boxes. Five budgets. Five sets of metrics. No shared model of the work.
The dysfunction is not that any individual team is bad. They are usually staffed with capable people. The dysfunction is that these are the wrong unit of analysis. They are not five teams. They are one system. STACK names that system.
The five capabilities, named correctly
- Strategy. Deciding which problems are worth solving and in what order. The output is not a deck. The output is the prioritization that governs everything below.
- Transformation. The portfolio of in-flight changes to how the work is done. If Strategy picked the right problems, Transformation is the muscle that actually changes the workflow.
- Automation. Both first-party (your bots, your agents) and third-party (the automation embedded in the SaaS you buy). Most orgs only manage the former and are surprised by the second.
- Content. The articulated answers your users see — policy pages, FAQs, onboarding flows, the words a chatbot reads from. This is what your AI agents will be grounded in tomorrow.
- Knowledge. The internal substrate that makes Content possible — the rules, exceptions, decision rights, and tribal expertise. Knowledge is what Content is compiled from.
“These are not five teams. They are one system. The org chart is the bug, not the architecture.”
Why running them as silos is now an existential bug
Five years ago, you could get away with the silos. The cost was a steady-state inefficiency that nobody bothered to measure. Knowledge stayed locked up because Content did not pull from it. Automation built the wrong bots because Strategy never told them what to prioritize. Transformation ran projects that landed in a workflow that Content had not updated. Annoying, but tolerable.
AI agents collapse the tolerance. An agent grounded on stale or fragmented Content makes confident wrong decisions. An automation built without the Knowledge layer cannot handle the exceptions that make up most of real work. A Transformation that ships before Content catches up trains your users to ignore the help system. The five capabilities are now coupled whether you like it or not. You either design them as one system or you watch the coupling produce failures you cannot trace.
What changes when you treat STACK as one system
- Prioritization actually flows. Strategy's priorities show up in what Transformation works on, what Automation builds, what Content gets refreshed, and what Knowledge gets captured. Misalignment becomes visible in days, not quarters.
- Knowledge becomes a build target, not a wiki. When Content and Automation both depend on Knowledge being correct, Knowledge stops being a side project. It becomes the substrate the rest of the system runs on.
- Third-party automation gets governed. Most enterprises have no map of the third-party AI quietly showing up inside their SaaS tools. STACK forces this onto the same governance surface as your first-party agents.
- Headcount math changes. Once the five capabilities are one system, you stop hiring another transformation PM and start hiring a knowledge engineer or a content ops lead. The bottleneck moves to where the leverage is.
“The bottleneck moves to where the leverage is. Headcount stops following the org chart and starts following the system.”
Where to start
The cheapest first move is also the most uncomfortable one: name an owner for the system. Not for any one of the five capabilities — for the integration. Someone whose job is the joints, not the boxes. In most enterprises this person does not exist, which is precisely why the silos persist.
Once that role exists, the rest follows. Shared roadmap. Shared metrics. A single review of what the five capabilities together are doing for the function they serve. The work does not disappear. The waste between the five teams does.
Related Insights
See the full STACK operating model
The integrated operating model for enterprise services orgs. Five capabilities. One system.
Explore the STACK Framework