The Pyramid Series, Part 2: The Technology Leader’s Dilemma — Why CTOs Build the Pyramids They Swore They’d Tear Down

You Build What You Know

Here’s an uncomfortable truth: most technology leaders build organizations that mirror their own career path.

A CTO who came up through infrastructure builds an infrastructure-first org. A VP of Engineering who spent a decade in governance builds governance-heavy processes. A CIO who cut their teeth in audit and compliance builds an org that treats compliance as the primary deliverable.

This isn’t malicious. It’s human nature. We default to what we know. The problem is that what got you here won’t get your organization there. The skills that make someone an excellent infrastructure architect or a meticulous compliance officer don’t automatically translate into the skills needed to lead a modern, delivery-focused technology organization.

The result is a predictable pattern:

• Leaders from governance backgrounds build organizations where every decision requires a review board, every change needs a committee, and every release needs twelve signatures. They genuinely believe this is what “good” looks like because it’s all they’ve ever seen.

• Leaders from operations backgrounds build organizations optimized for stability over speed. Uptime is sacred. Change is risk. The safest deployment is the one that doesn’t happen.

• Leaders from delivery backgrounds build organizations that ship fast—but sometimes at the expense of the governance and support structures that keep things sustainable at scale.

The best technology leaders are aware of their blind spots. They actively compensate for them. They hire people who challenge their defaults. But that requires a level of self-awareness that’s rare in an industry that rewards confidence over introspection.

The Control vs. Enable Mindset

Every technology leader, whether they know it or not, operates from one of two fundamental mindsets:

The Control Mindset: “My job is to make sure nothing goes wrong.”

Leaders with a control mindset see their role as risk mitigation. They build organizations designed to prevent bad outcomes. Every process, every gate, every review board exists to catch mistakes before they reach production. The org chart is a series of checkpoints. Trust is earned slowly and revoked quickly.

The Enable Mindset: “My job is to make sure the right things go fast.”

Leaders with an enable mindset see their role as value acceleration. They build organizations designed to produce good outcomes quickly. Guardrails replace gates. Automation replaces manual review. Trust is the default, not the exception. The org chart is a support structure, not a command hierarchy.

Control-minded leaders ask: “How do we prevent failure?” Enable-minded leaders ask: “How do we accelerate success?” The difference sounds subtle. The organizational impact is seismic.

Here’s the thing: both mindsets produce organizations that handle risk. The difference is how. Control-minded leaders handle risk by slowing everything down and adding human checkpoints. Enable-minded leaders handle risk by automating controls and building them into the delivery pipeline. One approach scales. The other doesn’t.

A control-minded CTO looks at a deployment pipeline and asks, “Where do we add the approval gate?” An enable-minded CTO looks at the same pipeline and asks, “How do we automate the check so the team never has to stop and wait?”

Same risk. Same concern. Completely different organizations.

The Incentive Trap: When Leaders Are Rewarded for Risk Avoidance

If you’re wondering why so many technology leaders default to the control mindset, look at how they’re incentivized.

In most enterprises, technology leadership is evaluated on a fundamentally asymmetric scorecard:

• Ship a feature that generates $10M in revenue? The business unit gets the credit. Product gets a pat on the back. Engineering barely gets mentioned.

• Have a security breach that costs $10M? The CTO gets fired. Publicly.

• Pass an audit with zero findings? Nobody notices.

• Fail an audit? Board meeting. Executive review. Someone’s head rolls.

When your career upside is capped but your career downside is unlimited, the rational move is to optimize for not getting fired. And the surest way to not get fired is to control everything. Add more gates. Require more approvals. Slow things down until the risk of something going wrong approaches zero—even if the cost is that nothing goes right, either.

This is the incentive trap, and it explains why smart, capable leaders build organizations that are catastrophically slow. They’re not optimizing for business value. They’re optimizing for career survival. And the organization pays the price.

A technology leader who is never blamed for a breach but presides over an organization that can’t ship software is—by any reasonable business measure—failing. But in most enterprises, that leader is considered “safe.”

