Why Enterprises Fail Under Automation

Most enterprise IT failures aren’t caused by bad tools or bad engineers.

They happen because systems are making decisions, and no one ever stopped to decide who’s allowed to make them.

That’s it.
That’s the problem.

It isn’t new.
It isn’t just AI.
And it shows up long before anything actually breaks.

Automation Always Brings an Operating Model With It

By the time an organization realizes it has an operating model problem, it already has one.

It’s just undocumented.

Judgment already exists inside the enterprise. You can see it in platform defaults, security exceptions, budget thresholds, disaster recovery runbooks, and escalation paths. Decisions are being made all the time — usually for good reasons — but almost always implicitly.

What enterprises don’t lack is judgment.

They lack a clear place for it to live.

Automation makes this harder to ignore. Execution gets faster right away. Authority doesn’t. Accountability only shows up when something goes wrong — a cost spike, an outage, a failed audit, a migration that looked fine on paper.

When that happens, organizations don’t calmly redesign their systems.
They react.

Governance tightens.
Platforms get centralized.
Product teams get blamed — or suddenly empowered.
Authority moves. Then it moves again.

That back-and-forth isn’t random. It’s predictable.

Why I Wrote This

I’ve watched this pattern repeat across large enterprises — in platform exits, cloud migrations, AI operating model debates, and post-incident cleanups.

The story is always the same:

• Automation works

• Responsibility gets fuzzy

• Accountability spreads out

• And after something breaks, the org whipsaws trying to regain control

Most people explain this as an execution problem.

It isn’t.

It’s a decision authority problem.

This paper lays out a model for understanding where decision authority actually lives when systems act on their own, how accountability is (or isn’t) anchored, and why misalignment leads to the same failures over and over again.

This isn’t a how-to guide.
It doesn’t tell you which model to choose.

It does something more basic:

It makes decision authority visible — so you can design it on purpose instead of discovering it during an incident review.

How to Read What Follows

What comes next is a conceptual paper. It’s meant to be precise, not breezy.

It explains:

• why authority quietly shifts during automation

• why inherited authority is the default

• why governance breaks down in complex systems

• why organizations oscillate after incidents

• and why accountability has to move with authority if you want stability

If you’ve lived through repeated reorgs after outages, cost overruns no one wants to own, or platform decisions that “made sense at the time,” this will feel familiar.

That’s intentional.

What Comes Next

This paper establishes the model.

In follow-up posts, I’ll apply it to real enterprise situations — platform exits, cloud migrations, replatforming efforts, FinOps failures, and incident response — to show how the same structural issues show up long before problems become obvious.

For now, the goal is simple:

Name the problem clearly enough that it can finally be addressed deliberately.

(Paper begins below)

Download as PDF

The Decision Authority Placement Model (DAPM)

Abstract

As enterprise IT systems increasingly automate behavior, organizations experience recurring failures that are often misattributed to tooling, skills gaps, or governance immaturity. This paper introduces the Decision Authority Placement Model (DAPM), a technology-agnostic framework for understanding where decision authority resides and how accountability is anchored when systems act without direct human intervention.

DAPM argues that automation is routinely adopted for its execution benefits while decision authority and accountability placement remain implicit until failure forces them into view. This displacement produces a predictable gap between authority and responsibility, leading to instability, blame diffusion, and organizational oscillation.

By distinguishing between unplaced (inherited) authority and intentional placement modes—and by identifying authority oscillation as the dominant response to misalignment—DAPM explains why structurally similar failures recur across virtualization exits, cloud migrations, replatforming efforts, storage modernization, and autonomous systems adoption.

The model further demonstrates that decision context constrains authority placement viability: governance-coupled authority is structurally non-viable in complex domains, where decision frequency and emergence outpace human escalation. DAPM does not prescribe a preferred operating model, but asserts a necessary condition for stability: decision authority and accountability must be explicitly placed and aligned.

By formalizing decision authority and accountability as first-class design concerns, DAPM provides a durable lens for anticipating failure modes and designing enterprise systems that remain coherent under automation and stress.

1. Introduction

