The Two Tells

Every trend report published this year will tell you what mature AI governance looks like. Workforce evolution. Data discipline. Unified trust fabrics. Cost observability. The checklists are comprehensive. The frameworks are polished. The roadmaps progress neatly from “early stage” to “mature.”

None of them answer the only question that matters: Can your organization actually do any of this?

I’ve spent my whole career watching governance initiatives succeed and fail across infrastructure, cloud, and now AI. The technology changes. The organizational dysfunction doesn’t. The patterns that killed cloud governance programs in 2018 are killing AI governance programs right now, in real time, at organizations that have read all the right articles and hired all the right consultants.

The problem isn’t the framework. The problem is that nobody asks whether the organization wants what the framework requires, or can receive it.

There are two tells. They’re visible early. And they’ll save you eighteen months of building something that was never going to work.

The frameworks tell you what to build. The tells reveal whether it will be the sun or a shooting star.

Tell 1: Perform vs. Want

This is binary. It’s visible almost immediately. And it predicts everything that follows.

Does leadership want governance, or are they performing it?

The distinction matters because it determines whether your governance body will have authority or just responsibility. An organization that wants governance vests real decision-making power and accountability in the structure. An organization performing governance creates the appearance of oversight without the substance.

The tells for performance are obvious once you know to look:

Governance was mandated by an external force. An audit finding. A regulatory requirement. A board question that needed an answer. The initiative exists to satisfy someone outside the organization, not because leadership believes it creates value.

The governance body has responsibility without authority. It can review. It can recommend. It can document concerns. What it cannot do is shape how choices are framed or establish the boundaries within which teams operate. It reviews decisions already made rather than influencing the landscape those decisions emerge from.

No executive has personal accountability tied to governance outcomes. The body reports up, but nobody’s compensation or career trajectory depends on whether governance actually works. It’s orphan infrastructure.

The word “lightweight” keeps appearing. Leadership describes what they want as “lightweight governance” or “streamlined oversight.” Translated: they want the appearance of governance without the friction that makes governance effective.

Leadership presents as a monolith. Everyone agrees. No productive tension exists. Decisions flow smoothly because no one challenges them. This feels like alignment but it’s performance. Real governance requires real debate. When leadership is a monolith, groupthink has already won, and governance becomes another rubber stamp.

I’ve walked into organizations where I knew within a week which path they were on. At one, I was hired specifically to sit on a governing body. By day five, it was clear the body was window dressing for the board. It existed so leadership could report to shareholders that governance was “in place.” It had no authority. It wasn’t meant to. I didn’t stick around long enough to be involved in the fallout. I dodged a bullet.

If your organization is performing governance, nothing you build will have authority. Your architects already know it.

Tell 2: Design vs. Translate

Does the organization understand that architecture is translation?

This matters because governance bodies fail the same way architects fail: when the organization thinks they’re there to produce artifacts rather than cultivate alignment.

Most organizations hire architects to design. Draw the diagrams. Produce the reference architectures. Document the standards. They want the deliverables without the difficult conversations those deliverables should provoke.

But you can’t architect what you don’t understand. The job isn’t producing technical artifacts. The job is translating between business reality and technical possibility. Making the invisible visible. Surfacing conversations that artifacts alone can’t have.

Organizations that don’t understand this treat architects as expensive drafters. And they treat governance bodies the same way. They want policies, standards, review checklists. They want documentation they can point to. What they don’t want is a function that enables alignment between what the business says it wants and what the business is actually willing to change.

“We didn’t hire you to tell us how to run the business. We hired you to design the platform.”

That’s the tell. The organization just revealed they’ve separated technical decisions from organizational reality. They’ll treat governance the same way. They want the artifacts without the translation that makes artifacts relevant.

The signals often appear before you even start. A terrible hiring process. A role that changes between interview and offer letter. An inability to articulate what they actually need. These aren’t administrative errors. They’re an organization showing you it doesn’t understand translation at any level. If they can’t translate what role they’re hiring for, they can’t translate what they need from a governance body.

I’ve learned to trust these early signals. I once ignored them. The hiring process was chaotic. The role in my offer letter didn’t match what I’d interviewed for. I took the job anyway. Within months, I was being told to sit in the corner, be quiet, and be thankful for a paycheck. The tells were there before day one. I just didn’t want to see them.

An organization that thinks architects design rather than translate will treat governance as artifact production. The dysfunction is identical.

The Conversation That Clarifies

I had an exchange recently with a peer architect, Justin Snyder, that surfaced something important. We were discussing an article about Copilot implementations and the factors that drive real transformation.

I made the case that governance is the key. Without a governing body, everyone does their own thing without knowledge of what’s happening elsewhere.

Justin pushed back. Governance is crucial, he said, but trying to drive solely through a governance body will fall flat. The priorities of decision areas conflict. You need functions outside the governance body too.

We were both right. We were just describing different layers.

Justin’s point: governance bodies don’t drive transformation. They shouldn’t. A governance body that tries to drive becomes a traffic cop, and traffic cops create the resistance that makes people hate governance.

My point: without the governance body, there’s no coherence. The function isn’t to drive. It’s to facilitate. Standardization and innovation. Structure that enables rather than controls.

The exchange clarified something the diagnostic needs to acknowledge. Even practitioners who intellectually agree governance matters will deprioritize it because structure feels slower than building. The tell isn’t whether people say governance is important. The tell is whether they treat it as required and valued or an afterthought.

Justin and I arrived at the same conclusion from different directions. That’s what good discourse does. Most organizations never get there because they never have the conversation.

Governance doesn’t drive. It facilitates. The organizations that understand the difference can build something real.

The Forcing Function

Here’s the real world: organizations don’t shift from Perform to Want voluntarily.

