Moving People Is Not Moving Capacity

A priority initiative slips. The response looks obvious in a staffing spreadsheet: move a senior developer from another team for two sprints. One row gains a person. The other loses one. Total headcount stays constant.

The delivery system does not.

The receiving team gains someone who must learn its decisions, dependencies, and ways of working. The original team loses context that may not exist anywhere else. Both teams renegotiate who knows what, who decides, and who can review the next risky change. The move may still be worth it, but the spreadsheet has hidden most of the transaction.

This is the mistake behind many attempts to rescue late work. Leaders treat developers as portable capacity while the work depends on relationships and context that are not portable at the same speed.

Familiarity is part of the production system

Developer reassignment changes a team's shared context, role knowledge, and coordination patterns. Field studies associate prior experience working together with better performance, especially when software work already demands difficult coordination. They do not prove that every reassignment causes delay or that teams should never change.

That distinction matters.

Espinosa et al. (2007) studied geographically distributed software teams and separated two kinds of experience. Task familiarity concerns prior experience with similar work. Team familiarity concerns prior experience with the same people. Both helped, but not in a simple additive way. Team familiarity became more useful when coordination was harder, including in larger or more dispersed teams. Task familiarity could partly compensate when team familiarity was weak, and vice versa.

For a delivery leader, this means a staffing decision changes more than available hands. It changes the team's stock of shared experience. The cost is likely to matter most where dependencies, distance, or team size already make coordination difficult.

Huckman et al. (2009) reached a compatible conclusion using project data from an Indian software services firm. Team familiarity was positively associated with performance. Experience in a specific role also mattered, while general tenure at the firm was not consistently related to results.

A veteran developer is therefore not automatically ready capacity for any initiative. Ten years in the organisation cannot substitute immediately for knowing this team's architecture, current trade-offs, review habits, and informal coordination paths.

Not all movement has the same effect

The evidence does not support a blanket rule for stable teams. People leave. Priorities change. Critical knowledge sometimes needs to spread. The useful question is what kind of movement you are creating and which capability must survive it.

The most direct research in this evidence set examines project-to-project rotation inside software organisations. Santos et al. (2016) interviewed people across management and engineering roles in a large software organisation that used rotation. Participants described learning opportunities and work variety alongside cognitive workload and performance costs. They also reported weaker feedback when frequent movement separated people from the consequences of their work.

Santos et al. (2017) combined a systematic literature review with qualitative industry cases. Its abstract reports motivation and reduced monotony as benefits. It also reports social conflict, cognitive effort, workload, and temporary productivity loss as limitations.

These studies do not give leaders a universal rotation frequency. They do show why duration and purpose matter. A move designed to spread knowledge has a different success condition from an emergency transfer intended to rescue a deadline.

Other evidence sharpens the boundary. Foucault et al. (2015) linked external newcomer activity with lower quality in open-source projects, but open-source turnover is not the same as internal reassignment. Fægri et al. (2010) followed a support rotation that showed signs of increasing knowledge redundancy, yet participants judged the efficiency costs too high and the organisation stopped it.

That case is useful because it resists an easy slogan. Knowledge redundancy can make an organisation less dependent on a few specialists. Building it consumes time and attention. A rotation that looks inefficient this month may reduce a future dependency; a rotation without a clear learning purpose may simply interrupt two streams of work.

So the management choice is not “stable teams or flexible staffing.” It is whether the expected benefit of movement justifies the coordination and transfer demand created now.

Make the continuity cost visible

Before approving a reassignment, write a small staffing decision record. This is a practical design derived from the evidence, not a tested universal intervention. Its purpose is to expose assumptions that a headcount plan suppresses.

Use four questions.

1. What should change because of this move?

Name the delivery problem. “Initiative B needs help” is too vague. Is the constraint scarce domain knowledge, review capacity, an unresolved dependency, or simply too much work in progress?

If the constraint is an approval queue or a missing external decision, another developer may add waiting rather than remove it.

2. Which continuity leaves the original team?

Record the components, decisions, relationships, or recurring tasks that depend on the person being moved. Include review and mentoring work, not only assigned tickets.

This is not a claim that the person is irreplaceable. It is an inventory of transfer demand. If nobody else can describe the work, the reassignment includes a knowledge-risk decision whether leadership names it or not.

3. Who absorbs the transfer work?

Identify who will help the developer enter the new team and who will cover the work left behind. Onboarding, explanation, review, and handoff are work. They consume the time of people who were already part of the delivery plan.

Do not hide this work inside an optimistic capacity increase. Put it beside the expected benefit.

4. When will you review the decision?

Set a review point tied to observable outcomes. Did the target constraint move? Did review queues shorten? Did the original team's forecast change? Did defect investigation or dependency waiting increase?

The evidence does not provide a universal two-sprint threshold. Choose a point at which you can still reverse or redesign the move. A reassignment that has no review date easily becomes an accidental reorganisation.

Try it on one planned move

On Monday, take one proposed reassignment and pause the headcount discussion for 20 minutes. Complete the four questions with the two affected teams. Then make one explicit choice: proceed, reduce the scope of the move, create a time-bounded rotation with a learning goal, or stop lower-priority work instead.

The record will not calculate the true cost in advance. The studies behind this article are observational or action research, and none isolates frequent reassignment across concurrent corporate initiatives. They support the mechanism, not a precise forecast.

That is still enough to improve the decision. Familiarity, role experience, and shared context are productive assets. Moving a person can transfer expertise, but it can also remove the coordination capacity that allowed another team to deliver reliably.

A staffing spreadsheet counts people. A delivery system must account for the relationships and knowledge that make those people effective together.

References

Espinosa, J. A., Slaughter, S. A., Kraut, R. E., & Herbsleb, J. D. (2007). Familiarity, complexity, and team performance in geographically distributed software development. Organization Science, 18(4), 613–630. https://doi.org/10.1287/orsc.1070.0297

Foucault, M., Palyart, M., Blanc, X., Murphy, G. C., & Falleri, J.-R. (2015). Impact of developer turnover on quality in open-source software. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (pp. 829–841). ACM. https://doi.org/10.1145/2786805.2786870

Fægri, T. E., Dybå, T., & Dingsøyr, T. (2010). Introducing knowledge redundancy practice in software development: Experiences with job rotation in support work. Information and Software Technology, 52(10), 1118–1132. https://doi.org/10.1016/j.infsof.2010.06.002

Huckman, R. S., Staats, B. R., & Upton, D. M. (2009). Team familiarity, role experience, and performance: Evidence from Indian software services. Management Science, 55(1), 85–100. https://doi.org/10.1287/mnsc.1080.0921

Santos, R. E. S., da Silva, F. Q. B., de Magalhães, C. V. C., & Monteiro, C. V. F. (2016). Building a theory of job rotation in software engineering from an instrumental case study. In Proceedings of the 38th International Conference on Software Engineering (pp. 971–981). ACM. https://doi.org/10.1145/2884781.2884837

Santos, R. E. S., da Silva, F. Q. B., Baldassarre, M. T., & de Magalhães, C. V. C. (2017). Benefits and limitations of project-to-project job rotation in software organizations: A synthesis of evidence. Information and Software Technology, 89, 78–96. https://doi.org/10.1016/j.infsof.2017.04.006

AI disclosure: AI was used to help create this article. Responsibility for the published content remains with Nico Thümler.