I have watched a pattern repeat itself across organizations too many times to believe it is accidental. A technically competent person does careful work, raises legitimate concerns about architectural shortcuts, pushes back on timelines that will generate problems downstream. They are right. Their concerns are documented. And they are quietly sidelined while the project proceeds, delivers on schedule, and the manager who overrode their concerns is promoted.

The promoted manager is not incompetent. In many cases, they are genuinely skilled at something. But skilled at what, exactly? And why does that skill, rather than technical judgment, determine who advances?

This article is an attempt to answer that question rigorously. The answer implicates organizational dynamics, but also the educational institutions that train managers, the governance models that structure IT investment, and the reform movements, Agile among them, that have tried and failed to change the outcome. The system is not broken; it is working exactly as its underlying structure dictates. In 2007, Robert Schaefer, writing in ACM SIGSOFT Software Engineering Notes, asked the same question in more general terms: why do large complex systems so often work against their declared goals? His answer pointed directly at organizational governance, specifically at what he termed the Authoritarian Hierarchy of Control. What follows builds on that diagnosis and extends it into the specific dynamics of IT investment, selection, and reform.

Technical debt is not a failure of discipline. It is a system of incentives working exactly as designed.

The Incentive Structure That Generates Technical Debt

Large organizations govern IT investment through annual budget cycles and delivery metrics. A project is funded for a year, expected to deliver defined functionality by a defined date, and evaluated on whether it did. This structure imposes a specific temporal resolution on decision-making: what matters is what is visible within twelve months.

Architectural quality does not operate on a twelve-month horizon. The decisions that determine whether a system can be evolved cheaply in three years (modularity, decoupling, reversibility, testability) produce no visible output in the current budget cycle. By the logic of the measurement instrument, they are invisible.

Every technical role in a delivery team, whether developer, tech lead, or architect, is in the business of reducing the cost of being wrong. Good design does not predict the future; it ensures that when the system must evolve in ways no one anticipated, the cost of that evolution is bounded rather than catastrophic. But this value cannot be captured by a metric that closes at year end. It has no line in the budget and generates no deliverable.

The project manager who allocates time and money to architectural quality is making an investment whose return will appear in someone else’s budget cycle, under someone else’s name. The project manager who defers that investment delivers on time and on budget, and receives the recognition that comes with it. That is a sensible response to the incentive structure rather than a failure of individual judgment.

Schaefer named this mechanism risk shifting: when direct action to reduce a risk is judged too costly, the less costly tactic is to transfer that risk burden to others. If this transfer can proceed without immediate observation, the conflict it generates will simply be deferred. Annual budget cycles are, structurally, a machine for making risk shifting invisible. The cost lands in a future cycle, under a different manager, attributed to different causes.

Game theory offers a complementary framing. In a prisoner’s dilemma, two actors each face a choice between cooperation, which produces the best collective outcome, and defection, which protects individual interest at collective cost. When both actors reason independently and arrive at the locally coherent choice, both defect. The problem is not irrationality but the fact that individually sensible behavior produces collectively irrational outcomes. The parallel with IT governance runs deep enough to carry predictive weight. Every project manager, every budget cycle, every delivery team faces the same calculus. When every actor optimizes for their own position, the collective result is a technology estate that grows progressively more rigid, more expensive to evolve, and less capable of supporting the business it was built to serve. Nobody made a bad decision; everyone made a good one, given the game they were playing.

The Cascade: From Deferral to Dissimulation to Manipulation

Technical debt is the first and most visible symptom of this structure. But the same logic operates at every level of the organizational hierarchy, producing a cascade of increasingly consequential behaviors.

At the project level, the actor defers architectural quality. This is risk shifting in its most direct form: a cost that is real but diffuse, transferred to a future that belongs to someone else.

As the project encounters difficulty (deferred costs begin to materialize, timelines slip, complexity compounds), the actor at the next level faces a different version of the same calculus. Delivering bad news upward is costly. It damages reputation, invites scrutiny, and moves the problem from the future into the present. Filtering that information, presenting progress in the most favorable available framing, managing perception rather than reality: this is individually sensible for exactly the same reason that deferring architectural debt is individually sensible. The cost is real but diffuse, while the benefit is immediate and personal.

Schaefer formalized this in what he called the Liars’ Axioms. A liar, his term for any actor who strategically manages information to protect their position, suppresses, manufactures, or denies evidence to align observers’ judgments with their own goals. The intent of the lie, he observed, may simply be to stall for time. If the delay runs long enough, the consequences will have had greater impact on the world than the uncovering of the lie. Those who discover it afterward (auditors, commissions of inquiry, historians) matter only to a small audience. The actor has long since moved on.

The calculus that defers architectural quality also defers information. Technical debt accumulates at the bottom of the hierarchy; informational debt accumulates at the top. The mechanism is identical, and the consequences, when they finally surface, are proportional to how long the deferral has continued.

This is a structural observation, not a cynical one about human nature: it describes what happens when the same incentive pattern operates at multiple levels of a hierarchy simultaneously. Each level protects its position by deferring its costs to the next. The progression from deferral to dissimulation is continuous, not discrete. There is no moment at which a sensible actor becomes a dishonest one, only a gradual drift toward behaviors that the structure rewards and away from behaviors that it penalizes.

What Gets Selected

Organizations do not select randomly among the people available to them. Over time, through promotion decisions made by individuals operating within the incentive structure described above, they exercise a form of natural selection. The behaviors that advance are the behaviors that the structure rewards. The behaviors that are penalized (transparency, technical rigor, willingness to deliver unwelcome news) become associated with career stagnation.

Schaefer described this dynamic in terms of the Authoritarian Hierarchy of Control: organizations structured around command and control systematically suppress independent judgment in favor of loyalty and conformance, rewarding those who display alignment with authority over those who bring accurate but unwelcome observations. The result, he noted, is that the quality of products and services tends to be driven to the lowest level of mediocrity the market will bear, and that responsibility for poor performance will be attributed to individual contributors, never to the structure that produced it.