The initial posture usually predicts the trajectory. An organization performing governance will continue performing it until something forces a change. That something has to be of equal or greater magnitude than the inertia holding the performance in place.

Usually, it’s pain.

I learned this in business continuity and disaster recovery. Nobody wants BC/DR. It’s insurance against something they don’t believe will happen. They fund it minimally, staff it reluctantly, and treat tabletop exercises as theater.

Then disaster happens.

At one organization, I raised alarms for months. The risks were documented. The gaps were clear. Leadership acknowledged them and chose to accept the risk. Then the disaster hit, and suddenly the organization wasn’t happy that we weren’t prepared. Hearts and minds changed overnight. Not because my arguments got better, but because pain taught what translation couldn’t.

After that, I stayed for years. Not because every recommendation was accepted. They weren’t. But the organization had demonstrated it could learn. It had moved from Perform to Want through the forcing function of failure. That’s an improvable environment.

AI governance will follow the same pattern. The organizations performing governance now will learn to want it after the model drifts into production and causes visible damage. After the vendor AI introduces bias into a customer-facing process. After the compliance violation lands and the board starts asking questions that “we have a governance body” can’t answer.

Pain teaches what translation can’t. The question is whether you want to wait for it.

The forcing function is almost always pain. The organizations that learn are the ones that survive the lesson.

What You’re Signaling

Two tells. Both visible early. And your architects see them whether you realize it or not.

If your organization is performing governance and treats architecture as artifact production, your architects know. They knew within weeks of joining. And they’ve already made a decision about how much of themselves to invest in work that won’t land.

The best ones leave. That’s actually the better outcome for you, because at least you know you lost the capability. You can try to backfill. You can ask yourself hard questions about why they left.

The worse outcome is when they stay and disengage. You still have the headcount. You still think you have the capability. You don’t. You have someone showing up, producing the artifacts you asked for, documenting objections that will never be read, and waiting for the inevitable. Quiet quitting is invisible until the moment you need what they were supposed to provide and discover it was never really there.

I’ve been the architect who left. I’ve seen the window dressing, recognized it early, and made the professional decision to find somewhere my work could matter. What you lost wasn’t a headcount. It was every conversation I would have surfaced, every risk I would have translated, every alignment I would have cultivated if you’d let me.

I’ve also been the architect who stayed and fought. In organizations that challenged my translations constantly. That pushed back on recommendations. That made me defend every position. Those organizations got my best work, not because they agreed with me, but because the engagement was real. How your organization engages with your architects’ work matters more than whether you agree with any single recommendation.

Your architects already know which organization you are. The question is whether you do.

What the Trend Reports Miss

The articles will keep coming. AI governance frameworks. Maturity models. Roadmaps from early stage to advanced. They’ll describe what good looks like with increasing precision.

What they won’t tell you is why your organization can’t get there.

That’s not a question frameworks can answer. It requires looking at yourself honestly. It requires recognizing that the governance body you stood up isn’t failing because the framework was wrong. It’s failing because you’re performing governance rather than wanting it. Because you hired architects to draw diagrams rather than translate. Because the signals you’re sending tell everyone who could help you that their work won’t matter.

The governance body won’t bootstrap itself. The translation won’t happen automatically. And no framework, however comprehensive, will overcome an organization that’s performing structure rather than wanting it.

Two tells. Perform vs. Want. Design vs. Translate.

Your architects already checked them. They decided accordingly.

The question is whether you’re willing to see what they see. And if you don’t like what you find, whether you’re willing to become the forcing function before pain does it for you.

The frameworks tell you what to build. The tells reveal why you keep failing to build it.

Start Here: A Governance Charter That Means Something

If you’ve read this far and recognized your organization in the wrong places, here’s where to start. Not a framework. Not a maturity model. A single page that forces the conversation that matters.

Adapt it. Make it yours. But before you stand up another governance body, make leadership sign something that commits to Want, not Perform.

TECHNOLOGY GOVERNANCE CHARTER

PURPOSE

This governance body exists to enable success, not enforce compliance. We are a 
technology office - a place for guidance, counsel, and assistance. Teams operate 
within established boundaries; we exist to help them thrive within those boundaries.

We are not a checkpoint. We are not a blocker. We are the resource teams turn to 
when they need help navigating complexity.

COMMITMENTS

We commit to Want, not Perform. This body exists because leadership believes 
governance creates value, not because an audit or board required it. If that 
changes, we will dissolve this body rather than let it become theater.

We commit to shaping choices, not reviewing decisions. Our role is upstream - 
establishing boundaries and frameworks within which teams have freedom to operate. 
We do not exist to approve or reject work already completed.

We commit to translation. We bridge business reality and technical possibility. 
We make the invisible visible. When misalignment exists between strategy and 
execution, surfacing that misalignment is our responsibility.

We commit to authority with accountability. This body has the authority to 
establish boundaries and frameworks. With that authority comes accountability 
for outcomes. Named leaders below accept both.

ACCOUNTABILITY

Executive Sponsor: ______________________________  Date: __________

This individual has authority to resource, empower, and defend this body's mission.
Their accountability is tied to governance outcomes.

Governance Lead: ______________________________  Date: __________

This individual owns day-to-day operations and is accountable for the body 
functioning as a technology office, not a bureaucracy.

RENEWAL

This charter will be reviewed in 12 months. If this body has become performance 
rather than genuine governance, we commit to acknowledging that honestly and 
either recommitting or dissolving.

Reviewed: __________  Outcome: [ ] Recommit  [ ] Dissolve

Copy this. Adapt it. Put it in front of leadership. If they won’t sign it, you have your answer.

Photo by Kristina Flour on Unsplash