Blog

How transformation-ready is your organization?

Take the free 5-minute SPICE assessment — a scored readout across Strategy, Politics, Innovation, Culture, and Execution, plus reading recommendations.

  • Your AI Pilot Didn’t Fail — It Was Never Designed to Succeed

    Let me say the thing nobody says in the portfolio review: your AI pilot didn't fail. Failure implies it had a chance. It was designed to produce a demo, not a decision — and on that measure, it succeeded beautifully.

    Only 19% of CIOs say most of their AI initiatives met ROI goals. The industry keeps treating the other 81% as a technology problem. It isn't. The models worked. The demos dazzled. What failed was everything around the model — the part nobody designed.

    Here's the uncomfortable truth about pilots: a real experiment is designed to be killed. Before it launches, someone writes down what "working" looks like in numbers, what "not working" looks like in numbers, and the date on which the verdict gets delivered either way. That's what an experiment is. What most organizations run instead is a performance — a fixed budget, a friendly use case, a demo date, and an unspoken agreement that success means the demo didn't crash.

    And the tell is always the same: ask what the pilot is allowed to conclude. A real pilot can conclude "don't build this." A theater pilot can only conclude "we need phase two." If killing it was never on the table, you weren't running an experiment — you were running a procurement justification with better lighting.

    Run it through SPICE:

    Strategy. A pilot without kill criteria isn't a strategy; it's a wish with a budget. Before a single line of code runs, write the obituary in advance: under what conditions do we scale this, and under what conditions do we kill it? Put both in writing, signed by the sponsor. If the sponsor won't sign the kill conditions, you don't have a pilot. You have a hobby with headcount.

    Politics. And here is why nobody writes the kill criteria: killing a project is a political act. Somewhere in your organization right now is a zombie pilot — everyone on the team knows it's dead, the metrics quietly say it's dead, but the executive sponsor still loves it, because it was their idea, their budget ask, their story for the board. The portfolio review becomes a funeral nobody wants to attend. So the project shambles on, consuming the two scarcest resources you have: engineering time and executive attention. Leaders are now running portfolio reviews specifically to kill underperformers, and that's progress — but a review doesn't kill projects. Incentives do. If the sponsor's standing depends on the pilot surviving, the pilot survives, and the review becomes theater about theater.

    Innovation. The irony is that the willingness to kill is what makes innovation work. A portfolio where nothing ever dies isn't a portfolio — it's a museum. The organizations getting real returns from AI aren't the ones with the best models. They're the ones with the fastest funerals: small bets, honest verdicts, resources recycled into the next bet within weeks, not fiscal years.

    Culture. Ask what happens to the person who kills their own pilot. In most companies, they get quietly punished — the failed initiative on the performance review, the whisper that they "couldn't deliver." Until killing a dead project is celebrated the way shipping a live one is, your people will keep every zombie alive out of pure self-preservation. And notice who gets blamed when the zombie finally dies of old age: the team that "failed to deliver" — never the sponsor who refused to read the metrics. The people closest to the truth pay the highest price for it, which is exactly why the next team will hide the truth earlier. Culture isn't what your AI strategy deck says. It's what happens to the person who brings bad news early.

    Execution. So here's the machinery: every pilot gets a written hypothesis, a success metric, a kill metric, a verdict date, and a named owner for the verdict — and the owner cannot be the sponsor. Separate the advocate from the judge. When the date arrives, the verdict is delivered in the open, the resources are reallocated within thirty days, and the team is publicly thanked for the learning. Do that five times and watch what happens to your sixth pilot: suddenly everyone designs for the verdict, because they know the verdict is real.

    Today, most AI pilots are designed to never end — no kill criteria, no verdict date, no judge. Tomorrow belongs to the organizations that treat every pilot as guilty until proven innocent, and say so out loud before the money is spent.

    Stop asking why your pilots fail. Start asking who benefits from them never ending.

    Infographic: Your AI Pilot Didn't Fail — It Was Never Designed to Succeed
  • Fifty Agents, No Orchestra: The Sprawl Nobody Budgeted For

    I once argued that AI agents should have job descriptions — a written role, boundaries, KPIs, someone responsible for the outcome. That was the hiring conversation. This is the management conversation, and it's uglier: what happens when every team hires five agents and nobody conducts the orchestra?

    Walk through any mid-size enterprise right now and count. Marketing has a campaign agent and a content agent. Sales has a prospecting agent and a forecasting agent. Support has a triage agent. HR has a screening agent. Engineering has three nobody will admit to. Finance is piloting two. That's fifty agents before lunch, each deployed by a team that did the responsible thing locally — wrote the job description, set the boundaries — and never once asked what happens when all fifty start interacting. The agent that promises a customer a refund by Friday. The agent that approves the budget the first one just spent. Nobody's agent is misbehaving. The ensemble is.

    This is the failure mode nobody budgeted for — literally. Nobody budgeted for it, because nobody planned the fleet. We deployed agents the way we used to buy software: one team at a time, each solving its own problem, each convinced its five agents were the whole story. But agents aren't software licenses. They're workers. And fifty workers with no manager, no org chart, and no shared rules isn't a workforce — it's a crowd.

    Run it through SPICE:

    Strategy. You need an agent portfolio, not an agent collection. Go back to the job-description question and ask its portfolio sibling: which jobs deserve agents at all, and which of those deserve your agents versus a shared service? I'm watching governed agent catalogs emerge — including for federal agencies — and the smart ones aren't bureaucracy; they're portfolio management. A catalog says: here are the approved agents, here's what each is allowed to do, here's who owns it, here's what it costs. That's not red tape. That's the difference between a fleet and a stampede.

    Politics. Here's where it gets delicate: every team owns its agents, and nobody owns the interactions. When marketing's agent makes a promise that fulfillment's agent can't keep, whose problem is that? Marketing's? Fulfillment's? The AI center of excellence that approved both deployments and neither integration? Turf wars love a vacuum, and agent-to-agent interactions are currently a vacuum with API keys. The politics have to be settled explicitly — interaction ownership, escalation paths, who can override whom — before the first cross-agent failure, not during it. Because "not my agent" will become the new "not my department," and it will be just as corrosive.

    Innovation. The real innovation here isn't another agent — it's the conducting layer. A registry where every agent declares its capabilities, its limits, and its owner. Standards for agents to identify themselves to each other and to the humans watching. An orchestration tier that sees the whole ensemble: who's calling whom, who's duplicating whom, who's about to step on whom. The organizations building this now aren't slowing agents down; they're making fifty agents safer than five were without it. Conducting isn't control-freakery. It's what turns noise into music.

    Culture. Start managing agents like the workforce they've become. Onboard them: announced, documented, with a named owner. Evaluate them: against the job description, on a cadence, with consequences. Retire them: decommissioned cleanly when the job changes, not left running in a corner consuming budget and confusing everyone. "You wrote the job description" was step one. Step two is writing the org chart. A culture that treats agents as disposable scripts will get disposable outcomes; a culture that manages them as staff will get leverage.

    Execution. And now the part nobody wants to say out loud: the bill. Metered API costs multiplying across fifty agents. Three teams paying for three agents that do the same job. The security review nobody scheduled because each deployment was "small." Audit the fleet the way you'd audit headcount: every agent gets an owner, a cost center, a kill switch, and a review date. Kill the duplicates — gently, with migration, not with a midnight revocation. And put agent spend in the budget where everyone can see it, because invisible spend is how fifty became a hundred while nobody was watching.

    Today, the enterprise has fifty agents and no orchestra — each one well-behaved, each team responsible, and the whole thing one interaction away from an incident nobody owns. Tomorrow, the winners won't have fewer agents. They'll have a catalog, a conductor, and a budget line with a name on it.

    You wouldn't hire fifty people with no manager, no org chart, and no budget. So why did you do it with agents?

    Infographic: Fifty Agents, No Orchestra: The Sprawl Nobody Budgeted For
  • Your Employees Are Already Using AI — They Just Stopped Telling You

    Here's the number your IT department doesn't want to think about: roughly 45% of enterprises have no real visibility into how their employees are using AI. Nearly half are flying blind.

    Now here's the uncomfortable follow-up: the employees aren't waiting for visibility. They aren't waiting for permission either. The analyst pasting client data into a public chatbot, the marketer generating campaign copy on an unsanctioned tool, the engineer letting an AI assistant read proprietary code — none of them asked. They just did it, because it made Tuesday afternoon survivable. Your AI policy didn't stop AI use. It stopped honesty about AI use.

    This is the part most governance conversations get backwards. Shadow AI is treated as a tooling problem — unapproved software to be blocked, detected, and stamped out. It's not a tooling problem. It's a trust problem, and in most organizations, the governance itself created it. When the official path is a six-week approval process and the unofficial path is a browser tab, employees don't choose the unofficial path because they're reckless. They choose it because they're trying to do their jobs. Heavy-handed governance didn't eliminate the behavior; it eliminated your view of the behavior. You traded visibility for the illusion of control, and the 45% number is the receipt.

    Run it through SPICE:

    Strategy. You cannot govern what you cannot see — so visibility has to come before control, not after it. The strategic move isn't a better ban; it's a better offer. Declare a simple principle: anything employees use openly, on approved rails, is fine; anything hidden is the risk. Then make the approved rails genuinely good — sanctioned models, internal sandboxes, data that stays inside the walls. Strategy here means competing with the shadow, not just condemning it. If your official AI tools are worse than the public ones, your policy is a suggestion and everyone knows it.

    Politics. What we're really watching is a cat-and-mouse game between IT and the workforce, and it's worth asking who's winning. IT bans a tool; employees route around it by Friday. Security blocks a domain; the work moves to personal devices, which is worse for everyone. Each round of prohibition pushes usage further from oversight while teaching employees that the governance function is an adversary. That's a political failure, not a technical one. The departments that "win" the ban usually discover they've won the right to be surprised — loudly, publicly, and at the worst possible moment.

    Innovation. The innovative response isn't detection software — it's disclosure design. Build the internal alternative people actually want: a sanctioned assistant with your company's data, proper guardrails, and none of the friction. Some of the best enterprise AI rollouts I've watched started with the question "what are people already doing in the shadows?" and simply productized the answer. Your employees did your user research for you, for free, at scale. The innovation is listening to it instead of punishing it.

    Culture. Everything hinges on one question: what happens to the first person who admits what they've been using? If the answer is a disciplinary meeting, you've just taught the other 99% to hide better. If the answer is "thanks — here's the approved version, and here's what we learned from your workflow" — you've recruited your best evangelist. Culture isn't the AI policy on the intranet. It's what happened to the last person who got caught, and whether the story that traveled was "they helped me" or "they made an example of me." Trust is the infrastructure; the tools are just paint.

    Execution. Start with amnesty, not audits. Announce a window: declare what you're using, nothing bad happens, and we'll build you a better path. You'll get your inventory — the real one, not the fantasy in the compliance deck — and you'll get it in weeks instead of years. Then catalog what you found, retire the riskiest patterns first, stand up approved alternatives, and train people on the line between "helpful" and "career-limiting." Measure disclosure, not just compliance: the metric that matters is what percentage of AI use you can see, trending up, quarter over quarter.

    Today, nearly half of enterprises can't see how AI is being used inside their own walls — while their employees use it every day, quietly, on tools nobody vetted. Tomorrow belongs to the organizations that made honesty the path of least resistance: declare it, we'll support it, and together we'll make it safe.

    Your people already voted with their keyboards. The only question left is whether you want to know what they voted for.

    Infographic: Your Employees Are Already Using AI — They Just Stopped Telling You
  • Who’s Accountable When AI Adoption Outruns Governance?

    Here's a number that should end meetings: 91%. That's the share of organizations that now admit AI adoption is outpacing their governance — fresh data from October 7, 2026. And here's the one that should start them: a third of leaders say they're personally accountable for AI outcomes they can't actually control.

    Read that again. Accountable for outcomes they can't control. There is a name for that condition in every organization I've ever worked in, and it isn't "a governance gap." It's politics — the purest kind. Responsibility without authority is the oldest power game in the enterprise, and AI just gave it a faster engine.

    We've spent three years writing AI governance as paperwork: principles, committees, policy PDFs that nobody reads until something breaks. Then something breaks, and everyone discovers the paperwork named no one. Governance theater produces exactly what theater produces — a good show and no change in the outcome. Accountability is a different thing entirely. It's a name, a signature, and a person who agreed in advance to own the result. If you can't point to that person before deployment, you don't have governance. You have hope with a compliance stamp on it.

    Run it through SPICE:

    Strategy. Accountability is designed, not assigned. It gets decided before the system goes live — in the same meeting where you approve the budget and the timeline — not in the incident review afterward. For every AI system that touches a real decision, write down three names: who approved its deployment, who owns its outputs, and who can stop it. Not teams. Not committees. Names. Strategy here isn't a framework; it's the refusal to let "everyone owns it" mean "no one owns it." The organizations getting this right treat accountability the way they treat architecture — decided up front, documented, and reviewed when conditions change.

    Politics. This is where it actually lives, so let's name it plainly. In most enterprises, accountability flows downhill while authority stays uphill. The vendor chose the model. A team deployed it under deadline pressure. An executive signed a one-line approval between meetings. And when it fails, the person answering for it is whoever is closest to the blast radius — rarely the person who had the power to prevent it. A third of leaders holding accountability they can't control isn't a data point; it's a diagnosis. The fix is political before it's procedural: give the accountable person real authority — over the data, the deployment decision, and the kill switch — or stop pretending they're accountable and name whoever actually holds the power.

    Innovation. The most useful governance innovation of the last two years isn't a policy — it's machinery. Evals that run before every release. Audit trails that record what the system did and why. A kill switch with a named human on the other end of it. None of this is glamorous, which is exactly why it works: it moves accountability out of the slide deck and into the system itself. An agent you can interrogate, halt, and roll back is governable. An agent you can only describe in a risk register is a liability with good documentation.

    Culture. Here's what determines whether any of the above survives contact with reality: what happens to the person who reports that the AI got it wrong? In a blame culture, accountability means punishment — so failures get buried, near-misses go unreported, and the same failure repeats at larger scale. In a learning culture, accountability means ownership of the fix — so the bad output becomes a ticket, the ticket becomes an eval, and the system gets better. Your governance posture is downstream of that answer. People don't hide AI failures because they're dishonest; they hide them because they've watched what happens to messengers.

    Execution. Make it boring and make it routine. Name one accountable human per AI system, in writing, before go-live — and re-confirm it when the system changes, because it will. Run pre-mortems: "it's six months from now and this system failed publicly — what happened, and who saw it coming?" Audit AI-influenced decisions the way you'd audit expenses — sampling, documentation, a human appeal path that actually functions. And publish the accountability map internally. Sunlight doesn't just deter corner-cutting; it tells every employee exactly whose judgment stands behind the machine's.

    Today, 91% of organizations admit adoption has outrun governance, and a third of their leaders are holding accountability without authority. Tomorrow, the serious operators won't have better policies — they'll have shorter lists. Fewer systems, each with a name attached, each with someone who can stop it and the power to mean it.

    Ask yourself: if your highest-stakes AI system failed spectacularly tomorrow morning, whose desk does the call land on — and did that person agree to it, or did they just get cc'd?

    Infographic: Who's Accountable When AI Adoption Outruns Governance?
  • 5 Questions to Ask About AI Agents

    5 Questions to Ask About AI Agents

    Yesterday I made the case that AI agents need job descriptions — a defined role, authority limits, escalation triggers, an audit trail. Several of you asked where to start. Start here, with five questions. Not about the technology. About the accountability around it.

    In this series I’ve always framed the questions the same way: where you are today, and where you should be tomorrow. Agents are no exception.

    Infographic: 5 Questions to Ask About AI Agents — WHO, WHAT, WHERE, WHEN, WHY

    1. Who — Who is responsible when an agent makes a decision? Today, the answer in most organizations is a shrug, or “the team.” Tomorrow, every agent has a named human owner — someone whose name is on the audit log, who approves scope changes, and who gets the call at 2 AM. Accountability that belongs to everyone belongs to no one.

    2. What — What actions can your agents take right now? Today, most leaders can’t produce a complete list. Tomorrow, every agent operates from a written scope: what it may do alone, what needs approval, and what is forbidden entirely. If you can’t enumerate an agent’s powers, you haven’t granted them — you’ve leaked them.

    3. Where — Where do agents touch your data and systems? Today, agents accumulate access the way closets accumulate boxes. Tomorrow, every integration is mapped, every data store is classified, and sensitive systems are off-limits by default. An agent should have to earn its way into your crown jewels, not inherit the keys.

    4. When — When does an agent escalate to a human? Today, escalation is whatever the vendor set as a default. Tomorrow, you define the triggers: dollar thresholds, confidence floors, novel situations, conflicting instructions — and a rule that silence is never consent. Autonomy should expand on your schedule, not the agent’s.

    5. Why — Why was each agent deployed, and why does it still have its access? Today, agents are deployed for a pilot and forgotten. Tomorrow, every agent’s access has an expiration date and a reason that gets re-examined. The most dangerous agent in your organization isn’t the one that misbehaves — it’s the one nobody remembers authorizing.

    Infographic: 5 Questions to Ask About AI Agents — WHO, WHAT, WHERE, WHEN, WHY

    Ask these five questions in your next leadership meeting. If the room goes quiet, you have your a

    nswer — and your starting point.

    Watch the explainer