Enterprise IT has undergone repeated waves of abstraction: virtualization, cloud computing, platform engineering, and most recently AI-enabled systems. Each wave promises reduced operational burden through automation. Yet enterprises consistently report similar failure patterns during and after major technology transitions—loss of control, governance backlash, cost unpredictability, and declining trust in platforms.

These failures are commonly framed as execution problems: insufficient tooling, inadequate observability, immature processes, or organizational resistance. This paper advances a different claim: many enterprise IT failures are the result of poorly understood or unintentionally altered decision authority, not technical incapacity.

The Decision Authority Placement Model (DAPM) provides a language and analytical structure for examining this phenomenon across enterprise systems, independent of specific technologies or vendors.

2. Problem Statement

Across enterprise IT domains, systems increasingly act on behalf of organizations by making continuous runtime decisions involving cost, performance, availability, security, and compliance. While execution is automated, authorization to make these tradeoffs is rarely examined explicitly.

This displacement occurs for a consistent reason: automation is adopted for its execution benefits, while decision authority placement remains invisible until failure forces it into view. Execution improvements are immediate and measurable; authority placement is silent and deferred. As a result, enterprises routinely change how work is executed without redesigning who is authorized to decide at runtime.

When failures eventually surface, organizations respond reactively—reasserting governance, centralizing platforms, or delegating authority ad hoc—rather than addressing the underlying placement gap. DAPM exists to explain this mechanism and to enable authority placement to be treated as a proactive design concern rather than a post-incident forensic exercise.

3. Definition: Decision Authority Placement Model (DAPM)

The Decision Authority Placement Model (DAPM) is a framework for understanding who is authorized to make tradeoffs at runtime—such as cost, risk, performance, availability, and policy—when enterprise systems act without direct human intervention.

DAPM focuses on the placement of decision authority: where it is deliberately assigned, implicitly inherited, or accidentally displaced across platforms, governance functions, and product teams as systems automate behavior.

Key properties of the model include:

• Technology agnosticism
• Directional neutrality (applies across migrations and reversals)
• Separation of execution from authority
• Emphasis on accountability and intentional design

4. Conceptual Foundations

4.1 Decision Authority vs. Execution

Historically, enterprise systems executed decisions made by humans. As automation increased, systems began making decisions themselves, often continuously and at machine speed. DAPM distinguishes execution capability from decision authority, arguing that automation without explicit authority placement leads to organizational instability.

4.2 Placement as an Act of Design

The term placement is intentional. It implies that decision authority is not an inherent property of a system, but a design choice that carries accountability. Authority may be:

• Deliberately placed
• Implicitly inherited from platforms
• Accidentally displaced during transitions

DAPM asserts that unexamined placement is the root cause of many enterprise failures.

4.3 Accountability Anchor

Decision authority placement is only half of the structural equation. Enterprises must also determine where accountability is anchored for the outcomes of automated decisions.

The Accountability Anchor is the organizational locus that explicitly accepts responsibility for the consequences of runtime decisions, including financial loss, operational disruption, security exposure, and regulatory impact.

In stable systems, decision authority placement and accountability anchoring are aligned. In failing systems, authority moves faster than accountability, resulting in responsibility diffusion, blame shifting, and post-incident paralysis.

4.4 The DAPM Gap

The DAPM Gap describes the distance between where decision authority is placed and where accountability is anchored. When this gap widens, organizations experience predictable failure dynamics:

• Decisions are made without clear ownership
• Incidents trigger organizational conflict rather than resolution
• Governance responses focus on control rather than correction

DAPM predicts that authority placement without accountability anchoring produces instability equivalent to unplaced authority, even when decision logic is technically sound.

5. Decision Authority Conditions and Intentional Placement Modes

DAPM distinguishes between decision authority conditions and decision authority placement modes. This distinction is critical. Not all observed authority structures in enterprise systems are the result of intentional design. In practice, most organizations operate in a state where decision authority exists, but has not been deliberately placed.

5.1 Unplaced (Inherited) Decision Authority

Unplaced authority describes the default condition in enterprise IT, where no actor has explicitly decided where decision authority should reside. Instead, authority is inherited from upstream platforms, vendor defaults, or historical operating assumptions.

In this condition:

