Getting executive agreement on strategic priorities is the easy part. Maintaining it is hard. IT executive and advisor Eduard de Vries Sands explains how to design commitment mechanisms that last: align around outcomes before work starts, build in incentives for business leaders, and protect what matters.
Most C-suite teams can agree on key priorities for their organizations when they’re in the same room. For example, they may decide that it makes complete sense to consolidate on a single order-to-cash process to leverage scale. But very few stay aligned twelve months later. The difference is not effort or goodwill. It's design.
The CIOs who move their organizations forward aren't the ones who facilitate the best alignment conversations. They're the ones who build commitment mechanisms that make the agreed outcome the easiest path for everyone to take. That's a fundamentally different skill from running a meeting—and one of the highest-leverage things a technology leader can do.
CIOs who design commitment into the structure of a program, rather than relying on agreement alone, hold alignment even when priorities shift and focus moves elsewhere. A few principles can help CIOs design commitment that sticks, at any scale, in any organization.
Agreement Is Incidental. Commitment Is Intentional.
When a program launches with a room full of nodding heads but no mechanism behind them, it's already in trouble. Priorities will shift. Budgets will tighten. Business leaders will get pulled into their own fires.
The technology team will keep building, but the business alignment that started the program will quietly erode.
The solution isn't more meetings or better communication. It's structural: tie the outcome to something stakeholders already care about—a forecast, a metric, a tradeoff they've already accepted. You want the right outcome to be the easiest path, and the wrong outcome to require active work to achieve. When the mechanism does that, alignment holds even when attention drifts.
Designing Commitment at the Enterprise Level
Earlier in my career, I led a finance and supply chain transformation for an enterprise with over $10 billion in revenue. The expected annual savings were in the eight figures, with a two- to three-year payback. All of the benefits were hard cost reductions: consolidated supply chain purchasing, volume discounts across the enterprise, and reduced banking transaction costs across all legal entities, with no labor reductions assumed. The easy path would have been to approve the program, track the savings as they came in, and report results quarterly.
We took a different road. When the program was approved, we loaded the savings directly into the P&Ls of each business unit, not as a future target, but as a commitment inside the business unit’s forecast. This meant our business leaders could only hit their targets if the program delivered on the committed outcomes. It was part of the deal when we said yes.
The effect was immediate. Every business leader had real skin in the game for the program's success. It was no longer an IT project they supported. It was a forecast they needed to protect. The technology team and the business team were committed to the same outcome, with the same timeline, and the same financial consequences if we slipped.
A year in, when competing priorities emerged, we didn't need to renegotiate alignment. The forecast was the alignment. Business leaders were already invested because the savings were already counted. The commitment mechanism did the work that a thousand steering committee meetings could not.
Designing Commitment at the Operational Level
The same principle applies to situations on a smaller scale.
A few years ago, at a large medical group, we had a credit card processing system that finance loved. Daily reconciliation was an hour shorter than the old system. It was integrated with their preferred banking partner. For the people managing the books, it was a clear improvement.
Then I visited the clinics and spent some time checking patients out after their appointments. What I found was different. Every checkout required manually copying the patient's name and amount due from the electronic medical record into a completely disconnected credit card application, running the transaction, and then manually recording the payment back in the EMR. Each checkout took over a minute, while the patient waited. And every office manager spent about 30 minutes a day reconciling payments with the EMR because manual entry led to errors at scale.
Finance was saving an hour a day. But the clinics were losing 30 minutes a day per location, the patient experience was suffering at every checkout, and point-of-service collections were weaker than they should have been.
We had a choice. We could further optimize the existing system, or we could redesign it around the outcome that actually mattered: a fast, accurate checkout where patients pay at the time of service.
We chose the latter. We committed upfront. Success would be measured by checkout speed, clinic reconciliation time, and point-of-service collections, not by the convenience of the finance back-office. Once we made that commitment, the decision was easy. We switched to an integrated solution that processes payments directly within the EMR.
The results were clear. Checkout time dropped significantly. Each clinic saved 30 minutes a day on reconciliation. Point-of-service collections improved meaningfully, because payments that previously were routed for back-office follow-up were captured at checkout (where they're both cheaper to collect and more likely to be collected in full). Finance gave back an hour of easier reconciliation and accepted a slightly harder process in its place. That was the tradeoff. It was the right one.
The commitment mechanism here was different from the enterprise example, but the logic was the same. We decided upfront which outcome we would protect. When the time came to choose a tradeoff, we already knew which way it would go.
What Effective Commitment Mechanisms Have in Common
There's an old line about breakfast: the chicken is involved because it provides the eggs; the pig is committed because it provides the bacon. Most executive alignment produces “involved chickens”. The goal is to design a system that produces “committed pigs”.
The critical work happens before the program starts, not during it. In the enterprise finance transformation, the commitment was financial: savings were booked into forecasts on approval day. In the clinic payment system, the commitment was operational: the protected outcome was agreed upon before we evaluated solutions. In both cases, the commitment made the right decision easier to reach when tensions arise.
Three things make a commitment mechanism real:
-
It's agreed before the work starts, not during it. Once a program is underway and pressure mounts, the window for designing commitment has closed. You have to build it in at the beginning, as a condition for program approval.
-
It changes the incentives of the people who could otherwise drift. A business leader whose forecast depends on the program is a different stakeholder than a business leader who is "supportive" of the program. A finance team that has already agreed to a harder reconciliation process is a different partner than one being asked to accept one after the fact.
-
It protects the outcome that matters, not the activity that produces it. Most misalignment occurs because teams drift toward activity metrics that are easier to hit than outcomes. A well-designed commitment mechanism ties success to the outcome, making drift visible and costly.
What This Asks of the CIO
Integrating commitment into the structure of a program is the work of the modern technology leader. It's harder than running a technology department. It requires business fluency, executive credibility with the CFO and COO, and the willingness to have uncomfortable upfront conversations that most programs skip.
And it’s what separates CIOs who deliver technology from those who deliver outcomes. Boards and CEOs notice the difference quickly.
Commitment mechanisms aren't a nice-to-have. They're the design choice that determines whether alignment endures.
Those who’ve worked with me know one of my operating beliefs: alignment is not a conversation; it's a design choice. Design it in early, or you'll spend the rest of the program wishing you had.
Written by Eduard de Vries Sands
Eduard de Vries Sands is a 2025 ORBIE Global CIO Award Finalist and former CIO of EVERSANA, where he led technology, product operations, and global software development teams across four continents. He has delivered seven-figure EBITDA impact across private-equity backed healthcare and life sciences companies, including leading SAP S/4 HANA cloud transformation and driving commercial technology strategy in life sciences. Eduard specializes in turning technology into competitive advantage for PE-backed portcos and large enterprises. He is currently pursuing permanent CIO/CDIO opportunities with the right organization.