This selection process has a name for each of its outcomes. HEC Montréal, one of Quebec’s leading business schools, administers a political skill assessment that classifies managers into five profiles: Machiavellian, Strategist, Survivor, Good Soldier, and Sacrificial Lamb. The Machiavellian profile, described as driven by a strong thirst for power, politically motivated behavior, and the belief that ends justify means, is listed as having two strengths: highly effective, and achieves objectives. Ethical risks appear as a limitation, alongside friction and mistrust. The profile is presented not as a pathology but as a high-performance option with known trade-offs.

At the other end of the scale, the Sacrificial Lamb, described as believing that merit is sufficient, unable to decode political dynamics, potentially becoming a victim of the system, is listed as having three strengths: integrity, authenticity, and focus on work well done. Its risks include marginalization and incomprehension of real organizational dynamics.

What Gets Trained

HEC is not inventing the reality it describes. It is documenting what it observes in organizations, and then teaching it. HEC is not alone in this. The framing of political skill as a legitimate and measurable managerial competency has been widely adopted across business schools. What was once informal knowledge (how to handle power, manage perception, read the room) has been systematized into curriculum. By naming these profiles, measuring them, and transmitting them to the next generation of managers as legitimate knowledge about how organizations actually work, business education completes a feedback loop that Schaefer identified: the selection pressure that organizations exert is validated, codified, and taught as professional competence.

The Machiavellian who advances in a large organization is not a deviation from the system. They are its product: shaped by the incentive structure, selected by promotion decisions, and trained by the curriculum.

There is an irony here. Schaefer’s 2007 paper received only three citations in the seventeen years following its publication, not because it was wrong, but because the professional and academic structures of software engineering had no established category for an argument that located the root cause of system failure in governance, power, and the suppression of independent judgment. The diagnosis arrived before the vocabulary existed to receive it. That, too, is the system working as designed.

There is a question this article does not pretend to resolve: does the organization produce this selection pressure, which the educational institution then documents? Or does the educational institution legitimate and amplify a pressure that would otherwise remain informal? The honest answer is that causality runs in both directions. The organization and its educational infrastructure have co-evolved into a system that is now very difficult to disturb from within.

Why Agile Was Structurally Condemned

The Agile movement emerged in the early 2000s as a direct response to the dysfunctions described above. Its founding documents, particularly the Agile Manifesto, called for transparency over performance theater, genuine collaboration over contract negotiation, and working software over comprehensive documentation. It identified, correctly, that waterfall project dynamics generated exactly the kind of rigidity and deferral that technical debt represents.

The adoption of Agile in large organizations over the following two decades produced a result that is by now well documented: the vocabulary was adopted; the underlying dynamics were not changed. Sprints became fixed-scope, fixed-date delivery commitments. Velocity became a production output target. Retrospectives became compliance rituals. The Agile transformation was managed by the same people operating within the same incentive structure, producing the same behaviors under a new name.

Agile did not transform governance. Governance transformed Agile.

The standard explanation for this failure centers on the frozen middle: middle managers whose positional authority depends on the existing governance model, who absorbed the pressure for change without transmitting it upward. This explanation is correct but incomplete.

The deeper explanation is that Agile, authentically practiced, requires a specific type of organizational actor. It requires transparency about progress and problems, the willingness to deliver unwelcome news early, and collaboration that is genuine rather than performed. These are the behaviors associated with the Good Soldier and the Sacrificial Lamb in the HEC taxonomy, the profiles described as loyal, competent, and appreciated for their work, but also naive, vulnerable, and easily marginalized in competitive environments.

The Strategist and the Machiavellian, the profiles that large organizations have systematically selected and elevated, are precisely those for whom authentic Agile practice is not a viable strategy. Transparency exposes their deferral. Early bad news undermines their narrative management. Genuine collaboration limits their control of information flows. For these actors, adopting the vocabulary of Agile while hollowing out its content is political competence applied to organizational survival, not resistance to change.

Schaefer anticipated this failure with what he called the Process Paradox: the more a process is commanded, the less independent judgment is permitted, and when something goes wrong (as it inevitably will), the worse the consequences. Agile, commanded from above within an authoritarian hierarchy, does not produce agility. It produces a rigid process that eliminates independent judgment while preserving the appearance of flexibility. The name changes; the structure does not.

Agile did not fail because it was poorly designed or poorly implemented. It failed because it was introduced into organizations that had spent decades selecting against the human dispositions it required. The frozen middle did not block Agile. The selection process that produced the frozen middle made authentic Agile adoption structurally improbable before the first sprint planning meeting.

The Agile coach role, now a standard position in many large organizations, crystallizes this contradiction with particular clarity. It is an officially sanctioned mandate to transform a culture that the incentive structure actively reproduces. The role signals commitment to change without requiring it. In Schaefer’s terms, it is a display directed outward: the organization can point to its coaches as evidence of transformation while the governance model remains untouched. And it produces a specific collateral damage that rarely appears in any measurement. Developers who glimpse a different way of working, who are shown what genuine collaboration and technical quality could look like, find themselves unable to practice any of it within the real constraints of the system. The choices available to them are narrow: exit the organization, remain with a chronic frustration that compounds over time, or disengage quietly and accept the distance between what they know is possible and what the system will permit. The organization does not notice this damage, because what it measures is sprint velocity.

The Normalization of Failure

One final mechanism completes the loop and explains why the system persists without generating the corrective pressure one might expect.

Large IT project failure is not an occasional anomaly. The Standish Group has tracked IT project outcomes for decades; their data consistently show that only around 30% of IT projects are considered fully successful, a figure that drops further for large-scale initiatives, with roughly half of all projects challenged and nearly one in five outright cancelled or abandoned. The pattern is stable across years and geographies. Yet when a specific project fails (costs overrun, the system delivered is less capable than the system it replaced, timelines stretch beyond any defensible estimate), the failure is almost never attributed to the incentive structure that generated it. It is attributed to poor management, to vendor problems, to scope creep, to technical complexity. The postmortem identifies individuals and decisions. It does not identify the game those individuals were playing or the rules that made their decisions predictable.

