📋 PLAYBOOK
Capability climbs one rung at a time. The handrail is yours.
📍 IN BRIEF
By the end of this you will be able to structure a mix of internal and partner support so that capability flows towards your team on a measured schedule. The test of a hybrid model is not whether the work gets done, it is which direction the work is travelling.
Most hybrid support models are designed as staffing arrangements. Someone counts the tickets, prices the partner's day rate against a permanent hire, and splits the queue between the two teams. Two years later the partner is as foundational as they were on day one, renewal is a formality because nobody internal can run what they run, and your own people have spent those two years watching somebody else get better at your platform. The work got done, and the capability never moved.
The better design borrows its logic from a teaching hospital. Consultants operate alongside trainees on live cases, and nobody doubts the consultant is the stronger surgeon today. But the institution is judged on something else entirely, whether the registrar can eventually run the ward without them. Every case gets treated, and every case also teaches. A hybrid support model built on that principle stops being a cost decision and becomes a capability programme with an external accelerator attached.
When to use this
This playbook is for platform owners who are running, or weighing up, a mix of internal staff and an external partner or managed service, and who intend to keep owning the platform strategy themselves. If the plan is to hand the whole estate to a supplier and step back, that is a legitimate choice, but it is a different model with different economics and this playbook is designed for someone else.
Stage 1, fix the internal spine before you shape the partner's scope
Name the roles that never cross the boundary, then design the partner's scope around them.
Every durable operating model rests on a small set of authorities, who owns the platform strategy, who holds design authority over solutions, who sets the technical standards development teams work within, and who answers for the health of the platform itself. Those authorities stay internal whatever the contract says, because they are the mechanism by which the platform serves your business rather than your supplier's delivery plan. The scale of that spine is easy to underestimate. Across the delivery method most large programmes draw on, the platform owner alone is accountable for almost a third of delivery tasks, and every one of those tasks carries exactly one accountable role. A partner can be responsible for and execute a large share of that work. But the accountability remains with the platform owner. If those authorities have never been written down, a team charter is where they stop being folklore, and a RACI that keeps the accountable column internal is where they become enforceable.
The gotcha is that teams sign the contract first and discover their operating model afterwards, assembled by accident from whatever the partner's standard service happened to include. Shape the spine before procurement starts, because no statement of work has ever volunteered to give authority back.
Stage 2, contract the steady state and the surge separately
Separate day-to-day support from hypercare, and keep the right to declare the surge over.
Platform support is two genuinely different services wearing one name. Day-to-day support runs indefinitely against broadly predictable volumes. Hypercare is the deliberately heightened support that follows a major release or go-live, with more people, tighter escalation, and its own communication rhythm, and it exists precisely because it ends. Contract them separately, price them separately, and write down what each one assumes. Above all, keep the closure decision internal. Hypercare ends when incident volumes return to normal and you say so, not when a calendar date arrives or a partner's resourcing plan needs it to.
The gotcha is that blending both into one service means paying surge rates for steady work, or starving a genuine surge because the contract never planned for one. The quieter failure is hypercare that never formally closes, so the elevated arrangement drifts into being the operating norm, at a premium, without anyone ever choosing it.
Stage 3, put every partner workstream on the autonomy ladder
Give each area of partner work a current level, a target level, and a date.
The ladder has three rungs, and each one names who leads rather than who attends.
Level | Name | What it looks like |
|---|---|---|
1 | Assisted execution | The partner leads the work, your team participates and absorbs the rationale |
2 | Guided autonomy | Your team leads the work, the partner reviews decisions and backstops mistakes |
3 | Independent operation | Your team owns the work end to end and can defend its decisions unaided |
Every workstream the partner touches gets a current level, a target level, and the date by which it should get there. Some areas will legitimately stay at level 1 forever, a rare specialism you have decided not to build is a defensible position. But it must be a decision on paper, made by you, not a residue of how the contract happened to be staffed.
The gotcha is that ladders without dates are decoration, and attendance is not progression. Your team having been in the room while the partner worked is still level 1. Level 2 begins the day your people lead with a safety net underneath them, and it is the rung most models silently skip.
Stage 4, make handover an acceptance test, not a document
Accept partner work only once your team has demonstrated it back.
The strongest transfer mechanism available is the reverse demo, in which your people walk the partner's build back to them, explaining not just what it does but why it was designed that way and what happens when it fails, before the work is accepted. Run these while the work is still warm, during testing rather than at contract exit, because that is when the reasoning behind every trade-off is still in somebody's head. Then contract the surrounding machinery, named transfer sessions, artefacts delivered with each release, and time in the partner's plan to run them properly, so that transfer happens on schedule rather than on goodwill.
The gotcha is that the handover pack written in the final month of an engagement, by people who are already rolling off, is an archaeology report. Documents describe what was built. Demonstrations prove somebody internal can run it, and only one of those survives contact with a live incident.
🎯 QUICK WIN
This week, list every workstream the partner touches and mark each one honestly as level 1, 2 or 3. No process required, one column on a page. The areas where nobody can name the level are your exposure map, and the exercise costs an hour.
Stage 5, measure the intersection quarterly and move the line
Track how much of the work your team leads, then move work in-house when the ladder says it is ready.
What gets measured in most hybrid models is the partner's side, response times, resolution rates, contract compliance. Measure the intersection instead, the share of incidents and triage your team leads, how long handoffs between the two organisations take, whether every escalation runs through one process rather than two, and where each workstream sits on the ladder against its target date. Bring the same discipline you apply to vendor performance to the boundary itself. Then, each quarter, open the review with one question, what is the partner still doing that we are now ready to take back. When the ladder says an area is ready, move it, and let the partner take on the next harder thing. That is what keeps the arrangement a partnership, the partner's work should be getting more advanced every year because the routine work keeps coming home.
The gotcha is that the boundary hardens. What began as a bridge over a temporary capability gap turns structural, because moving work is briefly inconvenient and leaving it is quietly easy. Without a named owner for the quarterly review, the line never moves, and a line that never moves is not a hybrid model, it’s an org chart with an invoice.
Common failure modes
The permanent hypercare. The surge arrangement never formally ends, and eighteen months later the premium staffing level is simply how support works. The fix is written closure criteria and an internal owner who declares the end, both agreed before the surge begins.
The rolled-off brain. The partner rotates their people, and everything the last team knew about your platform leaves in their notebooks. The fix is transfer as a per-release deliverable, reverse demos on acceptance, and contracted artefacts, so knowledge lands with your team continuously instead of evaporating at each rotation.
The comfortable dependency. Nobody is failing, the service is good, both sides like the arrangement, and precisely nothing has transferred in a year. The fix is making the renewal decision depend on the autonomy ladder report, so a contract that has moved no capability has to justify itself as a deliberate choice rather than gliding through on satisfaction scores.
📋 QUICK REFERENCE
The hybrid support model, in five moves.
Fix the internal spine. Name the authorities that never cross the boundary, in a charter and a RACI, before procurement shapes them for you.
Contract two services. Steady-state support and hypercare are priced, planned and closed separately, and you declare the surge over.
Ladder every workstream. Current level, target level, date. Level 2 means your team leads with a safety net, not that they attended.
Accept by reverse demo. Partner work is done when your team has demonstrated it back, failure modes included, while the reasoning is fresh.
Move the line quarterly. Measure the share of work your team leads, and when an area is ready, take it back and hand the partner something harder.
The bottom line
If you protect one thing, protect the direction of travel. Everything else in a hybrid model can be imperfect, the split can be wrong, the contract can be clumsy, and you will still end up stronger, provided routine work keeps flowing towards your team and the partner keeps graduating to harder problems. A model where the work stands still is not a partnership at any price.
A hybrid support model is healthy when the partner's work gets harder every year, because everything routine has already come home.
P.S. Run one drill before your next renewal conversation. Pick the partner-run workstream your platform depends on most, and ask which internal name could run it three months from now if the partner walked away. If the answer is a shrug, you have found your first ladder target, and you have found it before the renewal did.