liveBook · Manning

Employee turnover

As explained in Think Like a Software Engineering Manager

The gradual loss of employees from an organization through departures that are not immediately replaced.

A valued engineer leaves, and the team must keep work moving while it finds a replacement. Employee turnover, also called attrition here, is a reduction in the workforce through departures. Its effect is more than a vacancy: the team loses knowledge and may carry extra work for months. section 8.0 section 8.1

Departures have different causes:

  • Voluntary departures can reflect dissatisfaction with compensation, the role, career growth, or company culture; personal circumstances can also matter. section 8.6
  • Involuntary departures include layoffs and termination for underperformance. Restructuring or workplace policies can make the distinction between choice and constraint less clear. section 8.6 section 8.2

Turnover is difficult to eliminate, and not every departure is harmful. But losing a key teammate can lower morale, delay work, increase stress, and leave one person holding critical knowledge. Replacement also takes time: teams redistribute work, recruit, onboard, and train someone new. A useful cost checklist is hiring plus onboarding and training plus learning time plus the cost of the unfilled role. section 8.1 section 8.3

An engineering leader can respond in three stages:

  • Plan ahead. Use one-on-ones and career discussions, development opportunities, internal mobility, recognition, and feedback to help people feel valued and surface problems early. section 8.4.1 section 8.6
  • Respond to concerns. Changes in engagement, work quality, or candor may warrant a conversation, not an assumption that someone is leaving. If an employee shares plans to depart, explore the cause and whether a suitable internal role or a compensation discussion could help. section 8.2 section 8.6
  • Prepare for departure when the decision is final. Reprioritize work, distribute knowledge through documentation or technical talks, communicate the transition clearly, and treat the departing employee with respect. section 8.4.3 section 8.3.1

When a key engineer leaves

Suppose the engineer who knows a critical service accepts a substantially higher-paying offer. If retaining them is not feasible, arrange knowledge-sharing sessions and documentation, rebalance assignments, and explain the hiring and transition plan to the remaining team. section 8.4.3 section 8.3.1

Ask yourself: If someone left this month, what knowledge would be hard to recover, and which work would need to pause? section 8.3 section 8.4.3

How Think Like a Software Engineering Manager covers it

How deep it goes
Defines attrition, traces its costs and effects, and organizes proactive, reactive, and departure-stage responses without developing a turnover-rate calculation.
Examples
Uses a valued teammate's vacancy, a layoff's effect on morale, and an engineer's higher-paying offer to make the consequences concrete.
What it assumes
Assumes an engineering leadership role while defining attrition and backfill in plain terms.
What you can do after
Practice/perform retention conversations, workload planning, and knowledge-sharing steps for a departure.
How it connects
Links turnover to employee retention, team morale, burnout, hiring, onboarding, knowledge transfer, and internal mobility.

Also explained in

Compare how 3 books explain employee turnover →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.