Senior service-operations expertise, without the permanent hire.

Standard changes shouldn't be in the room. If a change is low-risk, well-understood and repeatable, the value of a board reviewing it live is close to zero — and the cost, in delay and attention, is real. Pre-authorise them against clear criteria and keep the board's time for changes that genuinely need judgement.

Normal changes need assessment, not theatre. A board works when it's reviewing risk, dependencies and readiness — not re-reading a form everyone could have read beforehand. Tighten the peer review upstream and the meeting gets shorter and sharper.

Emergency changes need a route that doesn't depend on a meeting at all. The test of change governance isn't how it handles the easy ones; it's whether the right people can authorise the right change at 2am without breaking the process.

Declare early, and make declaring cheap. The most common failure isn't mishandling a major incident — it's not calling one soon enough. People hesitate because the criteria are fuzzy or because raising the alarm feels like an overreaction. Define clear, objective triggers and give your team explicit permission to pull the cord: a false alarm costs minutes, a late declaration costs hours.

Separate the people fixing from the people communicating. The instinct is for everyone to pile onto the technical problem, but leadership, customers and the wider business need a steady stream of honest updates — and your engineers can't do both well at once. A named incident lead and a named communications lead, agreed in advance, is the single biggest predictor of a response that stays calm under pressure.

Close the loop, every time. The review after a major incident isn't paperwork; it's where the next one gets prevented. Keep it blameless, fix the system rather than the person, and track every action through to completion. An incident you learn nothing from is one you've quietly agreed to have again — which is exactly where good problem management begins.

Platform consultants know what the tool can do. They know how to build workflows, configure approval logic, wire up notifications and produce dashboards that look exactly like the ones in the sales deck. What they often don't know — and have no reason to — is how your organisation actually operates. They don't know that your change approver is also the only person who handles emergency deployments. They don't know that your service desk inherited three different priority definitions from three different teams, none of which anyone has reconciled. They build what they're asked to build, and they build it well. But they're building against a brief that was written without that context.

Operational practitioners know how the work actually flows. They know where the handoffs break down, which steps get skipped under pressure, and which processes exist on paper but haven't been followed since the last audit. They know the informal workarounds that hold things together — and they know, even if they wouldn't put it this way, that a lot of what gets configured into tooling is an optimistic version of reality rather than a reflection of it. The problem is that practitioners are rarely given the space to shape the implementation. They're consulted at the edges, asked to validate something that's already been built, and then handed a system that doesn't quite fit how they work.

The gap between these two groups is where implementations go wrong. A workflow that looks correct in a configuration screen can be completely unusable in practice if it doesn't account for how decisions actually get made or how information actually moves. A dashboard that gives leadership the visibility they asked for is worthless if the data feeding it is inconsistent because the intake process wasn't designed with the people doing intake in mind. You can't fix these things after go-live without rebuilding trust you've already spent.

The answer isn't to replace one group with the other — it's to run them in parallel from the start. The operational practitioner maps the real current state before a single workflow is configured: how requests actually arrive, where changes actually stall, what information actually changes hands at each step. That map becomes the brief the platform consultant works from. The consultant builds against reality, not against an idealised process. And when decisions have to be made — about what to automate, what to keep manual, what to simplify — both perspectives are present. The practitioner challenges what's operationally unworkable. The consultant challenges what's technically unnecessary. The result is a system that people actually use.

If your implementation is already under way and you're not sure who is playing which role, ask yourself one question: does the person configuring your toolset know what happens when an approver is unavailable? If the answer is "I'm not sure", that's the gap. It's worth closing before you go live rather than after.