The hidden cost of moving your best engineers

Engineering teams lose years of accumulated context when they move their strongest people to the next big project.

Sep 03, 2026

An engineer joins a difficult project and spends the first few months figuring out where everything is. Gradually the questions change. They stop asking where things are and start understanding why they are that way.

They learn that one ugly piece of code can't be cleaned up because three old customers depend on its behavior. They know which service looks stateless but isn't. They remember the migration that failed two years ago, the workaround nobody wrote down, the dashboard that lies during incidents, and the team you have to talk to before touching an apparently harmless API. Eventually they understand the product almost as well as the software.

By then they are one of the company's best engineers, and the company moves them.

A new initiative has come up. It's strategic, it needs to ship fast, and leadership wants experienced people on it. So the engineer who spent years building up knowledge of one system is sent to a greenfield project to start again. On paper that's sensible resource allocation. In practice the company may have just written off a real amount of capital.

My argument is that software expertise compounds with context, and many engineering organizations interrupt the compounding right when it starts to pay off.

Rotation has real benefits, and I'll come back to them. The narrower problem is that we treat senior engineers as portable units of capacity and ignore how much of their value is tied to what they've learned in one place. The research on software teams suggests that matters more than most staffing models allow for.

The engineer doesn't just know the code

It's easy to think of software knowledge as something that lives in the repository. If the code is documented, the diagrams are current, and the runbooks are good, handing over ownership should mostly be a matter of giving another capable engineer time to read.

Anyone who has worked on a mature system knows it doesn't work that way. The knowledge that matters most sounds like this:

We tried splitting this service before. Here's why we put it back together.

That customer technically shouldn't be doing this, but 18% of revenue goes through this path, so don't touch it casually.

This component isn't the bottleneck. It only looks like one when that other subsystem backs up.

Talk to the platform team before you change that.

That's historical, operational, organizational, and product knowledge mixed together, and very little of it is written down.

Research on software teams keeps finding that important expertise is tacit and social rather than codified, and that having expertise isn't enough. Teams perform better when they can coordinate it: when people know where the knowledge is, when it's needed, and how to bring it into the work.

So a company with 50 engineers really has a network of knowledge spread across 50 people. Move one of the important nodes and you've changed more than the org chart.

General experience and local expertise are different things

Say an engineer with ten years of experience moves from a payments platform they've worked on for four years to a new logistics product. They haven't become less experienced. Their ability to reason about software, debug hard problems, review designs, and spot failure modes goes with them. What doesn't travel well is their local advantage.

Studies of software teams have found that team familiarity is significantly associated with better performance. Generic measures like years at the firm aren't consistently associated with performance, but experience in a specific role is. Experience is partly portable; expertise is partly situated. Software organizations often treat them as the same thing.

Research on developer fluency shows the cost of that assumption. Basic task productivity rises with project tenure, and on large projects it can take up to a year to level off. Adjusted for task difficulty, capability keeps rising for years, and developers gradually take on more central and consequential work.

A senior engineer joining a new project doesn't turn into a junior engineer, but they do become a newcomer, and newcomers have to learn. Studies of engineers joining unfamiliar projects describe it as entering a new landscape: learning not only the code but the practices, the culture, the people, and the small signals that tell you whether you're on the right track.

One move can reset two learning curves

Take a mature system owned by an engineer named Jane Doe, who has worked on it for four years. Leadership starts a new project and wants its strongest engineers on it, so Jane moves. John Doe, a competent engineer, takes over her old area.

Now John has to learn Jane's system while Jane learns a new domain. The source team has lost deep local context. The destination team has gained someone very capable with little local context. And the person best placed to get John up to speed is busy climbing her own learning curve.

This is why internal transfers are easy to misprice. The headcount spreadsheet says a senior engineer moved from Team A to Team B. The knowledge view says Team A lost four years of context, and Team B gained a strong engineer whose domain context starts near zero. Same event, very different economics.

The transfer may still be the right call, but it has a price, and most organizations never work it out.

The old system doesn't just carry on

The cost to the source team goes beyond onboarding a replacement. Complex systems have technical dependencies, and those create human coordination around them. A developer may need to know that changing service A means talking to whoever owns service B, even when the dependency barely shows up in the code.