Schaefer identified this as a structural property of hierarchical governance: the source of all faults will ultimately be whatever legitimate authority claims it is, whether or not such claims are true. Accountability flows downward to individual contributors. The structure that produced the conditions for failure is never the finding. To make it the finding would require those conducting the examination to indict what elevated them.

This misattribution operates at two scales simultaneously, and the two reinforce each other. At the organizational level, the postmortem blames individuals and decisions, protecting the incentive structure. But the same dynamic operates earlier, at the level of the project itself. When timelines slip, as they inevitably do when architectural shortcuts accumulate and deferred complexity begins to surface, the reading is almost always that the technical team is slow, that estimates were poor, that execution was lacking. This interpretation is structurally necessary. If the delay were attributed to its actual cause, the decisions that sacrificed quality to meet an earlier date, accountability would travel upward, toward the people who made those decisions. Attributing it to technical competence severs that causal chain cleanly. The practitioners who lived through the accumulation carry the reputational cost of a problem they did not create. They raised concerns that were overridden and worked inside constraints they did not choose. Some internalize the blame, wondering whether they could have done better, whether they should have pushed back harder, whether they lack something. The structure produces this doubt as a feature, not a side effect.

The system then produces a second deferral: the failed system is declared legacy (too old, too rigid, too expensive to maintain) and replaced. The replacement project is governed by the same annual budget cycle, managed by the same profiles, and evaluated by the same metrics. The cycle restarts. The debt that accumulated in the previous system is not examined as evidence of a structural problem but treated as the natural aging of technology, as entropy rather than design.

Software does not age. The observation is Schaefer’s, made in passing but worth dwelling on: software stays fixed in time. What changes is the context around it: the business it serves, the expectations placed on it, the people who maintain it. When an organization declares a system legacy, it is not describing a property of the technology. It is describing the accumulated consequences of decisions that were never attributed to their real cause.

A system whose failures are consistently misattributed, whose lessons are never learned, and whose replacements reproduce its conditions is not a system that is trying and failing to improve. It is a system that is successfully maintaining itself.

A Final Observation

This analysis is not offered as a counsel of despair to the practitioners who have spent years pushing against these dynamics, advocating for better design, raising concerns that were overridden, watching careful work be undone by delivery pressure. The frustration those practitioners feel does not mean they misunderstood something. It means they understood something correctly and found themselves playing a game whose rules made their understanding a competitive disadvantage.

Schaefer ended his 2007 paper with a question that remains unanswered: what are the limits of the will? He was asking whether individuals operating within deeply coercive systems retain any meaningful capacity for independent judgment. The question is not rhetorical. History suggests that the levers which have actually changed systems of this kind are rarely internal. They tend to be external: competitive pressure severe enough to punish rigidity, regulatory constraint that removes certain decisions from the negotiating table, or the cumulative weight of people who refuse to play the game and vote with their feet. Departures concentrate in exactly the profiles the system needs most, the Good Soldiers and Sacrificial Lambs who carry the technical judgment the Machiavellians cannot replace. Whistleblowing, when it occurs, is almost always punished before it produces change. Smaller organizations built deliberately outside the AHoC model sometimes succeed precisely because they have not yet had time to reproduce its conditions. None of these are solutions. They are the terrain on which change, when it happens, actually occurs.

The technical argument for architectural quality (modularity, decoupling, reversibility) remains correct. The problem is that it is a technical argument being made in an environment where the selection pressure runs in the opposite direction, and technical correctness has never overridden incentive structure.

What this analysis suggests is that the relevant question is not how to make the case for better architecture more persuasively. It is a prior question: in an organization that has systematically selected for political behavior, trained its managers in its legitimacy, and structured its governance to make individual rationality and collective interest incompatible, from what position, and with what leverage, is change actually possible?

That question does not have a technical answer.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Researcher (2005–2010): Image Processing & Creative AI
Business Expert / Domain Expert (2010–2026): Software Architecture, Software Development and Quality Practices

Reference

Schaefer, R. (2007). The Grand Theory of Everything: What Man-Made Systems Are, and Why They Fail. ACM SIGSOFT Software Engineering Notes, 32(4).

The first three articles in this series examined specific symptoms: the instability of the People-Process-Tools model under high human variability, the strategic liability of tool positioning in a fast-moving AI market, and the asymmetric risk that regulated organizations are structurally failing to measure. This fourth article steps back to name the underlying condition, the diagnosis from which those symptoms follow.

AI is not just a technological disruption. It is an organizational architecture disruption.

A Mismatch That Went Unnoticed Until Now

For most of the industrial and information age, there was a comfortable relationship between the pace of technological change and the pace of organizational adaptation. Technology evolved, but slowly enough that organizations could absorb each shift, stabilize their processes around it, and build institutional knowledge before the next wave arrived. The lag between technological possibility and organizational practice was an inconvenience, not a structural threat.

That relationship has inverted. For the first time in the history of organized work, the speed of technological evolution is structurally outpacing the speed of organizational adaptation. Rather than a temporary disruption caused by one particularly fast technology cycle, this is a change of regime: a permanent shift in the relative velocities of technological change and organizational response.

The evidence is visible in every domain. Organizations complete a tool evaluation cycle and find the market has already moved. They design a training program for a capability that AI has partially automated by the time the program launches. They build processes around a set of constraints that are redefined by regulatory guidance six months later. The gap is widening rather than closing, and the organizational models built for a slower world are showing the strain.

Why Processes Were the Right Answer, and What They Assumed

