After three years investing in and advising others' ventures, executive IT consultant Christoph Hesterbrink has developed a sharper view of what makes transformations succeed and the hard questions about readiness, legacy systems, and evidence that leaders skip at their peril.
Three years away from day-to-day IT leadership gave me something I did not have while I was in it: distance.
Since leaving, I have invested in and advised startups, advised on ERP transformations, and chaired my municipality's Finance Board. Those roles gave me a clearer understanding that insight alone does not move an organization. It must be translated into a coalition of trust, where people with different incentives, responsibilities, and authority can work together.
As an investor, I test assumptions before committing capital. Do the founders understand what they are asking for, and have they confronted the hard constraints? Seeing those questions from the outside showed me how directly I should have asked them inside my own transformations.
I saw that clearly when I looked back at my own work. Transformations often take far longer than planned, in part because they inherit systems, processes, and decisions made years earlier. That is not because the transformation team lacked commitment or because the work was poorly executed. I had been very good at solving the problems in front of me. But I now see that I focused too much on fixing and not enough on educating the executives sponsoring the change.
I understood how deeply those older systems were woven into the business—the exceptions they carried, the processes built around them, and the tradeoffs a replacement would force. I should have translated that knowledge more clearly for the executives approving the transformation and made those dependencies and commitments impossible to mistake for details IT could simply absorb.
Executives value fixers like me because they make difficult problems feel manageable. But when a fixer absorbs every complication, sponsors may underestimate what the transformation requires. The fixer's responsibility is not only to solve the problem, but to help sponsors understand and own the transformation's decisions, costs, and tradeoffs.
Three questions now shape how I think about transformation: Is the organization ready? Can legacy be prevented from consuming the future? And will the program produce evidence early enough to change course affordably?
1.) If the Conditions Aren't Right, Don't Do It
Readiness isn't a feeling in the room or a green light from the steering committee. It is whether leaders understand the commitments they are making and are prepared to own them. Appetite for change and readiness for change are different things. Confusing them is how capable CIOs end up carrying risks the organization never fully agreed to own.
Before agreeing to lead a transformation, I ask:
-
Does leadership understand what it is changing and what the change will require?
-
Will business executives commit their time, credibility, and people—not just approve a budget?
-
Can they describe success in operational terms and accept the disruption required to achieve it?
If the answer to any of these is no, the organization isn't ready. That's not a failure of IT; it's a signal to change the plan. A conventional technology roadmap, aligned to business objectives but without the "transformation" label, is often the better fit. It’s less disruptive and the leadership team isn't quietly hoping IT will absorb the risk they weren't willing to own.
A CFO once insisted we could transform the organization while continuing to support the legacy environment with the same team and budget. I told him plainly that we couldn't do both with the same resources. He did not like hearing it. But I stuck with the facts. Transformation would require capacity the legacy environment was already consuming, and someone had to choose what to protect, defer, or fund. I held my ground.
Over time, the disagreement turned into one of the more productive working relationships I've had. A fixer's job isn't to make every demand look achievable. It's to make the tradeoffs visible, even when saying so out loud is uncomfortable.
2.) Don't Let the Legacy World Drive the Bus
Readiness is necessary but not sufficient. Even prepared organizations can be worn down by the systems still running the business. Those systems still must process orders, pay people, and remain compliant while the new environment is built. Unless their demands are tightly controlled, they will consume the team and budget the future requires—one reasonable request at a time.
The legacy environment must support the business, but it shouldn’t control the transformation's pace or priorities. In practice, that means:
-
Protecting operations, security, and compliance.
-
Ring-fencing the transformation team and its capacity.
-
Documenting critical dependencies and limiting enhancements or customization.
We had to stabilize the old environment before pushing hard on the new one. We documented critical interfaces and made sure no single person was the only one who understood them. Life support is not restraint for its own sake. It keeps the past from ambushing the people building what comes next.
3.) Build for the Real World, Move Quickly, and Manage Risk Continuously
The transformations that concern me most aren't the ones that hit a snag early. They're the ones that take years to reveal that their assumptions were wrong. By then, changing course costs far more than it should.
Don't wait for a three-year, big-bang deployment to discover whether the program works. Instead:
-
Deliver meaningful outcomes every 30, 60, or 90 days.
-
Test with real users, real data, and real business processes.
-
Look for risks and bad assumptions early, while they're less costly to fix.
Moving quickly doesn't mean rushing. It means shortening the distance between an assumption and the evidence that confirms or challenges it.
In one e-commerce implementation for a manufacturing company, the software had been selected after a series of persuasive demonstrations. The team believed it could handle the requirements; I suspected the demos had not exposed the gap between the vendor's assumptions and the client's operational complexity.
We used the first two sprints to build a proof of concept with real scenarios and brought the product owner, business users, developers, and configurators into the same working sessions. The system handled basic cases, but the more complex products exposed significant shortfalls, as well as deeper problems in the client's data and processes.
The evidence forced a more realistic plan. We adjusted the budget and timeline and narrowed the first release, leaving the most complex product out of the initial phase. Early testing didn’t derail the transformation; it made the plan credible.
A 30-day checkpoint should do more than report progress. It should test the assumptions behind the business case while they are still affordable to change.
Three years away from IT taught me that a technologist must find their voice early—not after credibility is fully established, but while the work is still proving itself. An effective IT leader must articulate what the organization needs to hear, even when staying quiet is easier. That's the difference between fixing what's in front of you and helping sponsors understand what the transformation requires.