Breaking out of the incentive trap requires two things: a leader brave enough to redefine what “success” means for their organization, and a board willing to measure technology leadership on value delivered, not just incidents avoided.

Modern Organizational Theory: What the Best Leaders Already Know

The good news is that there’s no shortage of proven frameworks for building technology organizations that are both fast and safe. The bad news is that most technology leaders have never studied them.

Here’s a quick tour of the ideas that separate modern technology leaders from the ones still running their org like it’s 2005:

Team Topologies

Matthew Skelton and Manuel Pais’s Team Topologies framework defines four fundamental team types: stream-aligned teams (delivery), enabling teams (support that makes delivery faster), complicated-subsystem teams (deep specialists), and platform teams (self-service infrastructure). The key insight: support teams exist to reduce the cognitive load on delivery teams, not to add to it. If your QA, Cyber, PMO, or EA teams are increasing the cognitive load on delivery, you’ve got the topology wrong.

The Inverse Conway Maneuver

Conway’s Law says your system architecture will mirror your org chart. The Inverse Conway Maneuver says: design your org chart to produce the architecture you want. If you want loosely coupled, independently deployable services, you need loosely coupled, autonomous teams—not a maze of cross-team dependencies and approval chains that force every change through a centralized bottleneck.

Servant Leadership

The concept is simple: leaders exist to serve their teams, not the other way around. In practice, this means a CTO’s job is to remove obstacles, provide resources, and create the conditions for teams to succeed—not to dictate technical decisions from the top of a hierarchy. A servant leader asks: “What do you need from me to ship faster?” A command-and-control leader asks: “Why didn’t you follow the process?”

DORA Metrics and Accelerate

The research from the DORA team (now part of Google Cloud) and the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim proved empirically that high-performing technology organizations are both faster and safer. Deployment frequency, lead time for changes, change failure rate, and mean time to recovery—these four metrics predict both delivery performance and organizational performance. The data is unambiguous: speed and stability are not trade-offs. They’re correlated.

Technology leaders who haven’t internalized these ideas are flying blind. They’re making organizational decisions based on intuition and outdated mental models from the era of waterfall, ITIL v2, and quarterly release cycles. The world has moved on. Their organizations haven’t.

The Missing Piece: A Maturity Assessment That Actually Works

Frameworks and metrics are essential—but they’re useless without a clear picture of where your organization stands today. You can’t apply Team Topologies if you don’t know which teams are functioning as enabling teams and which have become bottleneck gatekeepers. You can’t track DORA metrics if you don’t know whether your SDLC is actually producing the data those metrics require.

This is where a comprehensive Maturity Assessment becomes the technology leader’s most critical tool. Not a one-time audit. Not a consultancy’s 200-slide deck that collects dust. A living, practical assessment that evaluates behaviors and capabilities across the entire organization—from leadership and organizational structure all the way down to SDLC practices, Agile maturity, DevOps adoption, QA processes, security posture, and infrastructure automation.

A well-designed maturity assessment answers four questions that every technology leader needs to obsess over:

• Where are we right now? Not where we think we are, not where last year’s PowerPoint said we’d be—where we actually are. Across every team. Across every practice. Measured against clear, objective criteria that everyone can understand.

• What do we need to focus on? Not everything at once. A good assessment reveals the highest-leverage gaps—the two or three areas where improvement will have the biggest downstream impact on delivery velocity and business value.

• Where do we start? Transformation paralysis is real. Leaders stare at a wall of dysfunction and freeze. The assessment creates a prioritized roadmap: start here, then here, then here. First steps that are concrete and achievable.

• How are we doing? Run the assessment quarterly. Track progress over time. Celebrate wins. Identify areas that are regressing. Make maturity visible to the entire organization—not as a punishment, but as a shared scoreboard.

The key is that the assessment must be comprehensive but usable. It has to span organizational structure, program management, SDLC, Agile practices, DevOps pipelines, QA automation, security integration, infrastructure-as-code, and cross-team collaboration—but it can’t be so complex that only a consultant can interpret the results. The best maturity assessments are visual, intuitive, and actionable. A technology leader should be able to look at the output and immediately know where the pain is and what to do about it.