Consider what processes actually are, and why they represented such a powerful organizational technology for so long. Beyond being a list of steps, a process is an encoded solution to a recurring problem, a crystallization of organizational learning into a repeatable, transferable, auditable form. When an organization documents a process, it is converting tacit knowledge into institutional memory, individual judgment into scalable behavior.

This is genuinely valuable, and it rests on three assumptions that held for most of the twentieth century and well into the twenty-first: that the problem being solved is sufficiently stable to justify encoding, that the conditions under which the process operates will remain predictable enough for the steps to stay valid, and that repeatability is itself a source of value (doing the same thing reliably, at scale, is better than improvising every time).

AI attacks all three assumptions simultaneously. It renders stable problems unstable by continuously shifting what is technically possible and economically rational. It introduces permanent uncertainty into operating conditions. And it transforms repeatability from an asset into a fragility: the ability to execute the same steps reliably becomes a liability when those steps are precisely what needs to change.

Processes are not so much wrong as misaligned, optimized for a world that is receding faster than most organizations have recognized.

Processes Are Becoming Legacy Systems

In technology, we use the term ’legacy system’ to describe something specific: not a system that is broken, but a system that was built for a set of constraints that no longer match the environment in which it now operates. A legacy system can be technically functional, even well-maintained. What makes it legacy is the growing gap between its underlying assumptions and current reality.

This is precisely the condition of process-driven organizational architectures in the face of AI-driven technological turbulence. The processes themselves may be executing correctly. The people following them may be doing so diligently. The problem is architectural. The way the organization governs work (through predefined steps, stable roles, documented procedures, sequential approvals) was designed for a world of slower change, and that world is no longer the operating environment.

The recognition is uncomfortable because process-driven governance is deeply embedded in how organizations understand accountability, compliance, and quality. Audits verify process adherence. Performance frameworks reward process execution. Regulatory frameworks often mandate specific processes. Saying that processes are becoming legacy systems does not mean that accountability, compliance, and quality no longer matter. It means that the mechanism through which they have been achieved is reaching the limits of its fitness for purpose.

Principle-Driven Systems as the Architectural Response

If processes assume stability, principles assume change. This is the essential distinction, and it points toward a different architecture for organizational governance.

A principle defines what must be true: the quality threshold that cannot be compromised, the constraint that is non-negotiable, the outcome that must be achieved. It does not prescribe how. It governs by results rather than by steps. Teams operating under a principle-driven system follow guardrails and pursue defined objectives, but they adapt their methods continuously as the environment evolves, while the principle itself stays stable.

This is not a novel idea in theory. Agile movements, outcome-based management, and mission-command doctrine in military organizations have all pointed in this direction. What is new is the urgency and the mechanism. The urgency comes from the acceleration of technological change. The mechanism comes from agentic AI architectures: systems that are natively coupled to objectives and constraints rather than to specific tools or procedures, and that can adapt to changing operating conditions without requiring the governance layer to be redesigned every time the tooling shifts.

Agentic architectures are not simply a more efficient way to execute processes. They are an architectural alternative to them, embedding adaptability at the level of the system itself rather than relying on human judgment to compensate for procedural rigidity.

Consider a concrete illustration. A logistics team operating under a process-driven model has a documented approval workflow for any change to its supply chain routing tools, a cycle that takes weeks and requires sign-off from architecture, security, and procurement. When a new AI-powered routing tool becomes available, the process triggers in full, regardless of how minor the change. Under a principle-driven model, the governing constraint is different: “all routing decisions must maintain delivery reliability above X%, cost variance below Y%, and full auditability.” An agent operating under those principles can evaluate and adopt a new routing tool autonomously, because what is being governed is the outcome rather than the mechanism. The principle holds, and the approval cycle dissolves.

The shift from process-driven to principle-driven governance is therefore primarily an architectural decision rather than a technology one. It concerns where stability should live in an organization. In a world of permanent technological turbulence, the answer is that stability must live in principles and outcomes, not in procedures and tools.

Organizations Must Be Engineered for Technological Turbulence

None of this argues for improvisation, or for abandoning the rigor that processes have historically provided. The argument is that rigor itself must be rearchitected. The question to settle is what to govern and at what level of abstraction, not whether to govern.

The organizations that handle the coming decade well will not be the ones that execute their current processes better, but the ones that have made a deliberate architectural choice: to invest in stable, well-defined principles rather than brittle, step-by-step procedures; to build agentic systems capable of working with continuously shifting tooling; and to develop adaptive governance frameworks that measure outcomes rather than adherence.

Engineering an organization for technological turbulence means building a particular kind of resilience. Bouncing back from disruption is one form of it; being structurally designed to absorb continuous change without losing coherence is another. The distinction matters, because the first is a recovery capability and the second is an architectural property.

The organizations that possess this property will not be immune to the challenges of an AI-accelerated environment. But they will face those challenges with a structural advantage: the ability to adapt their methods while holding their principles constant, and to absorb technological change as a normal operating condition rather than as an exceptional disruption.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era

A Time-Tested Model Confronting an Unprecedented Context

The People, Process, Tools (PPT) model has shaped technology governance for decades. Its founding premise rests on the stability of human capital: skilled individuals, carrying a shared culture, apply defined processes using adapted tools. In its mature form, this model has always recognized that processes and tools encode organizational knowledge, with the human dimension serving as the activation vector.

But in an environment defined by high resource turnover, systematic reliance on external consultants, and the proliferation of teams assembled for short-term needs, that premise of stability no longer holds. The PPT model remains theoretically valid. What is in question is whether it can operate effectively when its human pillar is structurally unstable.

The ‘People’ Pillar as an Unstable Variable

When resource turnover is high, organizational knowledge disperses instead of accumulating. Every departure takes with it decision-making context, tacit practices, and domain understanding that formal artifacts only partially capture. Internal culture loses its coherence when a significant proportion of contributors operates within a temporary horizon. Practices imported from outside, heterogeneous by nature, complicate governance and introduce variability that neither documented processes nor available tools can adequately contain.

