A backend engineer’s departure does not translate neatly into a fixed number of lost development days. The real impact depends on what that engineer was working on, which parts of the system they understood better than anyone else, and also how easily the remaining team can pick up that work.
Sometimes the problem is mostly capacity. In that case, a company may decide to extend your in-house engineering team while recruiting a permanent replacement. But developer turnover becomes much harder to absorb when the person leaving is also the main source of knowledge about a critical service, integration, or deployment process. Replacing the headcount is then only part of the recovery.
For engineering leaders, that distinction matters. A team can look fully staffed on paper yet still struggle to meet delivery timelines because the knowledge required to do the work is concentrated in too few people.
One Vacancy Can Move Work Across the Entire Release
Suppose a five-person backend team loses one engineer. It is tempting to treat that as a 20% reduction in engineering team capacity. Software delivery rarely follows such clean arithmetic.
Engineers are not interchangeable units of output. One may have spent the past year working on authentication. Another understands the payment service and its integration with Stripe. A third is the person everyone calls when a production problem involves Kafka consumers or a difficult database migration.
The work attached to those people has dependencies.
Imagine that the departing engineer is building an API required by two frontend features scheduled for the next release. Another backend developer takes over. Before continuing the API work, that developer has to understand the existing implementation, decisions already made, and outstanding issues. Their original tasks now move back.
The frontend engineers may also be affected. If the API contract changes or is delivered later than planned, integration work cannot finish on schedule. QA receives those features later, which leaves less time for testing before the planned release.
The original vacancy was in the backend team. The schedule impact has spread beyond it.
At this point, management has a planning decision to make. The team can delay the release, reduce its scope, or even move lower-priority work into a later iteration. None of those choices can be calculated accurately from headcount alone. What matters is where the missing engineer sat in the chain of dependencies.
The Code is Still There. The Context May Not Be.
Losing implementation capacity is visible. Losing context is easier to underestimate.
A useful way to think about engineering knowledge is to separate what is stored in the code from what developers learn while working with a system.
The repository can show how a service is implemented. It may not explain why the team rejected an apparently simpler design two years ago, why one customer follows a different authentication flow, or why a particular validation exists despite looking redundant.
Operational knowledge creates similar problems. An engineer may know that an external API occasionally returns an unexpected response, that a migration requires an additional manual check, or that a particular service behaves poorly under a specific workload. Some of this should be documented. In real codebases, some of it inevitably lives in people’s heads.
Then there is decision knowledge. Architecture decision records can preserve important choices, but teams do not create an ADR for every meaningful decision made during years of development.
This is the practical problem behind the software engineering concept of the “bus factor”: how vulnerable a project is when important knowledge is concentrated among a small number of contributors.
The immediate consequence is usually not that development stops. It is uncertainty.
A task estimated at two days may turn into four because the new owner discovers an undocumented dependency halfway through. A change may need additional testing because nobody is quite sure why the existing behavior was implemented that way. Code review can slow down when the person most qualified to review a particular component is the person who just left.
That makes forecasting harder at exactly the point when stakeholders are asking for a revised delivery date.
Hiring a Replacement Does Not Reset the Clock
A new engineer can close the vacancy without immediately restoring the previous level of output.
Even an experienced backend developer has to learn the product. They need to understand its architecture, local development setup, coding conventions, CI/CD pipeline, deployment process, business rules, current technical debt, and the boundaries between services.
Knowing Node.js, PostgreSQL, AWS, or Kubernetes helps. It does not provide product context.
Onboarding also consumes time from people who are already compensating for the departure. Existing engineers review early pull requests, explain architectural decisions, answer questions, and help the newcomer navigate unfamiliar parts of the system. Microsoft has discussed this problem in the context of developer productivity: onboarding requires new engineers to learn the project and their tasks while building the relationships needed to work effectively.
So “we hired a replacement” and “we restored capacity” should not appear as the same milestone in a delivery plan.
A new developer can contribute useful work early, especially when tasks are well scoped. Expecting them to take immediate ownership of the former engineer’s most complicated responsibilities is a different proposition.
A Two-Week Handover Cannot Recreate Two Years of Context
Once an engineer gives notice, teams often respond with the same request: document everything.
That is understandable and usually unrealistic.
A developer who has worked on a product for years has accumulated thousands of small pieces of context. Trying to convert all of them into documentation during the final days of employment produces a lot of writing, not necessarily useful knowledge transfer.
The better question is: What will the team struggle to figure out after this person is gone?
A service with no secondary owner deserves attention. So does an unusual deployment procedure, an integration with poorly documented behavior, an unresolved architectural decision, or a production process that only one person regularly performs.
The receiving engineer should do the work while the current owner is still available. If a deployment matters, let the second engineer run it. If a service is difficult to troubleshoot, let them investigate the next issue. If ownership of a component is changing, a small real change exposes knowledge gaps faster than an hour-long walkthrough.
Documentation still has a role. Runbooks are useful for operational procedures. Architecture decision records preserve the reasoning behind significant choices. Diagrams can help developers understand service boundaries and dependencies. Good documentation is also associated with stronger software delivery capabilities in DORA’s research.
But documentation works best when it supports hands-on familiarity. It is a poor substitute for it.
The Best Handover Happens Before Anyone Resigns
A team with strong continuity should not need an emergency knowledge-transfer project every time someone leaves.
That does not mean every engineer must understand the entire backend. Specialists exist for a reason. Making everyone equally familiar with every service would consume enormous amounts of time and reduce the benefits of deep expertise.
The practical target is secondary ownership.
For every component important enough to affect a release or production operation, someone besides the primary owner should know enough to work on it without starting from zero.
Code review is one way that knowledge spreads. Google’s published engineering practices describe review as more than a quality gate: reviewers are expected to consider design, functionality, complexity, tests, as well as documentation, and Google explicitly treats knowledge sharing as part of the process. GitHub, GitLab, Bitbucket, and Gerrit all support workflows where changes are reviewed before they are merged.
But there is a limitation. A developer who approves occasional pull requests does not automatically know how to operate or troubleshoot the service.
For critical areas, secondary owners need hands-on exposure. That may mean pairing on a complex feature, rotating maintenance responsibilities, participating in production incidents, or taking the lead on a smaller change while the primary owner remains available.
There is a cost. Pairing uses two engineers where one might have completed the immediate task. A detailed review takes time. Keeping runbooks current does not ship a customer feature.
Teams are effectively trading some short-term individual output for lower continuity risk. Pretending that knowledge sharing is free makes it one of the first things to disappear when a deadline gets tight.
Find the People Your Delivery Plan Quietly Depends On
The easiest time to identify a single-person dependency is while that person is still on the team.
Repository data provides a starting point. GitHub or GitLab history can show who changes a service most often and who typically reviews those changes. That does not tell the whole story.
Look at operational ownership too. Who gets pulled into incidents involving a particular service? Who understands the difficult third-party integrations? Who can explain the reasoning behind the data model? Who knows how to recover the system when the normal deployment path fails?
Then ask a less comfortable question: If this engineer were unavailable tomorrow, who would take over?
“No one yet” is useful information.
The response does not have to be a large knowledge-sharing initiative. A second engineer can review the next meaningful change, handle a maintenance ticket, participate in the next incident, or own a small feature in that part of the system.
Over several months, those small decisions create real overlap.
They also provide a more realistic picture of team continuity than an org chart. Five backend engineers do not necessarily provide five interchangeable units of capacity if several critical systems still depend on one person each.
More Developers Help Only When Capacity is the Bottleneck
When a backend engineer leaves, leaders need to determine what has actually become scarce.
If the remaining developers understand the system and the problem is simply that there are too few people to complete well-defined work, adding engineering capacity can help. Tasks can be redistributed, and an external or newly hired developer can take on work with clear technical boundaries.
Knowledge shortages behave differently.
Adding another engineer to a poorly understood subsystem does not make the missing context reappear. The newcomer still needs someone to explain the architecture, historical decisions, operational constraints, and business rules. If the remaining team is already overloaded, onboarding can temporarily add pressure rather than relieve it.
That is why replacing people and replacing knowledge should be treated as separate problems.
Often, both exist at once. The team may need to transfer ownership of a critical service internally while assigning better-understood work to additional developers. This keeps the new capacity productive without making a newcomer responsible for reconstructing years of context under deadline pressure.
Plan for the Departure You Cannot Predict
Developer turnover is normal. Zero disruption is not a realistic target, particularly when an experienced engineer leaves in the middle of a release.
What teams can control is how much of the disruption comes as a surprise.
DORA measures software delivery partly through change lead time: how long it takes a committed change to reach production. Its broader research treats software delivery as a system of technical and organizational capabilities rather than a simple measure of individual developer output. That distinction matters when thinking about staffing risk.
A delivery plan that quietly depends on one person understanding a payment service, deployment workflow, or critical integration already contains a risk, even while that engineer is still there.
The useful question is therefore not whether losing one backend engineer will delay a release by one week, two weeks, or a month. There is no defensible universal number.
Ask instead what work would become difficult to continue tomorrow, and who besides the current owner could pick it up.
If there is no good answer, the timeline risk already exists. The resignation simply reveals it.