• Systems make runtime tradeoffs because they must
• Decision authority is assumed rather than assigned
• Accountability remains organizational, while authority is technical

Unplaced authority is not an operating mode. It is the absence of placement. It explains why organizations often struggle to explain system behavior, defend outcomes, or assign responsibility following incidents. Most enterprise IT failures occur in this condition.

DAPM asserts that meaningful operating models only emerge once organizations move from inherited authority to intentional placement.

5.2 Intentional Decision Authority Placement Modes

Once decision authority is explicitly placed, organizations tend to converge on one of three recurring placement modes. These modes are descriptive rather than prescriptive; none is inherently superior. Failures arise when a mode is adopted implicitly, applied inconsistently, or misaligned with accountability structures.

Platform-Led Authority

In a platform-led placement, decision authority is embedded within a centralized system that continuously evaluates and enforces runtime tradeoffs. The platform is authorized to decide outcomes related to efficiency, availability, performance, and cost within defined bounds.

This mode provides consistency and scale, but concentrates authority within technical systems that may be organizationally distant from business accountability.

Governance-Coupled Authority

In a governance-coupled placement, systems automate execution, but decision authority is escalated to human review under predefined conditions. Automation operates until thresholds are exceeded, ambiguity is detected, or risk criteria are met.

This mode prioritizes defensibility and control, but limits scalability and often reintroduces latency and bottlenecks under load.

Product-Aligned Authority

In a product-aligned placement, decision authority is deliberately delegated to product or service teams, bounded by explicit guardrails. Teams are authorized to make runtime tradeoffs within constraints defined by platform and governance functions.

This mode scales well and aligns authority with outcomes, but requires mature teams and strong shared primitives to avoid fragmentation.

5.3 Making Placement Explicit: The DAPM Authority Matrix

The preceding sections describe how decision authority may be placed. In practice, enterprises require a concrete way to make these placements explicit across decision domains. To address this, DAPM introduces the Authority Matrix: a conceptual artifact that captures where decision authority resides, where accountability is anchored, and how conflicts are resolved.

The DAPM Authority Matrix is not an access control list or a permissions system. It does not specify who may execute actions. Instead, it documents who is authorized to decide when runtime tradeoffs must be made, and who accepts responsibility for the outcomes of those decisions.

Decision Domain	Authority Placement	Accountability Anchor	Override Path	Typical Failure Signature
Cost / Spend Control	Platform-led	Finance / Executive	Governance escalation	Surprise cost spikes, blame diffusion
Performance & Scaling	Platform-led	Product Team	Platform configuration	Over-provisioning, defensive architectures
Availability / Failover	Product-aligned	Product Owner	Platform backstop	Incident ownership disputes
Security Enforcement	Governance-coupled	Risk / CISO	Human escalation	Bottlenecks, post-incident crackdowns
Compliance / Audit	Governance-coupled	Legal / Compliance	Human review	Velocity collapse
Reliability / SLOs	Product-aligned	Product Team	Guardrail breach	Inconsistent risk posture

DAPM does not prescribe which authority placement is correct for any given decision domain. Its requirement is more fundamental: that authority placement, accountability anchoring, and override expectations be made explicit and internally consistent. When this matrix is absent or incomplete, organizations default to inherited authority and discover misalignment only after failures occur.

6. Failure Modes as Placement Mismatches

6.0 Authority Layering and Boundary Friction

In large enterprise systems, decision authority is rarely placed uniformly. Different layers of the stack often adopt different authority placement modes simultaneously. This authority layering is not inherently problematic; it reflects legitimate differences in risk, decision frequency, and domain expertise across layers.

For example, a system may employ platform-led authority for resource scaling, governance-coupled authority for regulatory controls, and product-aligned authority for reliability or user experience. Each placement may be locally rational.

Failures emerge at the boundaries between layers when decision authority and accountability are not aligned across those boundaries. Authority layering introduces friction when:

• A decision in one layer triggers consequences governed by a different authority model
• Accountability is anchored at a layer that lacks decision authority
• Escalation paths cross layers with incompatible decision tempos

DAPM predicts that boundary friction, not individual placement choices, is the dominant source of instability in layered systems. Authority oscillation often originates at these seams as organizations attempt to reconcile conflicting authority models after incidents.