Under these conditions, structuring quality around a constantly renewing pool of human expertise exposes the organization to real risks: operational discontinuity, practice drift, and erosion of technological maturity. What this calls for is a shift in ratio, not an inversion of the model. The human factor remains central, but it can no longer serve as the sole foundation.

Repositioning the Foundation: Processes, Tools, and Platform Engineering

Faced with this reality, it becomes necessary to shift the model’s foundation toward elements that remain constant: processes, tools, and now the platform. This reconfiguration does not marginalize the human role; it relieves it of a responsibility it can no longer bear alone in a context of high variability. Individuals stop being the source of coherence and become its beneficiaries: they join a structured environment that guides them from day one, regardless of their background.

The natural evolution of this approach is platformization. An internal platform encodes organizational knowledge in a reusable ecosystem of normalized pipelines, pre-configured environments, project templates, automated controls, and standardized practices. It substitutes a human memory that erodes with turnover for an integrated, persistent operational memory.

That said, this approach is demanding. Building and maintaining a quality internal platform requires a competent, stable, and well-governed team. The structural irony is real: to reduce dependence on interchangeable individuals, you create an infrastructure that requires highly specialized individuals over the long term. Many organizations underestimate this cost. A poorly designed or poorly governed platform can become an even greater obstacle than having no platform at all. This repositioning is no magic solution but a long-term investment, with its own governance requirements.

Artificial Intelligence as a Lever and as a Responsibility

The integration of artificial intelligence represents a significant acceleration of this logic. Within a heavily tooled system, AI can transform static processes into adaptive mechanisms: automated code analysis, test generation, continuous review, technical drift detection, and domain knowledge assistance. These capabilities reduce dependence on individual expertise and strengthen the system’s resilience against team turnover.

However, it would be inaccurate to present AI as a frictionless solution. Its effective deployment raises several challenges:

• AI system governance (prompt engineering, continuous output evaluation, data lineage management, bias monitoring) itself creates dependence on specialized competencies (MLOps, LLMOps, Platform AI) that are often rare and expensive.
• AI shifts human dependencies; it does not eliminate them. It generates new layers of specialization, often more demanding than those it replaces.
• The cognitive debt risk is real: junior profiles who become overly reliant on AI suggestions may develop impoverished reasoning, undermining precisely the human capital the system seeks to make less critical.

An organization that adopts AI as a pillar of its quality engineering must simultaneously invest in the governance of that pillar. Without it, you are simply substituting one fragility for another.

Scope of Application and Model Limitations

This repositioning is particularly well-suited to high-variability organizations: fast-growing scale-ups, technology consulting firms, product teams with a significant proportion of contractors, or IT service delivery environments. In these contexts, platformization and AI augmentation represent high-ROI levers for operational resilience.

In high-criticality domains such as aerospace, healthcare, heavily regulated finance, and critical infrastructure, this logic must be applied with considerable care. Individual accountability and accumulated expertise remain non-substitutable pillars in these fields. Automation and standardization can play a supporting role, but they cannot render the human factor ‘interchangeable’ without introducing risks of a fundamentally different nature.

A Hybrid Model for an Asymmetric Environment

The repositioning proposed here aims to rebalance the PPT model rather than invert it. In an environment where human variability has become the norm, operational excellence rests on an asymmetric combination: a solid platform infrastructure, processes that enforce coherence, and well-governed AI that increases resilience. As an indispensable complement, it also needs a core of highly skilled individuals who maintain and evolve the system and embody its vision.

This model does not guarantee excellence on its own. It creates the structural conditions under which excellence becomes reproducible and less dependent on the luck of individual trajectories. What you gain is predictability. You do not eliminate the need for exceptional people; their role concentrates where it is least substitutable, in judgment, innovation, and governance of the system itself.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era

In a previous article, I argued that the People-Process-Tools model needs to be rebalanced toward platform engineering in contexts of high resource variability. This article extends that argument one step further: in a world where AI is redefining the available tools every few months, even the ‘Tools’ layer of that platform deserves to be rethought.

The Paradox of Tool Positioning

In large organizations, the process of selecting, evaluating, approving, and deploying a new tool is rarely a lightweight exercise. Between security reviews, architecture assessments, procurement cycles, integration planning, and training programs, the full lifecycle from initial evaluation to production readiness commonly spans six to eighteen months. For highly regulated environments, that timeline can extend further.

This investment was once rational. When technology moved slowly, the cost of a rigorous positioning process was amortized over years of standardized usage. The approved tool became part of the organizational fabric, embedded in workflows, documentation, onboarding paths, and institutional memory.

That calculus has changed. The current cycle of AI-driven tool evolution is measured not in years but in months, sometimes weeks. By the time an organization completes its positioning process for a given tool, the competitive situation may have shifted, the tool itself may have been substantially transformed, and a new generation of alternatives may have emerged. The organization ends up optimized for a world that no longer exists.

Why This Was Rational, and Why It No Longer Is

It would be unfair to dismiss tool positioning processes as bureaucratic excess. They exist for legitimate reasons: security and compliance requirements, interoperability constraints, support and vendor stability considerations, and the very real cost of fragmented tooling across teams. These concerns have not disappeared.

What has changed is the nature of the coupling between an organization and its tools. In a slower-moving environment, investing deeply in a specific tool (building expertise, integrations, and institutional knowledge around it) generated durable returns. That depth was an asset.

In today’s environment, that same depth increasingly functions as a liability. Deep coupling to a specific tool creates switching costs that slow adaptation. Institutional knowledge built around a particular interface or workflow becomes obsolete as AI transforms the tools themselves. The more thoroughly an organization has embedded a tool into its operating fabric, the more painful the inevitable transition becomes.

The issue lies less in the tools themselves than in the strategic weight organizations assign to tool selection. When tool positioning is treated as a long-horizon strategic commitment, the organization assumes a stability that the environment no longer provides.