An experienced engineer carries a map of more than the modules. It covers how modules relate to teams, operational constraints, customers, and old decisions, and it's what tells them whether a change is safe. When that person moves, the code stays. The map may not.

This is also why I'm skeptical that AI coding tools close the gap on their own. Agents that can read an entire repository are genuinely useful for orientation: they can explain what a service does or trace a call path in minutes. But most of the map lives outside the repo, in incident history, customer commitments, abandoned migrations, and knowing who to call before changing something. An agent can only reason over the context it's given, and most of this context was never written down. AI makes the code easier to read. It makes the person who knows what the code doesn't say more valuable.

Other research points the same way. In large codebases, measures of organizational structure have predicted failure-proneness, in some cases better than code-based measures, and organizational volatility, including recent departures, has been linked to more customer-reported defects.

Moving one experienced engineer won't necessarily break a system, but the evidence is consistent that software quality is partly organizational. The people around the code, and what they know, are part of the system.

Then we hand the experienced engineer a blank page

We often move experienced engineers to new projects precisely because of what they learned on old ones. That makes sense, but experience comes with scars.

Suppose someone spent four years running a system that eventually hit severe scaling problems. On the next project, their instinct is that they won't make that mistake again. So the new system gets queues, caching, event sourcing, multi-region infrastructure, a generalized permissions system, an internal platform, layers of extensibility, heavy observability, and a careful abstraction around a data model that doesn't exist yet. Some of those calls may be right. Some may solve problems the product doesn't have yet.

Engineers have long called a version of this the second-system effect: after building one system, designers are tempted to load the next one with every idea they had to defer. It's a useful practitioner warning, not modern causal evidence. The research is much stronger on context loss than on any claim that experienced engineers systematically overbuild.

So the principle is narrower: experience from another context should produce hypotheses, not requirements. Someone who has lived through a scaling disaster should bring that knowledge into the next system, but "this failed before" isn't the same as "this product has the same constraint." Without context, even good lessons get applied too early.

Seniority doesn't have to mean starting over

Often the reward for years of depth is another greenfield project: another roadmap, another architecture phase, another race to ship. The research doesn't show that this alone causes burnout, but workload and job demands recur throughout the software-engineering burnout literature, and a new project isn't automatically growth. There are other ways to grow.

Picture a different career path. An engineer joins a system and implements features. Then they understand the architecture, then production, then how customers actually use it, then the odd edge cases, the historical constraints, and the relationships across teams.

This is often where organizations decide the engineer has outgrown the system. I'd argue they've just reached the part of the learning curve where unusually valuable work becomes possible. Their job can change without throwing their context away. They can spend less time on routine features and more on questions like:

• Why does this kind of incident keep happening?
• Why is deploying this subsystem still risky?
• Why do three teams keep building workarounds for the same component?
• Why does the architecture produce the same organizational bottleneck every six months?
• Which assumption from four years ago no longer holds?
• Where are we paying for complexity to handle a constraint that's gone?
• What problems can newcomers still not see?

These are hard engineering questions, whatever the org chart calls them, and the person best placed to answer them may be the one with enough context to recognize the pattern.

That gives a career path of implement, understand, master, investigate, simplify, teach, instead of implement, understand, become valuable, move, restart.

When moving someone is right

Rotation has real benefits: more motivation, less monotony, and knowledge spread more widely across the organization. It also has real costs: more cognitive effort, more workload, and temporary drops in productivity.

So rotation makes sense, with its costs counted.

There are plenty of good reasons to move someone. They may want a new challenge. A team may depend too heavily on one person. The company may need knowledge spread more widely. The system may be close to retirement. A successor may already have enough context to take over. Or the person's career goals may simply be elsewhere.

What matters is whether the context stays covered after someone leaves. For Jane, the real question is what knowledge system remains if she moves.

Context anchors, not knowledge silos

Most mature organizations need something between permanent ownership ("you built it, it's yours forever") and constant rotation ("you've learned enough here, go start something else").

One option is to keep one or more experienced engineers close to critical systems as context anchors and pair them with successors. The successor doesn't just pick up tickets. They join incidents, make progressively bigger changes, learn why the architecture is the way it is, and build relationships with the surrounding teams until they can run the system on their own. At that point, moving the anchor costs much less.

