I was brought in to fix a framework imposed on an organisation that wasn’t ready for it. I got the redesign right and still misjudged the two relationships that mattered most. A field story about context, politics, and making no assumptions.
Back in the 2010s, I was brought in as an interim executive director to fix a failing IT programme inside one of the most structurally complex environments I have worked in.
A major consultancy had recommended splitting the IT Demand and Supply functions and deploying a new demand and project management framework, backed by a new portfolio tool, new teams and roles. The CEO had just arrived himself. He gave me a clear mandate: assess what we had inherited, keep what was worth keeping, and work on bridging the business / IT gap.
That turned out to be the straightforward part.
The organisation underneath
The group was a federation of health insurers composed of 9 entities: seven independent organisations, each competing for members in the private health insurance market, each with their own leadership, their own commercial ambitions, and their own view of what IT should be doing for them. Above them, a central union responsible for regulatory compliance and shared services, where the IT demand function sat. And alongside, a separate entity acting as IT supplier to the whole group.
This is 3 types of actors, each with very different incentive structures, all sharing the legal mandate to deliver the minimum health insurance coverage required by law. This was enforced interdependence, experienced as obligation more often than as shared purpose. The central body had to federate without the authority to impose. The member organisations cooperated on regulation but competed on everything else. The IT supplier had to serve both the non-negotiable regulatory pipeline and the varying commercial ambitions of organisations with different budgets and priorities. In that kind of environment, priority conflicts are a structural feature.
This was enforced interdependence, experienced as obligation more often than as shared purpose.
The consultancy firm’s actions and recommended framework were not wrong in principle. The destination, a structured demand management function, stronger portfolio management, and a proper architecture practice, was reasonable. What it missed was the organisation’s bigger context: the maturity of the processes, the trust between the actors, the political dynamics that meant any new coordination mechanism would immediately become a battleground for existing conflicts. Deploying an updated governance model on top of a system that has not yet aligned on its shared mission, objectives and operating principles can hardly be successful.
What I did
I dropped most of the “what” and “how” of the framework while retaining the key principles of how a mature IT system of work should operate. I kept the portfolio tool but stripped it back to its default configuration, hired one person to become the group’s expert in it, and committed to introducing new workflows and features only when the organisation was actually ready for them. The tool would follow our growing maturity, designed to support the people and the process rather than drive them.
I spent a significant part of the first year building stronger relationships with most of our stakeholders. Weekly sessions with the IT supplier CEO, then progressively with his leadership team to understand their context and help integrate our internal clients’ perspective better. I toured the member organisations to sit with their directors, listen to what they actually needed, and to promote the agenda and mission of the federation. The priority conflicts that had been escalating as formal disputes started to have somewhere else to go. However, I had underestimated how many there would be and how much of a strain they would become for my team and me.
On the process side, we built a number of pragmatic things: a demand management forum with the member organisations, a monthly one-page report per project for visibility, and a physical control centre where that information was available to everyone involved. It was deliberately not sophisticated. The point was to create shared visibility before shared governance.
The point was to create shared visibility before shared governance.
The work I was most proud of was the shared change initiative we ultimately launched. It was built around a simple, uncomfortable observation: IT Demand and IT Supply may be considered dedicated functions, but cross-functional collaboration between architects, analysts, project managers, delivery and support specialists was not a nice-to-have; it was the only way we would make the whole thing work for the federation.
The breakthrough came from a workshop where both management teams got into the same room and realised they had identical objectives. This started a genuine integration effort facilitated by fully engaged interim managers: project managers from both demand and supply moved to split their time between both entities, working end-to-end on portfolio management together; domain business analysts spent one day a week embedded in the development teams to ensure design and solutions evolved towards the desired results. The boundaries were not abolished but they stopped being a wall. The delivery flow improved. The conversations between IT and the business became less defensive. The energy in the teams shifted, creating a positive context for further change iterations.
This was further supported by the parallel launch of a vast enterprise architecture programme fully approved by the federation board of directors. Its objective: to illustrate the common contexts in which we were all operating, open the door for legacy systems replacement and synergies between the entities. With a 1MEUR budget and a team of eight to ten architects, we worked on documenting the full as-is state and on establishing a solid architecture practice, fully integrated in the demand-supply lifecycle.
Two years into this journey, I was both exhausted and energised. The momentum was only growing and the next phase of the work was taking shape. In the six months that followed, we continued making progress, delivering the change while running operations. By the two and a half year mark though, I resigned.
How it came apart
Over that last year, the CEO had been building a different plan, one he had not shared with his executive team. He hired a senior external consultant to lead a broader transformation initiative and asked me to stop the architecture programme mid-flight, redirecting the budget to fund that work instead.
There was little acknowledgement of what we had done and built to date, or of our plans to continue the journey. I was asked to facilitate the vendor selection for our mainframe replacement while simultaneously taking the lead of the architecture practice but without the external expertise we still needed to be successful.
While a strong mission in itself, what became clear was the absence of genuine dialogue with my boss. I was executing a vision I had no real influence over, without the visibility, openness and collaboration I believed the work required. That felt wrong enough to walk away from.
Executing a vision I had no real influence over without the visibility, openness and collaboration […] felt wrong enough to walk away from.
What I missed
In retrospect, I had not done enough to create a context for success, for the initiative or for myself. I had neglected two of the most important relationships in that organisation.
The first was the CEO. I focused on building the system and the external relationships: the IT supplier, the member organisations, the extended leadership team. I assumed that delivering visible progress would speak for itself. What I underestimated was the political relationship directly above me: understanding his agenda, making myself part of his thinking, staying close enough that I would not be surprised by decisions that directly affected my work. I treated him as the person who had given me the mandate, rather than as someone whose trust needed constant, active maintenance.
The second was some of my own management team, most of them with deep experience and connections within the organisation. I worked productively alongside them, involved them, but still did not invest enough. I assumed that shared direction would be enough and it wasn’t.
In both cases, I had confused relative proximity with alignment. Being in the room, delivering results, being transparent, moving in the same direction is not the same as genuinely bringing someone with you. Focusing only on the mission and on the people who actively reach out and engage is not enough. We also need to invest in those who are present but quiet, or whose buy-in we have taken for granted. Two words I have used as a personal motto since then: no assumption.
Moving in the same direction is not the same as genuinely bringing someone with you.
What I carry into INCEPTI now
I came in to fix a framework that a consultancy had imposed on a system that was not ready for it: correct destination but insufficient attention to context, to maturity, and to the structural tensions. I stopped that initiative, replaced it with something more grounded, and spent two years building a better system of work, carefully and deliberately.
And then, with the best intentions and a great deal of thought, I missed a few key contextual factors and actors, pushing the organisation in the right direction but without a full footing as the political ground above me was shifting in ways I was not party to.
I was more deliberate than the consultancy. I had built real relationships, made genuine hires, brought people along. But I had still, in the end, put more change into the system than the system was either able to absorb and sustain.
The best changes are the ones nobody attributes to anyone. The ones carried by the group. I wrote that at the time for our internal magazine, and I believed it. What I understand now is that for that to happen, the extended leadership team has to be part of building it, not just approving it.
The best changes are the ones nobody attributes to anyone.
Some of our work continued thanks to the talent of some of my team members and the interim managers I had brought in. Bringing demand and supply closer together did gradually deliver better and better results. It opened the way for the full scale deployment of cross-functional teams working iteratively towards shared outcomes. Five years later, it culminated in the full integration of IT supply within the central union, as the federation consolidated from seven to three entities. Both changes created a structure better suited to its ambitions.