The “empty chair” in your boardroom isn’t just a governance issue—it is the primary risk to your platform’s ROI. If your transformation feels like it is drifting, you do not need more features or a new implementation partner; you need a single, accountable owner.

In my last piece, I wrote about the lift-and-shift trap, the tendency to chase a prettier version of a broken legacy system instead of fixing the workflow underneath it. Since then, I’ve spent more time pulling on a thread that runs through nearly every one of these engagements, prettier UI or not: who, on the customer side, actually owns the platform?

Not “who sponsors the budget.” Not “who chairs the steering committee once a month.” I mean who wakes up every day accountable for whether ServiceNow is getting healthier or getting worse. In engagement after engagement, the honest answer is: no one, officially. And that single gap is usually the root cause underneath all of it. Not the UI, not the workflows, not even the customisation appetite. 

What Happens When the Chair Stays Empty

The pattern is remarkably consistent, and it doesn’t take long to show up. Without a mandated owner on the customer side, engagements tend to develop the same three symptoms: departments start optimising locally instead of converging on shared standards, decisions stall because no single voice is accountable for making them, and scope drifts toward whoever argues loudest in the room rather than what actually serves the platform. None of this is a technology problem. It appears specifically when no one is mandated to decide, prioritise, and align change with strategy.

What struck me most, going through the research, is how timed this decay actually is. Left unfilled, the role doesn’t fail loudly, it fails on a clock. In the first few months, nothing looks wrong; the platform runs on inherited momentum. By around month three, the roadmap starts drifting because priorities are set by whoever’s voice is loudest, and costs quietly start to slip. By month eight, technical debt has compounded far enough that upgrades turn into mini-crises and the data model starts diverging from its own standards. By month twelve, stakeholders lose enough trust that shadow solutions appear. Departments quietly building their own workarounds outside the platform. Somewhere between eighteen and twenty-four months, a senior leader finally asks the question that’s been sitting in the room the whole time: why isn’t this platform delivering what we hoped? By then, the cost is no longer theoretical. It’s stalled transformation, renewed licences nobody uses, and a platform team that’s lost the trust of the business it serves.

I’ve watched community discussions among practicing platform owners describe this exact drift in their own words: instances that slowly fragment into duplicate tables, brittle business rules, and increasingly painful upgrades; because no one held the line on data model discipline or uncontrolled customisation.

It’s worth being precise about what this isn’t. It isn’t a failure of the technology, the implementation partner, or even the people involved. It’s a structural gap, a chair that was never formally filled, in a system that was always going to need someone sitting in it.

How a Platform Owner Actually Closes the Gap

Once you name the gap, the fix sounds almost too simple: appoint one accountable person. But what that person actually does is worth spelling out, because “Platform Owner” gets used loosely and sometimes as an admin with a longer job title, sometimes as a product owner for a single use case. Neither is what the role, done properly, requires.

Practitioners I’ve read describe the mandate in fairly consistent terms: 

1. owning the platform vision and multi-year roadmap,
2. translating business strategy into what the platform should actually do,
3. setting functional direction when teams compete for priority,
4. establishing guardrails that let delivery move fast without fragmenting,
5. owning governance and decision rights, and
6. driving adoption and value realisation rather than just delivery. 

Most importantly, the Platform Owner must have the power to say “no,” even when there is pressure to rush. Their job is to prioritize the system’s long-term health rather than just meeting short-term goals.

The power of this role needs to be officially built into the organization, not just rely on the person’s personality. Without the genuine authority to set priorities, control the budget, and be part of major decision-making meetings, a Platform Owner is just an administrator with a fancy job title, and the platform will still go off track. This official mandate is what turns a job description into the ability to actually get things done.

The Bridge Between Business Vision and Operational Reality

The part of the role I find most underrated is the translation function. A Platform Owner sits precisely at the point where strategic intent has to become platform reality. Where “we want employees to have a better experience” becomes a specific workflow, a specific data model decision, a specific choice between adopting OOB, configuring, or building new.

This role requires a different set of skills than standard technical work. The Platform Owner must partner with various departments like IT, HR, and Legal to decide which processes to keep, standardize, or remove. The goal is to ensure the software reflects how the business actually works, rather than how leadership wishes it worked.

The owner also acts as a mediator in common conflicts, such as choosing between custom features versus standard ones, or speed versus following rules. Someone must balance these competing pressures; otherwise, decisions are made poorly by default, usually just favoring whoever is the loudest at the time.

