Digital Transformation Failed Because Humans Became the Glue Layer
Most digital transformation programs started with a reasonable goal: reduce manual coordination and shorten the feedback loops that slow enterprises down. The problem is that the enterprise itself never organized to support it. Supporting technology become more instrumented while staying just as messy underneath and the gap between these 2 things is where most transformation programs quietly died. Ambiguous requests still needed someone to interpret them while fragmented ownership still needed someone to navigate it. Teams using different language for the same concepts still needed someone to translate between them. In other words, exceptions, which were always the default operating condition rather than the edge case anyone planned for, still needed someone to handle them. That someone was never reflected in the project plan and they showed up anyway because the work had to get done and they became the permanent glue holding together systems that were never designed to talk to each other.
The uncomfortable reality that most transformation post-mortems skip is that the human translation layer was never a temporary patch waiting to be automated away. It was load-bearing infrastructure and most programs treated it like a rounding error. The irony that rarely gets named is that a lot of transformation initiatives created more coordination overhead than they removed. We automated the workflows and then hired entire teams to maintain the automation, manage the exceptions the automation could not handle and translate between system outputs and the humans who needed to act on them.
The glue layer became more expensive and harder to see on an org chart.
Quarterly Planning Is the Clearest Example
The process looks straightforward on paper: finance sets budget parameters, product submits roadmap priorities, engineering estimates capacity and leadership aligns on what gets funded. In practice none of those inputs arrive in a compatible format, on the same timeline or with shared definitions of what words like “priority” and “capacity” actually mean in context. Finance is measuring headcount and spend, engineering is measuring velocity and risk and product is measuring strategic value.
Nobody has agreed on a common language and the planning system assumes they have.
So someone becomes the translator.
Usually a senior PM or a chief of staff with enough organizational context to navigate the ambiguity without causing a political incident. They spend weeks pulling inputs from 5+ different systems, reconciling numbers that do not match because different functions are measuring different things, chasing down missing context from teams who submitted a slide deck instead of a structured request and manually building the single consolidated view that leadership needs to make a decision. By the time the new view exists the inputs have already shifted and the process restarts.
Every system involved is doing exactly what it was designed to do. The failure lives at the boundary between systems, in the handoff where structured data runs out and human judgment takes over. This boundary is where the actual work lives and it is the part that no workflow tool, project management platform or data warehouse ever solved because none of them were built to handle the translation problem. In other words, they were built to handle storage and routing which was already mostly solved before the transformation program started.
What LLMs Made Possible
LLMs have not fixed the messy enterprise nor have they rewritten org charts, clarified ownership or made finance and engineering agree on definitions. What they did is more specific: they made portions of the translation layer automatable for the first time because they can take messy, inconsistent input and produce usable structure from it without requiring every upstream system to speak the same schema first.
They can map language between teams who use different vocabularies for the same concepts. They can pull unstructured context from a slide deck, an email thread and a documentation page and surface what is actually relevant to the decision at hand. They can carry context from one system into another in a way that deterministic workflow tools never could because deterministic tools require clean inputs and the enterprise does not produce clean inputs.
In the cross-functional planning context, an LLM-enabled system can run the same underlying flow the senior PM was running manually. It extracts inputs from wherever they live: budget documents, roadmap submissions, capacity models, leadership asks in whatever format they arrived. It transforms them by normalizing language, flagging missing information and identifying where submissions are inconsistent with each other in ways that will cause problems downstream. It loads a reconciled view into the working set so the planning conversation can start from a shared baseline rather than from a blank page and a stack of conflicting spreadsheets. It routes flagged conflicts and missing inputs back to the right owners with enough context that they can respond without scheduling another meeting to explain what is actually needed.
The execution pattern is nearly identical to what the senior PM was doing. The difference is that a language model can run the translation step across unstructured and inconsistent inputs at a scale and speed no single person can match, which means the person who was spending 6+ weeks building the consolidated view can spend that time on the decisions the view is supposed to enable.
Where It Breaks
Seeing a demo of an LLM reconciling planning inputs in hours instead of weeks creates the impression that the coordination problem is solved. The work moved again, the same way it moved during the original transformation programs. You traded human glue for a new set of responsibilities that most organizations are not equipped for yet and the gap between the demo and the production reality is where the budget gets spent and the trust gets lost.
Ownership still has to be explicit and formally assigned because an LLM that routes a planning conflict back to the wrong team because ownership was never defined does not save time. It produces a faster version of the same stall and it does so with enough surface confidence that the mistake takes longer to catch than it would have when a human made it.
The translation the model is doing is probabilistic, meaning it is making inferences based on context rather than determinations based on ground truth. When the system reconciles 2 submissions that use different definitions of capacity it is guessing at the right answer using available signal. Consequential decisions still need human validation and deterministic systems still need to hold the source of truth underneath the model layer.
The long tail of exceptions shifts from manual handling by someone with organizational context to policy design by someone who has to anticipate edge cases before they occur. Every judgment call the senior PM used to resolve through accumulated knowledge and relationship capital now has to be encoded in advance as an escalation rule or a fallback path. Most organizations discover how hard that is after they have already deployed and started hitting the cases nobody thought to plan for.
Bounded actions, clear escalation paths, logging and audit trails, evaluation against real planning cycles and rollback paths for when the system gets it wrong are the actual deliverables of an AI-enabled planning capability.
Skip those controls and you have a faster way to produce confident errors at scale and a much harder time explaining what went wrong when it does.
The Shift
Classic automation was good at executing steps and struggled at the handoffs between them. LLMs are unusually capable at handoffs because they can read what a person meant and restate it in the vocabulary the next system or team expects.
This is the actual capability gain and it is worth being precise about because the distinction matters when you are deciding where to invest and what to instrument. We now have a new interface between workflows which changes what is possible at the boundaries without necessarily changing what happens inside each step.
Closing
Digital transformation stalled when humans became the permanent glue because nobody designed a system to replace what they were actually doing. Most programs saw the manual steps and automated them. Nobody accounted for the translation work happening between the steps and that work did not go away. It became invisible overhead that showed up as coordination costs, meeting load and senior people spending their time reconciling spreadsheets instead of making the decisions the reconciled view was supposed to enable.
LLMs change what the translation is made of and at what scale it can operate. Build the controls around that capability and you get real leverage. Skip the controls and you get the same coordination failure you had before, running faster and harder to debug. The organizations that figure this out will not be the ones with the most impressive demos. They will be the ones that redesigned ownership, escalation and policy around a system that finally handles the handoffs.