The Perfect Square Trinomial: When IT Governance Sounds Smarter Than It Works
A few days ago, I was having a C-level conversation with a CTO about technology governance and control. We were discussing the issues that really matter at executive level: how technology priorities are set, how investments are governed, how risk is balanced against speed, how architecture supports business growth, how delivery capability is measured, and how all of that is translated into outcomes the business can actually see.
During that conversation, while referring to COBIT, he mentioned a term: “Data Blending.”
For a moment, I drew a blank. I knew the term, of course, but I could not connect it to COBIT in the way he was presenting it. My first reaction was not to challenge him; it was to challenge myself. Perhaps there was something I had overlooked, so I checked.
There wasn’t. Data Blending is not a formal COBIT concept.
That detail could have disappeared immediately, but it stayed with me because it exposed a much larger issue. In technology, particularly at executive level, sophisticated terminology can create the perception of sophisticated capability. Someone who speaks fluently about COBIT, ITIL, Enterprise Architecture, Agile, Scrum, Kanban, OKRs, Quality Engineering, DevOps, operating models, risk frameworks and the latest technology trends can sound extraordinarily convincing in a C-suite conversation. Sometimes that person really has the depth behind the vocabulary. Sometimes you are simply listening to a very well-trained library rat.
There is nothing wrong with knowing frameworks. I have used many of them throughout my career, and they are valuable precisely because they capture decades of accumulated knowledge, patterns, controls, practices and lessons learned. The problem begins when familiarity with the framework is treated as proof that someone knows how to apply it.
That is where theory ends and experience begins.
A certification can demonstrate that someone understands a body of knowledge. A master’s degree can deepen conceptual thinking. A framework can provide structure and common language. None of those things, however, tells me what that person will do when the organization in front of them does not behave like the organization described in the book.
And real organizations almost never do.
They have technical debt that cannot simply be removed, budgets that are smaller than the roadmap, executives with competing priorities, regulatory pressure, informal decision structures, uneven maturity, legacy platforms, limited specialist talent and teams that are already operating close to their limits. The organization may say it wants transformation while simultaneously protecting the behaviors that make transformation difficult. The strategy may demand speed while the control model rewards caution. Architecture may define a clean target state while delivery teams are still keeping critical systems alive with scarce capacity.
That is why experience matters so much in technology governance. Experience is not simply time spent in a role; it is the accumulation of decisions made under real constraints and the consequences of those decisions. It is what happens when a theoretically sound approach fails, when you understand why it failed, adjust it and recognize the same pattern earlier the next time it appears in a completely different context.
Over time, that becomes judgment.
And judgment is what technology governance really needs.
Governance is not framework implementation
One of the easiest mistakes to make is to start the conversation with the framework: “How do we implement COBIT?” “How do we become Agile?” “How do we adopt ITIL?” “How do we formalize Enterprise Architecture?”
Those are legitimate questions, but they are usually not the first questions that should be asked. A better starting point is much more basic: what does this organization need to be able to decide, control, deliver, measure and improve in order to execute its strategy?
Once that question is answered, frameworks become useful because they can contribute specific practices to the solution. COBIT may strengthen governance and accountability, ITIL may improve service management, Enterprise Architecture may connect business capabilities with technology evolution, Agile practices may improve adaptability, Scrum or Kanban may improve flow in the right delivery context, OKRs may translate strategy into measurable outcomes, and Quality Engineering may protect delivery capability by embedding quality throughout the lifecycle.
The real work, however, is not selecting one of those practices. It is designing how they work together.
A mature technology governance system should create a visible line from business strategy to business outcomes. In practice, that means strategy should influence OKRs; OKRs should influence technology priorities; priorities should determine investment; investment should be constrained by architecture and sustainable Delivery Capability; delivery should operate with the right level of Agility and Quality Engineering; and the entire system should remain connected to risk, controls, performance and value realization.
When those relationships are weak, organizations can appear mature while producing poor results. I have seen architecture functions with excellent target-state diagrams that the organization did not have the capacity to execute. I have seen PMOs where most initiatives appeared green while delivery predictability was steadily deteriorating. I have seen organizations performing every Scrum ceremony correctly while remaining structurally incapable of reprioritizing work. I have also seen executive dashboards packed with KPIs that still could not answer a simple question: are we obtaining the business outcomes we expected from technology?
The problem in all of those cases was not the absence of practices. The problem was the absence of integration.
Strategy only matters when capacity follows it
This is where OKRs become especially useful—not because they are fashionable, but because they can expose whether strategic intent is actually being translated into execution.
An executive team may declare that digital growth, customer experience or operational efficiency is a strategic priority. That statement has little governance value unless technology can trace it into measurable Key Results, connect those Key Results to funded initiatives, and show that sufficient delivery capacity has actually been allocated to them.
A useful indicator here is the Strategic Alignment Ratio, which can be calculated as:
Delivery capacity allocated to strategic priorities / Total sustainable delivery capacity × 100
The number itself is not the point. The conversation it creates is.
If an organization repeatedly declares three major transformation priorities while most of its capacity is consumed by operational work, remediation, unplanned demand and low-value initiatives, the real problem is not that the teams are failing to transform quickly enough. The problem is that governance is saying one thing and funding another.
The same applies to OKR achievement. A high OKR Achievement Rate can look impressive, but if Key Results have been designed to be easy to achieve, the metric creates false confidence. The real executive question is whether OKRs are forcing prioritization, trade-offs and measurable outcomes or simply adding another layer of reporting.
That is why experience matters. Someone who has lived through enough transformations learns to look beyond the percentage and ask what behavior the metric is actually driving.
Delivery Capability is a governance issue, not just a delivery issue
Organizations are usually far better at approving demand than at governing how much demand their delivery system can absorb.
A portfolio starts with ten strategic initiatives. Then regulatory work appears, cybersecurity introduces critical remediation, operations raises urgent stability needs, the CEO adds another priority and a commercial opportunity suddenly becomes “non-negotiable.” Nothing stops; everything becomes urgent.
At that point, executives often look downstream and conclude that delivery is the problem.
But if the system has been overloaded upstream, delivery teams are simply where the failure becomes visible.
This is why I consider Delivery Predictability a governance indicator rather than merely a project-management metric. It can be calculated as:
Committed outcomes delivered within agreed tolerance / Total committed outcomes × 100
Used alone, that metric can be misleading. A drop in predictability may indicate weak execution, but it may also reflect excessive work in progress, unresolved dependencies, slow decision-making, critical skill bottlenecks, accumulated technical debt or declining quality.
That is why I would read Delivery Predictability together with Strategic Capacity Allocation, Work in Progress, Decision Cycle Time, quality leakage and major dependency exposure. The objective is not to create a larger dashboard. It is to determine whether governance is asking the delivery system to do something structurally impossible.
That distinction matters enormously at C-level because it changes the intervention. If the problem is capacity, adding pressure will not fix it. If the problem is decision latency, adding delivery resources may not help. If the problem is quality leakage, accelerating throughput can actually make performance worse.
Experience teaches you to distinguish those patterns.
Agility is the ability to adapt without losing control
Agility suffers from a similar problem because many organizations confuse adoption with capability. They run sprints, hold daily stand-ups, conduct retrospectives, use Product Owners and manage backlogs, yet remain slow to respond when strategic priorities change.
The presence of Scrum does not make an organization Agile.
The more relevant question is whether the organization can absorb meaningful change without destroying focus, predictability, quality and control. This is where indicators such as Lead Time, Flow Efficiency and Work in Progress become more useful than counting ceremonies or teams.
For example, Flow Efficiency can be calculated as:
Active work time / Total elapsed delivery time × 100
A low result often reveals that work is spending far more time waiting than being actively progressed. That waiting may be caused by approvals, dependencies, handoffs, environments, governance forums or unclear ownership. In other words, what appears to be an Agile delivery problem may actually be a governance-design problem.
The same logic applies to Work in Progress. Organizations sometimes equate high utilization with efficiency, but once teams are loaded beyond sustainable capacity, flow slows down, context switching increases, defects rise and predictability deteriorates. The objective should not be to maximize utilization; it should be to maximize sustainable throughput and the ability to respond to change.
That is a very different management philosophy.
Quality Engineering protects Delivery Capability
Quality is another area where governance often looks at the wrong end of the problem.
When quality is treated primarily as testing performed near the end of the lifecycle, defects are discovered after significant capacity has already been consumed. The organization then pays again to diagnose, fix, retest, redeploy and manage the operational consequences.
Quality Engineering changes that equation because quality is designed into architecture, requirements, engineering practices, automation, integration, deployment, observability and production feedback.
At governance level, this means quality is not simply a technical concern. It is directly connected to risk, cost, speed, capacity and business continuity.
Metrics such as Defect Escape Rate and Change Failure Rate are therefore valuable because they show how much instability is escaping into production:
Defects detected after release / Total defects detected × 100
and
Production changes causing incidents, rollback or remediation / Total production changes × 100
The interpretation, however, matters more than the arithmetic. A high escape rate may indicate insufficient automation, weak engineering discipline, architectural fragility or compressed testing caused by unrealistic deadlines. A very low rate can also be misleading if it has been achieved by introducing so many controls that delivery has become painfully slow.
The objective is not maximum control. It is the appropriate level of engineered control for the risk, maturity and operating context of the organization.
That balance is where Quality Engineering becomes part of governance rather than a downstream testing concern.
Enterprise Architecture must be executable
Enterprise Architecture belongs in the same conversation because architecture is where strategic intent begins to acquire structural form.
A strong architecture function should help the organization understand which capabilities it needs, how information should flow, how applications and platforms should evolve, where technology debt is accumulating and how current investments move the organization toward the desired future state.
But architecture only creates value if the organization can act on it.
A target architecture can be technically impeccable and still fail if the organization does not have the budget, skills, sequencing, capacity or maturity required to reach it.
This is why Architecture Compliance Rate should never be interpreted mechanically. It may be useful to calculate:
Initiatives aligned with approved architecture principles / Total evaluated initiatives × 100
but a complementary Architecture Exception Rate can be equally revealing. If exceptions are consistently high, one possibility is that teams are ignoring architecture. Another is that the architecture is repeatedly colliding with operational reality.
Those are very different governance problems, and no formula will tell you which one you have.
Experience will.
Context determines the governance model
This is also why copying governance models between organizations is dangerous.
A bank operates under a very different combination of regulatory scrutiny, cybersecurity requirements, operational risk, resilience expectations and reputational exposure than a retailer. A technology company serving financial institutions must reconcile engineering velocity with the control expectations of its banking clients. Retail may place greater weight on customer experience, omnichannel continuity, transaction volumes, availability, supply chain responsiveness and speed to market.
Size matters just as much. A multinational can sustain specialized governance functions, architecture boards, risk committees and formal control layers that could suffocate a mid-sized company. A small organization can destroy its own responsiveness by importing an enterprise-grade governance model before it has the maturity to absorb it.
And geography adds yet another layer.
Anyone who has led technology or transformation initiatives in Latin America understands that budget constraints, specialist talent availability, regulatory differences, informal decision structures, leadership culture and execution urgency shape what is realistically possible.
That does not make best practices irrelevant. It makes tailoring essential.
Tailoring is not what you do after selecting the framework because implementation became difficult. Tailoring is the deliberate design process through which you determine which practices the organization needs, how deeply they should be implemented, what sequence makes sense, what can be absorbed now and what should be postponed.
In my experience, that is precisely where the difference between conceptual knowledge and executive capability becomes visible.
A practical executive view
Rather than evaluating governance through hundreds of controls or isolated maturity models, I prefer to look at the system through a smaller number of integrated dimensions.
A useful executive view can examine Strategic Alignment & OKRs, Governance & Decision Rights, Enterprise Architecture & Investment, Delivery Capability, Agility & Flow, Quality Engineering, Risk & Resilience, and Performance & Value Realization.
Each dimension can be scored from 1 to 5, from Ad Hoc to Adaptive, and weighted according to business context. The resulting Technology Governance Capability Index can be calculated as:
Σ (Dimension Score × Dimension Weight)
The index is not valuable because it produces a number. It is valuable because it exposes imbalance.
A company may score highly in Risk & Controls but poorly in Delivery Capability, which means it is protected but slow. Another may score highly in Agility but poorly in Architecture, which can produce speed without structural coherence. A third may deliver quickly but score poorly in Quality Engineering, creating a system that generates output faster than it can sustain it.
That is what an executive governance model should reveal: not whether every practice exists, but whether the system as a whole is balanced enough to produce strategy, control, adaptability, quality and value at the same time.
The real “blending”
Which brings me back to that original conversation.
Maybe the irony is that “blending” actually does belong in Technology Governance after all, just not as a formal COBIT concept.
The real blend is the ability to connect strategy, OKRs, governance, Enterprise Architecture, Delivery Capability, Agility, Quality Engineering, risk, measurement and people into an operating model that fits the organization in front of you.
COBIT can contribute to that model. So can ITIL. So can Agile practices, Scrum, Kanban, architecture frameworks, KPIs, OKRs, management practices, engineering disciplines, best practices and lessons learned.
But none of those tools has intrinsic value simply because it has been implemented. Their value appears only when they help the organization make better decisions, allocate capacity more intelligently, reduce avoidable risk, improve quality, adapt faster and produce measurable business outcomes.
And that is where experience becomes impossible to replace.
Knowledge gives a technology leader access to the available tools, but experience reveals how those tools behave once they encounter real constraints. Over time, that experience becomes judgment: the ability to determine which practice to use, how deeply to apply it, what to adapt and what to leave out altogether. Execution then becomes the ultimate test because results, not terminology, show whether that judgment was sound.
That also explains the title.
A perfect square trinomial works beautifully because mathematics gives us known relationships and controlled rules. Organizations do not behave that way. A company can have the right framework, a sound architecture, proven methodologies and well-designed controls, and still fail to produce the expected outcomes because those elements depend on maturity, culture, decision speed, delivery capacity, quality practices and the organization’s ability to absorb change.
That is why being theoretically correct is not enough in Technology Governance.
The real objective is to create the conditions that allow strategy to become predictable, high-quality execution.
And that is something no framework can do by itself.
Experience is what makes the difference.
