The vendor is not your team, and pretending otherwise costs you the release

Mixed internal and vendor teams don't fail because of bad people. They fail at the seam nobody manages. Here's how to run it on purpose.

Three weeks before the release, in the standup you've run for six months, one of the vendor developers says the sentence that ends the pretense.

"We'd need a change request for that."

The "that" is small. A validation rule moving from one service to another. Your internal developers would have picked it up before lunch. But the two developers from the vendor squad, people who joke in your retros and stay late when the build breaks, suddenly sound like a legal department.

Here's the part worth studying: they're not being difficult. They're being accurate. The work isn't in the statement of work. Your sprint board and their contract were never the same document. You've just spent six months acting like they were.

If you lead a mixed internal and vendor team, this moment is coming for you. The only question is whether it finds you three weeks before a release, or whether you handle it months earlier, on purpose, while it's cheap.

The org chart shows one team. The commercials show two companies.

Everything about the setup tells you it's one team. One board, one standup, one Slack channel, one retro where everyone laughs at the same flaky test environment. Good vendors are excellent at this. Embedded squads, engineers in your ceremonies from day one, a kickoff deck that says partnership on every second slide. It looks like a team because everyone in the room wants it to look like a team.

Now read the paperwork instead of the board.

Your internal developers answer to your roadmap. The vendor developers answer to a statement of work, the SOW, negotiated before the first sprint and priced on assumptions that are now months old. Your board changes every planning session. Their scope doesn't, not without a signature.

You prioritize by product value. Their company prioritizes by margin and utilization. An idle vendor developer is a problem for their resourcing manager, not your product owner. Scope that grows quietly is a bargain on your side and leakage on theirs, and both companies employ people whose whole job is to notice.

You learn things in standups. Their company learns things through an account layer. What their developer hears in your retro travels up through a delivery manager and an account manager, and what comes back down has been through at least one meeting you weren't invited to.

There's a cheap way to see the structure under the theater. Ask for something small that's clearly outside the SOW and watch what happens to the pace. Inside scope, answers come back in hours. Outside scope, the same friendly people need a few days and a call they can't quite describe. The delay isn't rudeness. It's the org chart telling you the truth.

None of this makes them bad people. Most vendor engineers I've worked with were skilled, generous with their time, and genuinely wanted the release to ship. Here's the hard truth anyway: a vendor can love your project and still bill by the change request. Affection is personal. Invoicing is structural. When the two collide, structure wins, because a vendor developer who ignores their own SOW to help you out is creating a problem with their own employer.

The one-team act is deferred conflict, with interest

The pretense doesn't come from stupidity. It comes from a good instinct: treat people well, don't wave the contract around, build trust. So leads sand off every visible edge of the boundary. They skip formal acceptance because it feels bureaucratic. They stop asking whether something is in scope because it kills the vibe. They let handoffs blur, because deciding who owns a bug means pointing at the seam between companies, and pointing at the seam feels like an accusation.

Then the release gets close, because pressure always shows up at the end. Every question you politely didn't ask for six months comes due in the same three weeks. What exactly is in scope. Who accepts the integration work, and in which environment. Why a two-day fix needs eleven days of authorization. The boundary didn't appear late. It was there the whole time. You just chose to discover it during the release instead of before it.

That's the real cost of playing one team. Not the change request itself. Discovering the change request process at the worst possible moment, at the maximum possible price.

Manage the seam, not the vibe

You don't fix this by getting colder. You fix it by getting explicit. Five moves, all of them cheap early and expensive late.

1. Write the interface contract

Not the legal contract. The working one. One page that says, for every handoff between your side and theirs: what done means at the point of transfer, who accepts the work, in which environment, and within how many days. Something like: "Vendor delivers the API endpoints, internal QA accepts against the agreed test suite in staging, within three business days." Boring sentences. Boring is the point. When acceptance is defined up front, nobody has to negotiate it during a crunch, and the sprint board and the SOW finally describe the same reality.

2. Demo and accept on a cadence

Every sprint, the vendor demos what crossed the line and you accept or reject it, in writing, while it's fresh. Small ceremony, big effect. What kills mixed teams is acceptance drift: "looks good, we'll log it later." Later never has time. Three months of unaccepted work quietly becomes a dispute in week eleven, when nobody can prove what was agreed. Keep the log lightweight, a shared page with the date, the item, and who accepted it. If it takes more than five minutes a sprint, you've overbuilt it. Acceptance isn't distrust. It's hygiene.

3. Build a line to their delivery lead, not just the account manager

The account manager owns the relationship and the revenue. The delivery lead owns the work. If every technical question routes through the account layer, you're playing telephone with your release. So run two lines and know what belongs on each. Sequencing, dependencies, and risk go to the delivery lead. Scope, rates, and contract changes go to the account manager. Mix the channels and you'll watch a simple technical question turn into a commercial event, with a price tag to match.

4. Name the escalation path before you need it

Ask in week two, while nothing is on fire: if we hit a blocker on your side, who do I call, and what's the response window? Get names and hours, not a reassuring slide about partnership. An escalation path negotiated mid-crisis is the most expensive version of it, in goodwill and sometimes in actual penalty clauses. The same path, named early, costs one slightly awkward question.

5. Keep the warmth. Move the boundary.

None of this requires going cold. Keep the retro jokes, the shared channel, the coffee when their team is on site. The boundary isn't between people. It's between companies. The best vendor relationships I've seen were the most explicit ones, because nobody had to pretend, so nobody got burned, and the people could genuinely like each other since the companies had a working interface. Clarity is what makes the warmth safe.

"Tell me about managing a third party"

At some point in every senior interview, for delivery managers, program roles, senior Scrum Masters, some version of this question shows up. It sorts candidates fast, because you can't theorize your way through it.

The weak answer sounds collaborative: "We had a vendor on the project, so I focused on communication and made sure we treated them like part of the team." The interviewer hears something specific in that sentence: this person has never been burned.

The strong answer sounds like the seam: "I ran a mixed internal and vendor team. I set the interface early: definitions of done at each handoff, a demo-and-accept cadence every sprint, separate channels for delivery and commercial questions, and an escalation path with named response windows. When scope moved late, the change request took four days instead of derailing the release, because the boundary was already explicit."

That second answer signals something no certification can: you've delivered through a commercial boundary and kept both the release and the relationship. Vendor management in project management usually gets taught as procurement. Selection, contracts, SLAs. The version that gets people promoted is this one: running the seam between two companies while the work keeps shipping.

And if you've never run one, you don't need a title change to start. Volunteer for the next piece of work that touches a third party: an integration, a data migration, a security review. One release of managing that seam honestly gives you more interview material than a year of clean internal sprints.

Do it while everything is still friendly

Look at your board this week. If some of those avatars answer to a different company, stop letting the column layout convince you it's one team. Write the one-page interface: what crosses the seam, who accepts it, where, and how fast. Ask for the escalation path while asking costs nothing. Keep every joke and every ounce of goodwill.

The pretense feels like trust, but it's closer to the opposite. Trust is when both sides can see the boundary and shake hands across it anyway. Build that, and the vendor doesn't have to be your team. They just have to be a team you can ship with.