This fits the research on knowledge redundancy and team dynamics: redundancy is valuable, but it takes real investment. What makes it work is overlap. Documentation helps, but it doesn't replace people. Fresh perspective helps too, but it should be added alongside the expert, not swapped in for them. The aim is a second person who genuinely understands the system, so it doesn't hinge on one.

Move problems before you move people

When a senior engineer gets bored or underused on a mature system, the usual fix is to move them to a new project. A better first question might be whether you can change the problems they work on without throwing away their context.

Routine work can go to others, and harder problems can go to them. A context-rich engineer doesn't need to build every feature in the system they know. Their time can shift toward reliability, hard performance problems, complex migrations, simplifying the architecture, recurring incident patterns, technical debt with measurable business impact, mentoring, design review, and longer-horizon improvements.

The context stays; the altitude changes. It also makes room for newer engineers. The senior engineer stops being the person who does everything and becomes the one who helps others learn the system while spending their own time on the problems that need the most judgment.

When you bring in outside expertise, pair it with context

This has implications for consultants, specialist networks, and outside engineering talent.

Say a company has a serious database-contention problem. Its internal engineer knows the schema history, customer workflows, odd data invariants, operational requirements, failed migrations, and what absolutely can't break, but may never have solved this kind of database problem. An outside specialist may have seen the same pattern 20 times and recognize it immediately, while knowing nothing about the company.

Treating either one as a substitute for the other is the error. The internal engineer explains what this system actually means; the specialist explains what this kind of problem usually means. In practice, the specialist should work through the internal engineer: they diagnose together, the internal engineer owns the change, and the engagement ends when the reasoning has transferred, not just the fix. Together they often get there much faster than either would alone. Then the specialist leaves, the internal engineer stays, and what was learned stays with the organization. That works far better than continually swapping engineers in and out.

Measure what moving context costs

Most companies have very little data on this. They know when an engineer changes teams but rarely know what the move did to the system left behind.

An engineering organization that took this seriously could track, after a high-context person moves:

• incident diagnosis time
• change failure rate
• review latency
• escaped defects
• rollback frequency
• time needed for high-risk changes
• how many people can operate the system independently
• how long until a successor can make consequential decisions without help

And on the receiving side:

• how long until the transferred engineer makes independent, high-impact decisions
• how much review they need
• how much of their early architecture gets reversed later
• how much infrastructure and abstraction gets built before the product actually needs it

You don't need another 40-metric dashboard, just one invisible number made visible: how much context you lose by moving this person.

Sometimes the answer is very little, and you should move them. Sometimes it's a lot but the move is still worth it, so you move them carefully. And sometimes you find you're about to move the only person who understands the most fragile part of the company because another project has a more exciting roadmap. That one deserves a harder conversation.

Engineers aren't interchangeable capacity

The spreadsheet view of engineering says Team A has eight engineers and Team B has six. Move one senior engineer from A to B and you get seven and seven. Balanced.

But teams aren't buckets of interchangeable hours. The same engineer can have very different leverage in two places. On a new system they contribute like a strong senior engineer. On a system whose technical and organizational history they know deeply, they can be worth a great deal more. The difference is accumulated context, and it says nothing about their general ability.

One of the more useful findings in this research is that generic tenure explains less than you'd expect. Familiarity, role-specific experience, expertise coordination, and project fluency keep showing up as what matters. So besides asking who your strongest engineers are, ask where each engineer is unusually valuable because of what they've learned there. The two questions lead to very different staffing decisions.

Let context compound

Software organizations have a strange habit. Someone spends years building up knowledge until they can see further into a system than almost anyone, and that's exactly when we decide they're ready for something new.

Sometimes they are. Sometimes moving is exactly what they want and what the company needs. But it should be a decision, not something that happens automatically with seniority. What the organization has is the engineer plus their context, relationships, history, and judgment, and pulling those apart has a cost.

So don't punish accumulated context by discarding it casually. Let senior engineers go deeper, not just elsewhere. Let successors learn while the people with context are still around. Bring in fresh perspective without automatically removing local expertise. And when you do move someone, be clear about what knowledge goes with them and what stays behind.

Past a certain point, the strongest engineer on a system is valuable because they remember what the system has forgotten. That memory is the most expensive thing you can ask an organization to rebuild.