The Pivot: From Tools to Principles

If tools are no longer a stable strategic variable, what is? I would argue for principles: the articulation of expected behaviors, quality standards, operational constraints, and governance guardrails that define how work should be conducted, independently of which tool happens to be executing it.

This shift goes deeper than it may initially appear. Principle-driven governance asks organizations to invest in defining what good looks like (what outcomes are expected, what boundaries must be respected, what quality thresholds must be met) rather than prescribing the specific mechanism through which those outcomes are achieved. The principle is stable; the tooling that enacts it is fluid.

Consider the difference between these two governance postures:

Tool-centric: “All code reviews must be conducted using platform X, following workflow Y.”

Principle-centric: “All code changes must demonstrate coverage above threshold T, pass static analysis at severity level S, and include a human review sign-off before merging.”

The second posture is tool-agnostic. It can be enacted by a human reviewer, a CI/CD pipeline, an AI-assisted review agent, or any combination thereof. As tooling evolves, the principle remains intact. Only the mechanism of enactment changes, and that change becomes an optimization rather than a disruption.

Agentic Architectures as a Tooling Abstraction Layer

This is precisely where agentic AI architectures become strategically relevant, as a structural response to tooling volatility and not merely as a productivity lever.

A well-designed agent is coupled to an objective, a set of constraints, and a definition of acceptable outputs, rather than to a specific tool. Given those parameters, the agent selects, orchestrates, and adapts its tooling dynamically. The tool becomes an implementation detail, visible to the agent but invisible to the governance layer.

In a multi-agent architecture, this abstraction scales. Individual agents can specialize (one handling code analysis, another managing test generation, another monitoring technical debt), each operating against the same set of organizational principles while independently managing their tooling layer. As new, more capable tools emerge, the agents can incorporate them without requiring a governance review of the tool itself. What gets reviewed is whether the agent’s outputs continue to satisfy the principles.

This represents a meaningful inversion of the traditional governance model. Rather than controlling quality by controlling tools, the organization controls quality by controlling outcomes. The locus of governance shifts from inputs to outputs, from “what tool are you using” to “are the results meeting the standard.”

The implications for large organizations are significant. Tool evaluation cycles shorten dramatically. Shadow tooling, a persistent governance challenge in organizations with slow approval processes, largely dissolves as a concern: if the agent is producing compliant outputs, the underlying tooling becomes an operational detail rather than a governance risk.

Limits and Conditions for Success

This architecture relocates governance complexity rather than eliminating it. Several challenges deserve honest acknowledgment.

Defining good principles is harder than it appears. Principle-driven governance requires organizations to articulate, with precision, what they actually care about. Vague principles produce inconsistent agent behavior. Overly rigid principles reproduce the brittleness of tool-centric governance in a different form. Getting the level of abstraction right requires significant organizational investment and ongoing calibration.

Output evaluation at scale is a partially unsolved problem. For well-defined, measurable outcomes such as test coverage, static analysis scores, or deployment frequency, this is tractable. For more qualitative dimensions like architectural coherence, domain appropriateness, and long-term maintainability, it remains genuinely difficult.

Agent maturity remains a limiting factor. Current agentic systems are capable and improving rapidly, but they are not infallible. Human oversight, particularly for high-stakes decisions, cannot be fully removed from the loop, at least not yet.

Regulated environments require special treatment. In domains where regulatory compliance is tied to specific tools, processes, or audit trails, the fluidity of agentic tooling introduces compliance risks that cannot be resolved through principle-definition alone.

A Governance Model Built for the Speed of Change

The organizations best equipped for the current period of technological acceleration are not necessarily those with the best tools. They are those with the clearest principles, along with the architectural flexibility to let those principles be enacted by whatever mechanisms become available.

This is a direct extension of the argument made in the first article of this series. If the People-Process-Tools model needs to be rebalanced toward platform and process in a context of human variability, then the tooling layer of that platform needs to be rebalanced toward principles and agents in a context of technological volatility.

The strategic question for technology leaders has shifted from “which tools should we standardize on” to “which principles are non-negotiable, and how do we build systems, human and agentic, that reliably enact them, regardless of what the tooling landscape looks like six months from now.”

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era

The first two articles in this series examined how to rebalance technology governance toward platform engineering in contexts of high human variability, and why tool positioning is becoming a strategic liability in a world of accelerating AI. This third article steps back from the technical layer to address a more basic challenge: the organizational resistance that makes any of these transformations genuinely difficult, and the asymmetric risk of not moving fast enough.

Organizations have spent decades building systems to control technological risk. They have not built systems to detect technological irrelevance.

An Organization Does Not Have Processes: It Is Its Processes

There is a common way of framing organizational change that sounds reasonable but is misleading: the idea that an organization has processes, in the same way it has office space or software licenses, assets that can be evaluated, updated, or replaced through a sufficiently deliberate management decision.

The reality is more unsettling. An organization does not merely possess its processes. In a meaningful sense, it is its processes. They define how decisions get made, how work gets coordinated, how risk gets assessed, how value gets delivered. They encode the accumulated responses to past failures, regulatory pressures, and hard-learned lessons. Rather than a layer sitting on top of the organization, they are its operating identity.

This is the central insight behind Allen Holub’s work on systems of work: you cannot remove or change one element without affecting the entire system, and the system will actively resist changes that threaten its coherence, pulling the organization back toward its previous state. Organizational resistance to change is therefore not a failure of leadership courage or a deficit of innovation culture; it is the system functioning exactly as designed. The challenge is not to overcome that resistance through force of will, but to understand which parts of the system need to transform, and how to do so without collapsing the coherence that holds everything together.

AI Is Not Waiting at the Door: It Is Already Inside

Regulated organizations (financial institutions, healthcare systems, energy companies, public sector bodies, legal and professional services firms) have historically managed technological adoption through deliberate, controlled processes. This was rational. In a stable technological environment, moving carefully reduced integration risk, ensured regulatory compliance, and preserved operational continuity.