Authority layering therefore requires explicit boundary design. Without it, enterprises experience cascading failures even when each layer appears well-governed in isolation.

6. Failure Modes as Placement Mismatches

DAPM predicts failure not as a function of specific technologies, but as a consequence of mismatches between where decision authority is located, how it was placed, and where accountability is expected to reside. When authority location, placement intent, and accountability expectations diverge, enterprises experience recurring and structurally similar failure patterns.

This section reframes common enterprise IT failures as predictable outcomes of decision authority misalignment.

6.1 Unplaced Authority with Organizational Accountability

Condition: Decision authority is unplaced (inherited from systems or platforms), while accountability remains organizational.

Prediction:

• Systems behave correctly but unpredictably
• Incidents are difficult to explain or defend
• Responsibility becomes diffuse following failures

Explanation: In inherited authority conditions, systems make runtime tradeoffs without any actor having explicitly accepted responsibility for those decisions. When outcomes are questioned, organizations discover that authority was never intentionally placed, leaving no clear owner.

6.2 Platform-Led Authority with Product-Aligned Accountability Expectations

Condition: Decision authority is embedded within a centralized platform, while product teams are expected to own outcomes.

Prediction:

• Loss of trust in platform behavior
• Defensive application architectures
• Over-provisioning and redundancy

Explanation: When platforms retain authority but products bear accountability, teams compensate by bypassing or insulating themselves from platform decisions. This results in architectural sprawl and reduced efficiency, even when platform capabilities remain intact.

6.3 Governance-Coupled Authority Under Continuous Automation

Condition: Decision authority is escalated to governance functions while systems continue to operate continuously and at scale, particularly in domains characterized by high uncertainty or emergence.

Prediction:

• Escalation overload
• Bottlenecks and delays
• Reintroduction of manual controls

Explanation: DAPM predicts that governance-coupled authority is structurally non-viable in complex domains. As decision frequency increases and causality becomes nonlinear, human escalation cannot keep pace with system behavior. Under these conditions, governance-coupled authority inevitably collapses into either unplaced authority or authority oscillation.

6.4 Product-Aligned Authority Without Shared Guardrails

Condition: Decision authority is delegated to product teams without consistent constraints or shared primitives.

Prediction:

• Fragmentation of behavior across systems
• Inconsistent risk posture
• Difficulty enforcing enterprise standards

Explanation: Product-aligned placements require strong guardrails to function. Without them, authority decentralizes faster than accountability can be reconciled, resulting in divergent interpretations of acceptable tradeoffs.

6.5 Authority Oscillation as a Systemic Response

Authority oscillation is not merely one failure mode among many. It is the dominant organizational response to unplaced or non-viable decision authority under stress.

Condition: Decision authority has not been intentionally placed, or has been placed in a mode that is structurally non-viable given decision frequency and system complexity.

Prediction:

• Authority shifts reactively between platform teams, governance bodies, and product teams following incidents or cost overruns
• Policies are repeatedly tightened and relaxed
• Decision ownership becomes episodic rather than stable

Explanation: When systems fail or behave unexpectedly, organizations seek to reassert control. In the absence of an intentionally placed authority model, this reassertion manifests as oscillation: authority is temporarily centralized to governance after incidents, pushed back to platforms to restore velocity, and delegated to product teams to unblock delivery. Each shift addresses symptoms locally while increasing global instability.

Crucially, authority oscillation often represents an attempt to re-anchor accountability after incidents have exposed a widened DAPM Gap. When accountability is demanded but not clearly anchored, organizations move authority in search of a locus willing to absorb responsibility.

Authority oscillation is therefore not a corrective mechanism; it is a signal that no placement mode has been selected that can survive operational reality. Oscillation persists until decision authority and accountability are explicitly aligned in a form compatible with system complexity and organizational expectations.

DAPM asserts that authority oscillation is the inevitable outcome when automation advances faster than authority placement and accountability anchoring.

DAPM asserts that authority oscillation is the inevitable outcome when automation advances faster than authority placement. It explains why large enterprises repeatedly cycle through governance crackdowns, platform centralization efforts, and decentralization initiatives without achieving durable stability.