Without this bridge, business leaders describe a vision, and it either gets translated by committee (which produces the silo behaviour from section one) or gets translated by whoever happens to be in the room for that particular sprint (which produces the scope drift). Neither is really translation. It’s improvisation dressed up as delivery.

The Governance Layer a Platform Owner Builds

Governance is the part clients are usually most nervous about, because it sounds like bureaucracy. Done well, it’s the opposite. It’s what makes decisions fast rather than slow, because everyone already knows who decides what, and by when.

In practice, this tends to take the shape of a small number of lean forums rather than a sprawling committee structure:

1. a strategic board that meets monthly to handle value realisation, roadmap, and cross-departmental priorities;
2. a design or technical governance layer that meets more frequently to handle architecture decisions and deviations from standard;
3. and a delivery governance cadence that runs weekly to keep progress, risk, and dependencies visible.

The Platform Owner is the one constant presence across all of them. The hub that connects strategy to architecture to delivery, because removing that hub doesn’t stop the parts from spinning, it just stops them from producing value together.

Underneath the forums sits a decision-rights model that’s worth being explicit about, because ambiguity about who decides is exactly how platforms drift. 

1. Funding decisions sit with the sponsor. 
2. Roadmap and priority decisions, scope changes, deviations from standard, and release timing sit with the Platform Owner; consulted by architecture and product, informed to the sponsor. 
3. Operational day-to-day priorities sit with product owners. 

The Metrics a Platform Owner Actually Reports On

This is where most platform reporting quietly fails, and it’s worth naming why. The metrics that make sense to a platform team: ticket volumes, SLA compliance, uptime, MTTR are real and useful operationally, but they answer the wrong question for the audience that ultimately decides whether the platform keeps getting funded. A CFO looking at a renewal doesn’t want to know that 94% of tickets hit SLA. They want to know what the investment is actually worth.

The more useful frame splits metrics into two layers. 

1. The first is the platform detail layer. the operational numbers a platform team needs day to day: ticket volumes, release quality, adoption rates, technical debt index, architecture compliance.
2. The second is the business summary layer, and this is where a Platform Owner earns their seat in the room, because it reframes the same underlying data into terms finance actually works in:
   1. cost avoided – what would this have cost without the automation, measured against a baseline captured before go-live
   2. hours reclaimed – manual effort absorbed by the platform, expressed as team capacity rather than headcount reduction
   3. risk reduced – change failure rate, audit preparation time, vulnerability aging
   4. business outcome versus target – performance against the specific, numerical commitment made at programme initiation, not invented after the fact to fit whatever got delivered.

That last category is the one that separates a Platform Owner defending a number from a Platform Owner having a strategy conversation. Reporting “SLA compliance improved 8%” gets a polite nod. Reporting “we committed to reducing service delivery cost per employee by 15%, and we’re at 11% after eighteen months, on track” gets trust because it shows someone owned the outcome from day one, not just the delivery.

The evidence for why this ownership matters at all isn’t just anecdotal, either. There is strong evidence that having a platform owner makes a real difference. Research consistently shows:

• An actively engaged sponsor and owner is the most important factor in a project’s success.
• Projects are far more likely to succeed when roles are clearly defined and there is a clear decision-making structure.
• When owners are held personally responsible for results, they succeed at much higher rates.

Conversely, many digital projects fail to meet their goals. Large organizations often waste a significant portion of their budget just fixing old, outdated technology instead of using that money to create new value. This failure is not inevitable; it is simply what tends to happen when there is no one officially in charge.

Where This Leaves Me

I keep coming back to the same conclusion from a different angle each time: the technology is never really the constraint. ServiceNow, used as intended, is more than capable of delivering what most organisations ask of it. What’s usually missing is one person, properly mandated, sitting at the intersection of business vision and platform reality, with the authority to say no, the governance to make decisions stick, and the metrics to prove the investment is working.

This is still an evolving picture for me here in the region. Every engagement adds a new wrinkle to how this role gets resisted, half-filled, or quietly absorbed into someone’s already-full job description. I’ll keep sharing what I’m learning as it develops.

—

*Sources referenced: ServiceNow Community discussions on Platform Owner responsibilities and KPIs; Aloha Clouds on the cost of an unfilled Platform Owner role; The Cloud People on the bridging function between business and IT; Iconica on outcome-based ServiceNow reporting for finance audiences; and PMI, McKinsey, and BCG research on governance and executive ownership as drivers of programme success.*