10,000 m
The boardroom
Large enterprises rarely settle on a delivery model. They swing between delivery partners, independent contractors and building an internal team, and usually run some combination of all three. The swing is not random. Each model has a strength that solves the previous model’s weakness, and a weakness that eventually triggers the next swing.
This post takes one of the three, partner-first, and lays out both sides of the trade. It is not an argument for or against partners. It is a description of what the model does well, what it quietly costs, and the conditions that decide which side of the ledger wins. The other two models can have their own turn.
You are buying a bench, not a person
A partner engagement buys what is hard to get any other way. A team that can start next month. Capacity that scales with the roadmap. A contract with someone else’s name on the outcome. Add specialist depth in whichever product you have just licensed, which the partner has implemented several times and you have implemented never.
What it costs is a set of things that never appear on a purchase order. Knowledge of how the system actually works accrues inside the partner’s team and leaves with them. Internal staff shift from building to managing the build, and over time lose the ability to tell good work from confident work. Incentives point at delivery: fixed price rewards finishing, time and materials rewards continuing, and in both cases change requests are revenue.
The structural fact behind all of this is that you select the firm, and the firm selects the people. Presales is staffed by the partner’s strongest, because that is where the deal is won. Delivery is staffed to a blended rate card: one lead, a couple of seniors and a wide base of juniors, often offshore, because that is where the margin lives. Neither is dishonest, and the risk you carry is the variance in that pyramid, not its average.
The partner is usually also the platform vendor’s channel. That buys you an escalation path and early sight of the roadmap. It also means the partner earns tier status on the licences you buy, so the next module is never far from the recommendation. The table at the end lets you score your own situation.
3,000 m
The architecture
The design goes wherever the code is written
Design authority belongs to whoever makes the hundred small decisions a week that the design documents never covered. In a partner-first model, that is the partner, and if nobody internal is in those conversations, the architecture has moved without a handover ceremony.
The gains at this altitude are real. A partner has seen the same problem across a dozen clients and knows which of the vendor’s recommended patterns survive contact with production. They arrive with accelerators, frameworks and a house style that has been tested somewhere else first. On a platform your organisation has never run, that pattern library is worth more than the developers who carry it.
The costs are subtler than “the code is bad”. Each partner’s house style is layered over the last one’s. After three partners across eight years, the org reads like geological strata, and you can date a component by which trigger framework it uses. No single layer was wrong. The sediment is the problem, and it was in nobody’s scope.
The second cost is that the partner’s patterns were tuned for the partner’s typical client, and your organisation is not typical. Accelerators built for a 20-user rollout behave differently in an org with a hundred developers and a decade of history. The partner is not going to redesign their toolkit for one engagement, so the adaptation falls to you, usually after the fact.
The sharper question sits underneath the sediment: who holds the accelerators when the partner leaves. Ask whether you own the source and the licence to their framework, or whether you are entitled to run it and not to modify it. The second case is how the next partner ends up building on top of the last partner’s layer rather than replacing it, and it is checkable before you sign.
Some things therefore have to stay internal regardless of who writes the code. The design authority, meaning the person who says yes or no to structural decisions, and a decision record the partner cannot merge without. The glossary and the data model, because those outlive every engagement. The standards, the review process and the pipeline, because they are the only lever you still hold once the code is being written elsewhere.
If none of those are internal today, the partner owns your architecture, whatever the org chart says. That is a workable arrangement for a two-year rollout. It is a fragile one for a platform you plan to keep.
300 m
The delivery team
The team that inherits the work sets the terms
The team that will support the system after the partner leaves should set the terms of the engagement. They pay for whatever the terms leave out. That sounds obvious and almost never happens, since the contract is signed before that team is in the room.
A partner-led team onboards fast, because they have done it before. They bring the delivery discipline an internal team usually improvises: ceremonies, tracking, a status report someone actually reads. Liability for the outcome sits with the partner, which is more than you can say of a contractor who is simply not very good. And a partner can be replaced as a unit, with an obligation to backfill, where contractor churn is one resignation at a time.
Where it hurts is in what arrives at the end. The handover document is written in the final sprint by someone already booked on the next client. Review standards are met in letter and missed in intent, because the partner optimised for the checklist rather than the reason behind it. The baton is handed to people who did not build the thing, and every incident becomes archaeology.
The bench variance from 10,000 m lands here as the gap between the pitch deck and sprint one, and nobody internal sees it until the first pull request. Caught in sprint two, it is a conversation. Caught in sprint ten, it is tech debt and a knowledge gap arriving together, on an invoice that looks the same either way.
None of this is fixed by hoping. The practices that tilt the balance are mundane and mostly contractual:
- Name the delivery people in the contract, not just the roles. Interview the tech lead and senior developers before signing, keep a swap-out clause you are prepared to use, and add a notice period for rolling people off, because the partner’s next client will want your best one. This is not always practical or possible, and the partner will say so, but how hard they push back tells you a lot about the bench.
- Review the first two sprints properly. The same standard you would apply to a new internal hire, applied before trust has built.
- Keep an internal developer on every stream. They pair. They do not sit in the ceremonies and nod. This needs overlapping working hours, so with an offshore squad it becomes review by chat thread unless you plan around it.
- Make handover a definition-of-done item from sprint one. Runbooks and decision records ship with the feature, and the exit is written in from the start: a paid transition window, with knowledge transfer as an acceptance criterion.
- Own the review pipeline and the environments. Linting, the review checklist, the merge gate, the sandboxes and the release calendar are yours. A partner that owns the environments owns the schedule.
Every one of these costs internal time, which is exactly what hiring the partner was meant to free up. That is the trade. The partner takes the building off your hands, but the oversight stays with you, and engagements go badly when that oversight is budgeted at zero.
Something to do
Score your situation against the table. Each row is a condition where the model tends to fit or strain. Every tick in the right-hand column makes one of the mitigations above compulsory.
| Condition | Partner-first fits | Partner-first strains |
|---|---|---|
| Platform maturity | New to the organisation, nobody internal has run it | Established, with a decade of history and conventions |
| Demand shape | A burst: a rollout, a migration, a deadline | A baseline: continuous product development |
| Skill needed | Specialist, used once | Core to the business, used daily |
| Expected life of the work | Two to three years, then replaced | A decade or more |
| Internal capability | Enough to review and direct the work | Too thin to judge what comes back |
| Design authority | Held internally and staffed | Vacant, or held by whoever is writing code |
| Exit plan | Written into the contract from day one | “We’ll sort that out later” |
| Accelerator IP | Source and licence held by you | Partner-licensed, run but not modify |
| Team location | Working hours overlap with your reviewers | Offshore squad, onshore lead only |
Then run one quick test: pick the last three partner-built features and ask whether anyone internal can explain how they work without opening the partner’s documentation. If the answer is yes, the model is working for you. If the answer is no, you have already paid the price on the second side of the contract, and the question is only whether you keep paying it.
