Skip publishing timeline

Timeline of posts

Woodcut-style print of a flock of birds lifting off together from a gnarled tree and flying away in a long diagonal line, the tree left behind heavy with orange fruit, dark ink on cream paper Image made with Qwen-Image.
The flock leaves together; the fruit stays on the tree.

When a colleague who has cracked AI leaves, their virtual team goes with them, but the work and the expectations stay.

Many of the most impactful colleagues I work with now lean on AI heavily. Where others use it as a better search box, they have it so woven into how they work that their output compares to a small team's. At the far end, one person is sometimes doing what five or more people used to.

So when one of them leaves, you're not down one person. You're down that person and the impact of five colleagues, or six, or however many their way of working was standing in for. The whole team walks out with them, the way a principal investigator's lab tends to follow them to a new university.

Then you hire back, and it's hard to know what you'll get. The replacement might work at 1x, or 2x, or 5x. Even a good match will work differently, and arrives with an empty lab to fill. None of this is made simpler by how fast the tools have changed over recent years, and even months.

And the work stays behind. That's the part I think we're underestimating. Everything that was built still needs supporting, the bar for quality has gone up, and stakeholders have got used to the pace.

tl;dr

  • Colleagues who have cracked working with AI can carry the output of five or more people.
  • When one leaves, you lose their whole virtual team, much as a university loses a lab when its principal investigator moves on. Research on star performers shows how much of their output travels with their team.
  • The successor might work at 1x or 5x, and even at the same maturity they'll work differently. They arrive with an empty lab to build and orient.
  • What stays behind is the work: things to maintain, a higher quality bar, and stakeholder expectations. Documentation helps, but it doesn't staff any of it.

Where the extra capacity goes#

This increased leverage mostly hasn't made organisational headcount smaller. Instead the team does work that wouldn't have happened at all, much as people now wash their clothes far more often than before the washing machine.

That comparison is historian Ruth Schwartz Cowan's. The washing machine took the drudgery out of laundry but not the time, because standards rose to fill the gap: both sheets were changed every week instead of one, and underwear daily instead of weekly. As she put it, "Drudgery had disappeared, but the laundry hadn't."

I see the same at work, in two forms. Some of it is paying down technical debt: refactoring, consolidating, documenting. That work makes things more sustainable, and it's some of the best use of the extra capacity.

But much of it is new: new dashboards, new projects and products, new editing suites, new engagements with new stakeholders. All of it would otherwise have needed dedicated staff, and all of it needs looking after once it exists. These are the clean sheets every week, and they depend on one person and how they run their tools.

What a university loses when a lab leaves#

When a principal investigator moves on, the department can hire another one. But a researcher doesn't just work in an area; they work in a particular way, and they usually take their lab with them: the students, the postdocs, the methods. A replacement recruited from elsewhere usually brings a lab of their own. The field carries on, but the flavour of the research changes.

The pattern isn't unique to academia, and it holds lessons for an era of AI agents.

Boris Groysberg spent years following star Wall Street analysts who changed firms. On average, their performance fell immediately after the move and stayed down for at least five years. The exception was stars who moved with their team: they showed no significant decline. Much of what looked like individual talent depended on the firm and the people around them.

Firms have noticed. Groysberg and Robin Abrahams describe the lift-out: hiring a whole group that already works well together, rather than one star at a time. From the losing side, a lift-out is exactly what I'm describing. One resignation, and a working team goes out the door.

Two more findings show what's lost, and what replaces it:

  • The value is built up together. Xavier Jaravel, Neviana Petkova and Alex Bell studied US inventors who lost a close co-inventor. Eight years on, their citation-weighted patent output was still about 15% lower. The authors call what was lost team-specific capital: value that accumulates through working together, and that neither person carries alone.
  • The replacement takes the field somewhere new. When a star scientist dies, outsiders move into the field, drawing on different ideas, and their work is disproportionately likely to be highly cited.

None of these studies is about AI, and a resignation is obviously not a death. But the pattern maps closely. A colleague who has cracked AI is a star who always moves with their team, because the team is their setup. When they go, the lab goes with them. What comes next will be a different lab. It may be better, but it won't be a like-for-like swap, so plan for the change.

Hiring back: 1x, 5x, and an empty lab#

Maturity you can hire for, up to a point: you can look for someone who uses AI as seriously as the person who left, but it's hard to tell from an interview whether they'll work at 1x or 5x. Software has argued about the "10x developer" for decades; in my experience, AI widens that spread rather than closing it.

What you can't hire for at all is the same approach. Some colleagues run several agents in parallel; others keep one long conversation going all day. Some plan heavily before prompting; others iterate their way to an answer. Any of these can work very well, but two people at the same level will build different setups and get different things out of them.

So the successor has two jobs. Onboarding themselves is familiar, and organisations know how to plan for it. The new part is that, unlike a professor hired from another university, they arrive with an empty lab. They have to assemble a team (choose the tools, write their own agents and workflows) and then orient it to the work: what good looks like here, which sources to trust, where the edge cases hide. Only then are they back to a team's worth of output.

You hired one person. In practice, you're onboarding a team.

What stays behind#

The old team leaves, but its work doesn't. The dashboards still need their data feeds, the editing suite still needs fixes and features, and the projects still have stakeholders. All of it was built at the pace of a person-plus-team, and now it needs looking after by whoever is left.

The expectations stay too, and they're arguably the bigger part. The quality bar went up while that colleague was here. Stakeholders got used to faster delivery, quicker responses and better support, at a pace that only made sense with a team behind it. Cowan's households didn't go back to one fresh sheet a week just because the laundry got harder.

Documentation helps, and it goes a long way. Agents, prompts, skills and workflows can all be written down, which is one more reason documentation is quietly becoming the real work. But a documented setup is still someone else's setup, shaped by which tasks one person handed off, which they checked by hand and where they trusted the output.

It tells the successor what exists. It doesn't give them the capacity to keep it all running, on top of building their own lab.

Questions I keep coming back to#

  • How much of a colleague's setup can be handed over, and how much is really just how they think?
  • Should a handover include time for the successor to build their own lab, not just learn the old one?
  • Which roles in your team already work this way, and who would maintain what they've built if they left tomorrow?

I don't have tidy answers. I suspect the people doing this work are best placed to say what a good handover looks like, and that it's worth asking them before they leave rather than after.

If you've seen a team handle this well, or badly, I'd like to hear about it.

Was this useful?

👍 This was useful Found usefulFeedback count Thanks for the feedback! Curious how this was built?

Read next in sequence