— Recognizing these patterns allows organizations to anticipate failure modes and redesign systems before instability manifests.

7. Implications for Enterprise IT Strategy

By treating decision authority as a first-class concern, DAPM reframes how enterprises interpret common technology challenges. Rather than asking whether platforms, tools, or teams are sufficiently mature, DAPM asks whether decision authority has been intentionally placed and aligned with accountability.

This reframing has implications for platform engineering, cloud adoption and repatriation, governance design, cost control, and the adoption of increasingly autonomous systems. However, DAPM is not prescriptive; it does not mandate a preferred placement mode. Its primary contribution is diagnostic clarity.

8. Assessment: Locating Decision Authority

While DAPM is a conceptual model, organizations can infer their current decision authority placement through a small set of diagnostic questions. These questions are not intended to produce a score or maturity rating, but to surface implicit assumptions about authority and accountability.

8.1 Diagnostic Heuristics

Organizations can assess their current DAPM condition by examining the following questions:

1. When a system behaves unexpectedly, who is expected to explain and defend the outcome?
   • A platform team suggests platform-led authority
   • A governance body suggests governance-coupled authority
   • A product or service team suggests product-aligned authority
   • Ambiguity suggests unplaced (inherited) authority
2. Who is authorized to override system behavior at runtime?
   • Automated systems only
   • Humans through formal escalation
   • Product teams within constraints
   • No clear override path
3. Where are tradeoff policies defined and maintained?
   • Embedded within platforms
   • Codified in governance processes
   • Owned by product teams with guardrails
   • Implicit in defaults and vendor behavior
4. What happens after an incident or cost overrun?
   • Platform behavior is adjusted
   • Governance controls are tightened
   • Product teams change implementation
   • Authority shifts reactively between groups

8.2 Interpreting Results

Consistent answers across these questions indicate an intentional placement mode. Divergent or ambiguous answers indicate unplaced or oscillating authority. DAPM predicts that organizations operating with unplaced or oscillating authority will experience recurring instability regardless of tooling maturity.

These heuristics provide a starting point for examining decision authority placement without prescribing organizational change. More detailed assessment models and empirical validation are left for future work.

9. Relationship to Existing Frameworks

DAPM does not attempt to replace existing enterprise IT, governance, or decision-making frameworks. Instead, it addresses a structural gap that those frameworks implicitly assume away: the placement of decision authority when systems act autonomously at runtime. This section clarifies where DAPM begins, where other frameworks end, and how they compose without overlap.

9.1 RACI and Decision Rights Frameworks

RACI matrices and organizational decision rights frameworks define who is responsible, accountable, consulted, or informed for decisions made by people. They assume that decisions are discrete, deliberative, and human-mediated.

DAPM addresses a different problem: who is authorized to make tradeoffs when decisions are continuous, automated, and embedded in systems. While RACI can describe organizational accountability after the fact, it cannot explain why a system behaved as it did at runtime, nor who authorized those behaviors in advance.

DAPM complements RACI by exposing where decision authority has migrated into technical systems without corresponding organizational acknowledgment.

9.2 Control Planes and Platform Architectures

Control plane architectures describe where decisions are executed within systems. They specify how policies, configurations, and state changes are propagated and enforced.

DAPM operates one level above this abstraction. It asks who is authorized to define, constrain, and override control plane behavior. Two systems may share identical control plane architectures while exhibiting radically different operational outcomes depending on how decision authority is placed.

DAPM explains why technically sound platforms still fail organizationally when authority placement is implicit or misaligned.

9.3 Policy-as-Code and Rule-Based Systems

Policy-as-code frameworks formalize how rules are evaluated and enforced within systems. They excel at consistency and repeatability, but intentionally avoid questions of ownership and accountability.

DAPM treats policy engines as decision executors, not decision owners. It distinguishes between the existence of rules and the authorization to decide when rules apply, conflict, or require override. Without explicit authority placement, policy-as-code amplifies inherited authority rather than resolving it.

9.4 Human-in-the-Loop and Escalation Models

Human-in-the-loop (HITL) and human-on-the-loop models define conditions under which automated systems defer to human judgment. These approaches frame human intervention as an exception to automation.

