Leading a Team That's Half on Contract

Half my delivery team will be gone by next year. Not because anything went wrong. Because that’s the deal. A big chunk of the people building our platform are consultants on fixed contracts, and the day a contract ends, the person walks out with everything they never wrote down. So I’ll say it plainly: when most of your team is passing through, you’re not leading a team. You’re leading a flow of people.

And the thing everyone obsesses over, velocity, is not the real problem. The real problem is memory and accountability. When the one person who knew a module is gone, who answers for what’s left behind? That’s the job. The leader’s job in a blended team is to manufacture continuity inside a structure that was designed to be temporary. Good intentions don’t get you there. Mechanisms do.

Roles aren’t an accident, they’re a design choice

The first mistake I see is treating employees and contractors as interchangeable bodies on a burndown chart. They’re not, and pretending they are is how knowledge walks out the door.

Here’s how I split it:

1. Employees get the strategic, cross-cutting roles. The ones that hold the big picture, the architecture decisions, the run. They stay. So they carry the parts of the system that can’t afford to forget.
2. Consultants get precise missions. A clear scope, a start date, an end date. They come in to build a thing, build it well, and hand it off.

This isn’t about trust or about who’s better. It’s about where the gravity of continuity has to sit. If you hand the cross-cutting brain of your platform to someone whose contract ends in eight months, you’ve signed up to relearn it from scratch in nine. That’s not a risk, that’s a guarantee.

Documentation only counts if a stranger can read it

Everybody says document everything. Most teams produce documentation that’s worthless, and they don’t even know it, because the author is the one grading the homework. Of course it makes sense to the person who wrote it. They lived it.

My rule is simple and a little annoying on purpose: a doc gets approved by a peer who doesn’t know the subject. If they read it and understand, it holds. If they stumble, congratulations, you just found the blind spot, and you fix it right there through feedback. The stumble is the value. It’s the only honest signal you’ll get.

Do this and documentation stops being a graveyard nobody visits. It becomes a test of transmissibility. You’re not storing knowledge, you’re proving it can move from one head to another. That’s the whole point in a team where heads keep changing.

You can’t vouch for a ghost from memory

Here’s the uncomfortable scenario. A deliverable was built by someone who left four months ago. Production has a problem in their code. Who’s accountable?

If the answer depends on what’s in your head, you’ve already lost. Nobody remembers the edge cases of a module they never wrote. You’re not going to answer for a ghost’s code by straining your memory.

You answer for it because the system verifies itself. Test cases. Unit tests. Automated tests. Observability that tells you what the thing is actually doing right now, not what the author swore it would do. The behavior stays verifiable long after the person is gone. That’s the difference between a system you own and a system you’re just renting until the next incident.

This is the part people skip because it feels like overhead during the build. It isn’t overhead. It’s the only form of accountability that survives a contract ending. In a stable team you can sometimes get away with tribal knowledge. In a blended team, tribal knowledge is a countdown timer.

Onboarding is where the money leaks

The real trap of mixed teams isn’t the leaving. It’s the arriving.

A consultant who shows up with no integration framework burns weeks figuring out how to even commit code, who to ask, where things live. By the time they’re productive, a third of the contract is gone. You paid senior rates for someone to read the wiki and guess. Then they leave right around the moment they finally became useful.

So I treat onboarding as a hard deliverable, not an HR nicety. How fast can a new person make their first meaningful, reviewed contribution? That number tells me whether the temporary part of my team is going to produce value or chaos. Cut the time-to-first-commit and you’ve changed the economics of every contractor you’ll ever bring in. Ignore it and you’re funding ramp-up over and over with nothing to show.

The hardest tension: a narrow mission, a system-wide responsibility

Here’s the knot I haven’t found a clean way around. A consultant is assigned to one slice of the system. Tight scope, clear mission, good for velocity. But the run, the on-call, the incidents, none of that respects your scope. An incident at 2 a.m. doesn’t care that your mandate was just the payment module. It demands a view of the whole.

So how do you give someone knowledge of the entire system without dragging them off the precise mission you hired them for and killing their velocity?

My answer is on-call rotation. Put everyone, staff and consultants, into the rotation. A few shifts on call and someone learns more about how the whole platform actually behaves than any architecture diagram could teach them. They see the seams, the failure modes, the dependencies nobody documented. It exposes each person to the full system without pulling them permanently out of their mandate. It costs a little focus. It buys a lot of resilience.

The discomfort is the feature

A half-temporary team forces you to make explicit everything a stable team gets to keep implicit. The knowledge. The decisions and why you made them. Who owns the run. None of it can live in the hallway anymore, because the hallway empties out every few months.

That’s uncomfortable. It’s more work upfront, and it feels like you’re building scaffolding for people who aren’t even here yet. But I’ll tell you what I’ve seen: a team that’s forced to transmit ends up with a more robust system than a stable team that never had to hand anything to anyone. Stable teams accumulate debt they can’t see, because the people who’d notice never leave. They just get better at routing around the rot.

So if you’re running a blended team and it feels like you’re fighting the structure, you’re reading it wrong. The structure is doing you a favor. It’s making you build the mechanisms that stable teams skip and pay for later.

Manufacture continuity on purpose, or watch it walk out with the last contract.