That posture is increasingly misaligned with the current moment. AI does not present itself as a discrete technology that organizations can choose to evaluate and adopt on their own timeline. It is infiltrating through every layer of operations: the productivity tools individual contributors are already using, the platforms vendors are embedding AI capabilities into, the competitors who are quietly compressing delivery timelines and cost structures, the talent market where expectations about AI-augmented work are shifting rapidly.

In financial institutions, the question is no longer whether AI will affect credit risk modeling, fraud detection, regulatory reporting, or client-facing services. It already does, whether through internal adoption or through the competitive and regulatory environment that surrounds the institution. The relevant question has shifted from should we adopt AI? to at what rate are our current processes becoming a competitive and operational disadvantage, and are we measuring that rate?

The Asymmetry of Risk That Does Not Appear in Governance Reports

This is the most structurally important challenge for regulated organizations, and it is one that their governance frameworks are poorly designed to surface.

The risk of moving too fast with AI is visible and auditable. It manifests as compliance failures, model risk incidents, data governance violations, operational disruptions. It appears in risk committee reports, regulatory examinations, and audit findings. Regulated organizations have spent decades building sophisticated machinery to detect, quantify, and contain exactly this type of risk, and they are genuinely good at it.

The risk of not moving fast enough is structurally different. It is diffuse, cumulative, and largely invisible to conventional risk measurement frameworks. It does not generate an incident or trigger a regulatory finding. It accumulates silently as a widening gap between the organization’s operational capabilities and those of its environment: competitors, technology providers, talent expectations, and eventually regulators themselves.

By the time this second type of risk becomes visible, it typically manifests not as a discrete event but as a condition: an inability to attract engineering talent with relevant AI skills, a growing gap in delivery speed relative to competitors, a technological debt so deep that transformation becomes structurally prohibitive.

Consider a concrete illustration. A major bank’s regulatory reporting process relies on manual data consolidation across legacy systems. The cycle takes three to four weeks per quarter, absorbs dozens of analyst hours, and produces results that are already partially stale by the time they reach the board. An AI-augmented equivalent could compress that cycle to days, reduce error rates, and free the analysts for higher-judgment work. The risk of implementing such a system is visible and manageable (model validation, auditability, change management). The risk of not implementing it accumulates invisibly: mounting operational cost, growing talent frustration, and an expanding gap relative to institutions that have already made the transition. The first risk has a line in the risk register; the second does not.

The asymmetry is this: the governance machinery of regulated organizations is optimized for the first type of risk and structurally blind to the second.

Regulation as Constraint, and as Underestimated Lever

In conversations about AI adoption in regulated industries, regulatory constraints are frequently invoked as the primary justification for caution. This framing is not wrong; regulatory constraints are real and consequential.

But it is increasingly incomplete, and in some cases it has become a rhetorical convenience that obscures something less comfortable: the pace of adoption is often constrained less by regulation than by organizational inertia dressed in regulatory language.

Regulators themselves are not standing still. Financial supervisory authorities, including the AMF, OSFI, the European Banking Authority, and others, are actively developing AI governance frameworks, publishing guidance on responsible AI use, and in some cases explicitly encouraging institutions to build AI capabilities in areas such as real-time compliance monitoring, fraud detection, and operational risk management. The implicit message from regulators is not “wait until we have figured this out” but “develop the governance maturity to use these tools responsibly.”

An organization that waits for the regulatory framework to be fully stabilized before investing in AI capabilities is making a specific bet: that the cost of early compliance investment outweighs the cost of late adoption. In a faster-moving environment, that bet is becoming harder to justify.

Regulation, properly understood, is a constraint on the speed and form of AI adoption, not a justification for its absence.

Navigating the Transition: Changing Without Breaking

The response to this challenge is not a wholesale transformation that attempts to change everything at once. Holub’s insight about systems of work applies with particular force here: an organization that tries to revolutionize its entire operating model in response to an external pressure is as likely to collapse its coherence as to improve its capabilities.

This requires organizations to develop a capability that is itself relatively new: the ability to map their own processes according to their strategic value in an AI-augmented environment. Not all rigidity is equivalent. Some processes derive their value precisely from their stability and resistance to change: regulatory compliance mechanisms, audit trails, risk controls, fiduciary obligations. These are not candidates for AI-driven transformation. They are anchors that must be protected even as the surrounding system evolves.

Other processes derive value from their efficiency and adaptability: knowledge management, delivery pipelines, onboarding, tooling, internal reporting, operational monitoring. These are precisely the areas where AI augmentation offers the highest return, and where the cost of inaction is accumulating most rapidly. Treating them with the same conservatism as core compliance processes is a category error, not prudent risk management.

The practical implication is a dual governance posture: rigorous protection of the processes whose value is their stability, combined with active transformation of the processes whose value is their performance. The organizations that handle this transition most effectively will be those that can hold both imperatives simultaneously, and resist the temptation to use the first as cover for avoiding the second.

This is not a call to abandon prudence, but to redefine where prudence actually applies.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era

A Theory of Creativity First

Before building any system, I needed to understand what creativity actually is.

Here is the formulation I arrived at around 2005, working as a researcher in Québec City:

Humans cannot create something entirely new from nothing.

We can only perceive reality through our senses. You cannot imagine a color that does not exist. You cannot conceive a sound you have never heard. The entire domain available to human creativity is bounded by accumulated sensory experience.

Creative thinking is therefore combinatorial rather than generative ex nihilo. The only way to produce something genuinely new within a bounded experiential space is to discover a structural correspondence between two distant domains that are already known.

When that correspondence holds, it is a metaphor.

But novelty alone is insufficient. A creative idea must also be useful, and usefulness is not intrinsic to the idea itself. It is evaluated by a human observer with a specific problem and a specific set of objectives. The same association can be brilliant in one context and irrelevant in another.