You can’t flip a pyramid you can’t see. A maturity assessment turns the invisible—the behaviors, the habits, the cultural defaults—into something measurable, trackable, and fixable.

Throughout this series, we’ll keep coming back to the maturity assessment as the connective tissue that ties every transformation lever together. It’s how you diagnose the silos. It’s how you measure the audit flywheel’s grip on your roadmap. It’s how you know whether your support teams are enabling delivery or strangling it. And it’s how you prove to the board that your transformation is working—with data, not opinions.

The Power Asymmetry: Why Technology Leaders Hold All the Cards

Here’s what makes the technology leader’s role so consequential: they are the only person in the organization with the authority to change the pyramid.

Business leaders can complain about slow delivery. Product managers can escalate blockers. Engineers can grumble about process overhead. But none of them can restructure the technology support teams. None of them can change how Cyber, QA, PMO, EA, and Infrastructure operate. None of them can redefine the incentives, realign the metrics, or break down the silos.

Only the technology leader can do that. The CTO, the CIO, the VP of Engineering—whatever the title, this person controls:

• How support teams are structured — as independent silos or as an integrated foundation

• How support teams are measured — on their own output or on delivery outcomes

• How support teams interact with delivery — as gatekeepers or as enablers

• How risk is managed — through manual gates or automated guardrails

• How audits are handled — reactively (throwing bodies at findings) or proactively (automating compliance)

• How the org responds to failure — with blame and more controls, or with blameless retrospectives and better automation

This is an enormous amount of power. And with it comes an enormous responsibility: if the pyramid is upside down, the technology leader owns that. Not the PMO. Not Cyber. Not QA. Not EA. Those teams are behaving rationally within the system the leader created. Change the system, and the behavior changes.

Every dysfunctional technology organization is a reflection of the leader who built it—or the leader who inherited it and chose not to change it.

The Hardest Part: Choosing Courage Over Comfort

Knowing all of this and actually acting on it are two very different things.

Flipping the pyramid means challenging deeply entrenched power structures. The Cyber team that controls access to everything. The PMO that owns the project portfolio. The EA board that approves every technology decision. The QA team that holds release authority. These teams have built empires within the organization, and they will resist any change that threatens their authority—often by invoking the very concerns (security, quality, compliance) that justify their existence.

It means having uncomfortable conversations with the board. “We’re going to deploy more frequently with fewer manual reviews, and here’s why that’s safer, not riskier.” That’s a hard sell when the board’s mental model of technology risk was formed in the era of quarterly releases and change advisory boards.

It means accepting short-term chaos for long-term transformation. Breaking down silos, integrating support teams into delivery, automating manual gates—none of this happens cleanly. There will be a messy middle. The leader has to hold the line through it.

And it means putting your career on the line. Because if you flip the pyramid and something goes wrong during the transition—and something always goes wrong during transitions—you’ll be the one answering for it. The safe move is to leave the pyramid upside down and manage the symptoms. The right move is to fix the structure and accept the risk that comes with change.

The technology leaders who transform organizations aren’t smarter than the ones who don’t. They’re braver. They choose the discomfort of change over the slow decay of the status quo.

But courage without clarity is just chaos with good intentions. Before you start tearing down review boards and restructuring teams, you need to know what you’re working with. Run the maturity assessment first. Understand where your organization is strong, where it’s broken, and where the quick wins are. The assessment gives you the diagnostic foundation to make bold moves that are also informed moves—and it gives you the data to bring your leadership team along for the ride.

What’s Next

The technology leader sets the pyramid. But the pyramid is made of teams—teams that, in most organizations, operate as disconnected silos with misaligned incentives and no shared playbook.

In Part 3: The Silo Factory, we’ll go deep on how Cyber, QA, PMO, Enterprise Architecture, SDLC Governance, Infrastructure, and Reporting become independent fiefdoms—and how a maturity assessment exposes the hidden costs of siloed behavior that no single team can see from inside its own walls.

This is Part 2 of a 6-part series. Read Part 1: A Tale of Two Pyramids if you haven’t already.