Take the free 5-minute SPICE assessment — a scored readout across Strategy, Politics, Innovation, Culture, and Execution, plus reading recommendations.
Every transformation effort runs through the same five lenses: Strategy, Politics, Innovation, Culture, and Execution. Miss one, and the whole thing stalls.
So I turned the SPICE framework into a free 15-question assessment. It takes about three minutes, and it gives you an overall readiness score, a dimension-by-dimension profile, and two priority actions to work on first.
I asked Anupam Khare, the CIO of Oshkosh Corporation, a question that sounds like it’s about analytics and is actually about power: “When it comes to using data for decision making, how do you make sure that an executive or a business leader’s experience — which is to say their bias — doesn’t overshadow what the data is saying?”
Notice the trap inside the question. We assume the data is neutral and the executive is the problem. Sometimes that’s true. Sometimes the executive’s “bias” is twenty years of pattern recognition the dataset hasn’t lived long enough to learn, and the data is a beautifully formatted record of a world that no longer exists.
So the real question isn’t data versus experience. It’s this: in your building, when the two disagree, who wins — and was that ever a decision, or just a habit?
Look at it through the SPICE lenses — Strategy, Politics, Innovation, Culture, Execution:
Strategy. Data and experience answer different questions. Data tells you what happened at scale; experience tells you which parts of what happened actually mattered. A strategy that crowns either one permanently is a strategy with a blind spot by design. The manufacturers who get this right treat the disagreement itself as the signal — when the dashboard and the veteran diverge, that’s not noise. That’s the exact spot where the decision deserves a second hour.
Politics. Let’s be honest about why data usually loses. The person with the experience has the title, the budget, and the relationship with the CEO. The data has a PDF. “My gut says otherwise” is rarely an analytical position — it’s a veto held by someone who has never had to write down what their gut is based on. And here’s the part nobody says in the meeting: executives don’t reject data because they distrust it. They reject it because accepting it would mean a past decision — theirs — was wrong.
Innovation. The genuinely innovative move isn’t a better dashboard. It’s a decision protocol: a standing rule that says when a model and a senior leader conflict above a certain dollar threshold, both sides state their reasoning in writing before the call is made. Oshkosh’s framing — moving from data-driven to data-rich decision making — points the same way. The innovation is in enriching the decision, not automating the decider.
Culture. In most organizations, the career-safe move is to agree with the senior person’s experience and quietly let the data die in an appendix. So that’s what people do, and then leadership wonders why the analytics investment never changed a single outcome. Culture is what happens to the analyst who brings the inconvenient chart. Promote that person once — publicly — and you’ll get honesty for a decade. Bury the chart once, and you’ll get decoration forever.
Execution. So here’s the machinery: pick your ten most consequential recurring decisions. For each one, write down — in advance — what evidence would override the senior person’s judgment, and what experience would legitimately override the model. Review the disagreements quarterly: who won, and were they right? You now have something almost no company has: a track record for both your data and your executives’ instincts. Most leaders grade only one of those.
Today, the winner is decided by seniority and the loser is decided by silence. Tomorrow, the winners will be the companies that made the disagreement a governed event instead of a hallway war.
Ask yourself: in your last big decision, did the data lose an argument — or was it never actually allowed to make one?
The CFO wants ROI. The business unit wants the capability. And IT gets handed both the build and the blame. About 31% of CIOs say they feel accountable for returns they can't influence — and that number should embarrass everyone who isn't in IT, because it describes a broken contract, not a failed function.
Think about what we're actually asking. IT is told to prove the financial return of a transformation it doesn't control. The business unit owns the process, the people, the incentives, and the decision rights — IT owns the model. When the process doesn't change, the model can't produce returns. And then the CIO gets the question: "Where's the ROI?" As if the algorithm were supposed to reorganize the department on its own.
Notice the asymmetry: when the transformation works, the business unit led it. When it doesn't, IT picked the wrong tool. The CIO gets accountability in both directions and authority in neither — responsible for the outcome, powerless over the inputs. No other executive would accept that deal. CIOs accept it every budget cycle.
This is accountability without authority — the oldest trap in organizational life — and we've rebuilt it around AI with a straight face.
Run it through SPICE:
Strategy. ROI doesn't live in the technology; it lives in the changed behavior the technology enables. A model that predicts churn produces zero return until someone changes how retention is worked. A document agent saves zero hours until the approval chain is actually shortened. Strategy means naming, before a dollar is spent, whose behavior changes, by how much, and who owns making that change happen. If the answer to "who owns the change" is "IT," you don't have a strategy. You have a purchase order with delusions.
Politics. Here's why the broken contract persists: it's convenient for everyone except the CIO. The CFO gets a single throat to choke — one budget line, one accountable executive, clean governance theater. The business sponsor gets the upside of the capability with none of the accountability for the outcome; if it works, they led the transformation, and if it doesn't, IT picked the wrong tool. And the CIO accepts the deal because refusing it looks like dodging accountability. Everyone's incentives point at the same fiction: that returns are a property of the technology rather than a property of the organization using it.
Innovation. The genuinely innovative move here isn't a better dashboard — it's a better contract. Joint accountability, written before funding: the business sponsor signs the value case and the specific process changes they commit to, and IT signs the capability delivery. No signed value case, no build. The signature matters more than the spreadsheet, because it converts a vague hope into a named human being with something at stake. Organizations that do this discover something uncomfortable: half their AI backlog evaporates, because nobody will sign for it. That's not a loss. That's the filter working.
Culture. Watch what gets celebrated. In most companies, IT gets praised for shipping the model and blamed for the missing returns — celebrated for the part it controls, punished for the part it doesn't. Flip it: celebrate the business leader who changed their process and can show the number. Make the value case a promotion story, not an IT metric. Culture follows what gets rewarded, and right now we're rewarding IT for building things and business units for watching.
Execution. So here's the machinery. IT measures what's technical: adoption, reliability, latency, usage. The business owner measures what's economic: cycle time, cost per transaction, revenue per head — the numbers that actually appear in the P&L. The two meet in a quarterly review where the business sponsor defends the value case they signed, not the CIO defending a model they built. One more mechanical detail: put that review on the same calendar as the budget review, with the same audience. If the ROI conversation happens in a side meeting with no CFO in the room, it's advisory. If it happens where the money gets allocated, it's governance. And the CFO? Stop accepting ROI reports from IT alone. Demand them from the business owner, and watch how quickly the numbers get honest — nothing sharpens a value case like having to sign it.
Today, we ask the people who build the capability to prove the return, then act surprised when the proof is thin. Tomorrow belongs to the organizations that put the measurement where the ownership is: with the business leader whose process, people, and P&L actually changed.
If you want IT to prove the ROI, give IT the P&L. Otherwise, ask the person who has it.
You applied for a job running technology. You got a job redesigning how humans work. Nobody sent the memo — the title stayed the same, the org chart stayed the same — but somewhere along the way, 92% of North American CIOs became more responsible for redesigning workforce workflows than for managing IT infrastructure. Read that number again: the job is no longer the job.
This isn't a promotion. It's a quiet rewrite of the contract, and most CIOs are still being measured against the old one. The board still asks about uptime, cost per ticket, and project delivery dates — the vital signs of a job that barely exists anymore — while the actual work on your calendar is transformation: which roles change, which processes get rebuilt, which parts of the organization learn to work with machines instead of around them.
Run it through SPICE:
Strategy. You used to own the stack. Now you own the work itself — how it's done, by whom, with what. The strategy question changed from "what do we buy?" to "how should this work be done at all?" That's a business strategy question wearing an IT title. The CIOs thriving in this shift stopped presenting technology roadmaps and started presenting work redesigns: here's the process today, here's who does what, here's what changes when agents take the repetitive half. The laggards are still presenting server refresh cycles to a board that stopped caring three years ago.
Politics. Here's the trap: your authority didn't grow with your responsibility. You are now accountable for how the sales team, the finance team, and the operations team do their jobs — but you don't run any of those teams. Redesigning someone else's workflow is an act of organizational trespass, and every peer executive knows it. The CIOs who survive this don't lead with architecture diagrams. They lead with coalitions — a business sponsor who owns the outcome, a shared definition of done, and the explicit backing to tell a VP that their twenty-year-old process is the problem. Without that, you're just the person with opinions about other people's departments.
Innovation. The irony is that the CIO is the only executive who sees across every silo. Finance sees finance. Operations sees operations. You see the whole workflow end to end, which makes you the only person in the building who can spot the handoff where work goes to die. That vantage point is the actual job now — not the infrastructure underneath it. The innovation isn't the agent or the model. It's finally having someone whose remit covers the seams between departments, redesigning the seams instead of paving over them.
Culture. And this is the part the job description will never capture: redesigning workflows means telling people their jobs change. That's not a technology conversation; it's an identity conversation. People don't resist new tools — they resist the implication that the way they've worked for a decade was wrong. The fear is rational, by the way. Every efficiency drive in corporate history ended with layoffs, and your people have excellent memories. You don't overcome that with a new org chart. You overcome it by making the redesigned work visibly better than the old work — not just cheaper. The CIO's new core skill isn't architecture. It's the ability to walk into a room of people who are afraid and leave them feeling like co-authors instead of casualties. No certification teaches that. No vendor sells it.
Execution. So stop defending the IT budget and start designing the work. Rewrite your own scorecard before someone else does: measure workflow cycle times, adoption of new ways of working, the percentage of processes redesigned versus merely digitized. And rewrite the relationship with your peers while you're at it — you can't redesign someone's workflow as a service provider, with "the business" ordering from "IT" like a restaurant. The new job requires a seat at the strategy table, not a ticket queue. Bring the board a picture of the future operating model, not the infrastructure bill. And have the explicit conversation with your CEO about the gap between what you're measured on and what you're actually doing — because that gap is where CIO careers go to stall.
Today, the title on your door still says technology while the work on your calendar says transformation. Tomorrow, the CIOs who named the shift out loud — who stopped pretending the old job still exists — will be the ones writing the new job description. Everyone else will be managed against a role that's already gone.
You're not the CIO anymore. You're the chief work officer. They just haven't printed the cards.
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.
You must be logged in to post a comment.