This leads to a precise formulation:

A creative idea is an association between two distant known domains whose relevance is judged by a human evaluator as both novel and useful within a specific context.

Novelty is a function of semantic distance between domains.

Utility is a function of the match with the problem and with the evaluator’s own criteria.

From this theory, an architecture follows naturally.

The Architecture (2005–2010)

If creativity is the identification of structural correspondences across distant domains, then a system designed to assist creativity should not search for what is similar. It should search for what is structurally equivalent across distance.

Between 2005 and 2010, working at a private imaging company in Québec City, I designed and implemented such an architecture.

Each object in the system (initially images, but the framework was modality-independent) was described through three structured vectors:

• A composition vector capturing spatial organization, perspective, and luminosity
• An object-property vector encoding detected geometries, shapes, and physical attributes
• A semantic vector containing qualitative keyword descriptors

These vectors were computed automatically using classical computer vision techniques: color histograms, wavelet decompositions, geometric segmentation, texture analysis, spatial frequency distributions. Each image received a multidimensional signature, which we called a “genetic code,” stored in a database and queryable in real time across a collection of 100,000 images.

In today’s terminology: a hand-crafted feature-embedding pipeline feeding a structured vector database, with sub-second query response time. Built in 2008, before those words existed in this context.

But the architectural intent was quite different from similarity search.

The system did not ask: What is nearest?

It asked:

• Which objects share equivalent structural overlaps with a reference? (alternative objects: substitutable, not combinable)
• Which objects contribute complementary, non-overlapping components of a reference? (complementary objects: combinable to form a stronger metaphor)
• Which combinations increase analogical coherence rather than surface resemblance? (linked objects: internal reinforcement as a tiebreaker)

The metaphorical strength of a combination was computed as the aggregate overlap across structured dimensions. Combinations were ranked by analogical coverage, not by proximity.

A red apple and a white tablecloth, taken separately, are only partial metaphors for the Japanese flag. Combined, they cover it completely: one contributes the red circle, the other the white rectangle. Their combination scores higher not because they resemble the flag, but because together they account for its structure. That is analogy, not similarity.

Similar questions were being explored across content-based retrieval and computational creativity research during that period. The problem was recognized; what was missing were the representational tools to address it at scale.

Why This Distinction Still Matters

Modern embedding systems, including the best multimodal foundation models, are extraordinarily capable. They organize high-dimensional spaces where related concepts cluster together. Distance minimization in embedding space has proven to be a remarkably powerful paradigm.

But the analogical operation itself remains largely latent in these systems.

Current architectures optimize for distance, retrieve nearest neighbors, and interpolate within learned manifolds. They do not explicitly evaluate which pairs or sets of representations together form a structurally stronger mapping to a reference than any single element alone.

Foundation models can produce metaphor-like outputs through statistical association, sometimes impressively so. But the mechanism is emergent rather than structured, which means it cannot be controlled, composed, or inspected.

Making analogy a first-class, explicit, steerable operation in AI systems remains an open architectural problem.

What AI Still Needs

Revisiting this research today, three limitations of current AI systems stand out, each rooted in the same theory of creativity I was working from in 2005.

1. Implicit context inference

Human creativity does not operate in a vacuum. The relevance of any idea depends heavily on the context in which the human is operating: their constraints, objectives, mental state, environment. A skilled collaborator reads this context without being explicitly told.

Current AI systems depend almost entirely on what the user explicitly provides. They do not perceive the context in which the human evolves. For AI to become a genuine creative partner, it needs access to richer contextual signals, along with the capacity to infer meaning from them without requiring the human to articulate everything. That is a problem of situated cognition rather than retrieval.

2. Memory as a knowledge reservoir

In my theory of creativity, the quality of associative reasoning is directly proportional to the richness of available memory. More diverse experience means more potential connections across distant domains.

Current AI systems have impressive parametric knowledge, but their memory architecture is largely static between training runs. The strategic management of episodic, contextual, and long-term memory, treated as a dynamic, queryable reservoir that evolves with use, remains underdeveloped. Memory, in this view, is the substrate of association and not just storage.

3. Emotional memory

This is perhaps the most significant gap, and the one most likely to trigger an objection from researchers in reinforcement learning or affective computing.

The objection is predictable: AI systems do incorporate affective signals, through reward modeling, reinforcement learning from human feedback, and preference learning. This is true, and the work is serious.

But it addresses a different problem. These approaches treat affect as an external training signal: feedback injected during learning to shape behavior. Human emotional memory is structurally different. Rather than a signal applied to knowledge from the outside, it is woven into knowledge itself.

The neuroscientist Antonio Damasio demonstrated this precisely. Emotion is not separate from rational cognition; it is constitutive of it. Patients with damage to emotional memory centers do not become more rational. They lose the capacity to make decisions at all, because they can no longer assign differential weight to recalled experiences.

Every human memory carries affective encoding (fear, joy, discomfort, wonder) that influences which associations surface, which combinations feel meaningful, and which ideas resonate. This weighting is embedded in the retrieval structure itself rather than applied post-hoc.

Current AI systems process semantic relationships without this integrated affective architecture. The gap may therefore be architectural rather than merely incremental.

Building systems where affective structure is embedded in memory, instead of applied to it from outside, may be one of the most important open problems in AI research on creativity and reasoning.

Why I Am Writing This Now

The research described here was conducted between 2005 and 2010 and was not publicly discussed at the time due to contractual obligations.

Revisiting it now is less an exercise in retrospection than a recognition that the underlying questions remain open, and that the technological conditions to investigate them meaningfully finally exist.

I am not writing to claim priority. Parallel discovery is the norm in research, and I have no interest in relitigating timing. I am writing because the problem is still in front of us.

If you are working on reasoning architectures, compositional intelligence, contextual AI systems, or human–AI collaboration, I would like to talk.

The research described above is documented in an unpublished patent specification and a research poster produced in 2008.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era