DAPM reframes this relationship. It treats escalation paths as expressions of governance-coupled authority placement, not safety mechanisms layered onto otherwise autonomous systems. DAPM explains why HITL approaches fail at scale when authority placement is not explicitly designed to accommodate decision frequency and operational tempo.

9.5 Cynefin and Decision Authority Viability

The Cynefin framework classifies decision contexts based on the nature of causality, uncertainty, and emergence, distinguishing between simple, complicated, complex, and chaotic domains. It provides guidance on how decisions should be approached in different environments, particularly with respect to experimentation, analysis, and sense-making.

DAPM addresses a complementary but more constraining question: who can be authorized to make decisions at runtime without destabilizing the system once a decision context is known.

Importantly, Cynefin domains place hard limits on which decision authority placement modes are viable:

• In simple and complicated domains, governance-coupled authority can function effectively. Decision frequency is manageable, causality is sufficiently stable, and escalation to human review can keep pace with system behavior.
• In complex domains, governance-coupled authority becomes structurally non-viable. Emergent behavior, nonlinear interactions, and rapid feedback loops outpace human escalation mechanisms. Under these conditions, governance-coupled authority inevitably collapses into either unplaced authority or reactive oscillation.
• In chaotic domains, only pre-placed authority can respond at operational tempo. Platform-led or product-aligned authority is required to act immediately, with governance operating retrospectively rather than as a gate.

DAPM therefore extends Cynefin by translating decision context into constraints on authority placement. While Cynefin helps organizations understand the nature of the decision environment, DAPM determines whether an authority model can survive within that environment without generating instability.

Together, the two frameworks form a layered view: Cynefin classifies what kind of decisions exist, while DAPM determines who must be authorized to decide them at runtime.

9.6 Summary of Differentiation

Across these frameworks, a common assumption persists: that decision authority remains external to systems or is implicitly understood. DAPM challenges this assumption by making decision authority placement explicit and examinable.

DAPM does not replace organizational, architectural, or governance frameworks. It supplies a missing abstraction that explains why those frameworks succeed or fail depending on where decision authority is placed.

10. Conclusion

Enterprise IT failures are frequently attributed to immature tooling, insufficient skills, or inadequate governance. This paper has argued that such explanations often obscure a more fundamental issue: decision authority has shifted into systems without being intentionally placed or aligned with accountability.

The Decision Authority Placement Model (DAPM) formalizes this dynamic by making explicit a question that enterprise IT has historically left implicit: who is authorized to make tradeoffs at runtime when systems act on behalf of the organization. By distinguishing between unplaced (inherited) authority and intentional placement modes, DAPM explains why structurally similar failures recur across otherwise unrelated technology transitions.

DAPM does not prescribe a preferred operating model. Instead, it asserts a necessary condition for stability: decision authority must be explicitly placed, and that placement must align with how organizations expect accountability to function under stress. When execution is automated but authority remains implicit, failure is not anomalous—it is inevitable.

As enterprise systems continue to increase in autonomy and decision frequency, the need to reason explicitly about decision authority will only grow. DAPM provides a durable, technology-agnostic framework for doing so. When execution is automated but decision authority remains unplaced, failure is not anomalous—it is inevitable.

11. Future Research

Future work may include empirical studies of DAPM placement choices, quantitative analysis of failure correlations, and exploration of how AI systems further stress decision authority boundaries already present in enterprise IT.

About the Author

Keith Townsend is an independent CTO advisor and the founder of The CTO Advisor, an independent research and advisory platform focused on enterprise infrastructure, cloud platforms, and operating models for automation and AI.

Keith has spent his career working at the intersection of enterprise IT operations, platform engineering, and executive decision-making. His work draws on direct experience advising large enterprises on platform exits, cloud migrations, operating model design, and post-incident recovery, as well as facilitating closed-door Buyer Room discussions with CIOs and CTOs across regulated and mission-critical environments.

Keith’s recent research explores how decision authority and accountability shift as automation increases, including work on VMware as an operating model, cloud repatriation, the Fourth Cloud, and explicit judgment in AI systems (Layer 2C). He publishes and advises independently through The CTO Advisor.