Root cause

As explained in Think Like a Software Engineering Manager

A root cause is an underlying factor responsible for an observed outcome, problem, or change.

When a team member is stressed, disengaged, or preparing to leave, the visible problem is not always the real problem. A root cause is an underlying factor responsible for an observed outcome, problem, or change. Finding it helps a manager choose support that addresses the situation rather than treating only its symptoms. section 3.2.2 section 8.4.2

Use a practical root-cause check when a morale or attrition problem appears:

• Listen through one-on-one conversations, open communication channels, feedback forums, or an exit interview. section 3.2.2 section 8.4.3
• Name the possible cause specifically, such as work dissatisfaction, inflexibility, personal circumstances, compensation, or project-related problems. section 8.4.2
• Separate controllable factors from circumstances outside the manager’s control. section 8.4.2
• Match the response to the cause: rebalance workload, provide support, adjust a project or role, explore internal mobility, or accept an unavoidable departure. section 3.2.2 section 8.4.2
• Look for recurring patterns across departures and use them to improve processes and retention practices. section 8.6 section 8.4.3

A resignation with different possible causes

Suppose David resigns. Work dissatisfaction, flexibility problems, personal circumstances, compensation, or project problems could each be a root cause. A project problem may be addressed through support or a project change; a family relocation to a region without a company presence may not be controllable. The appropriate response therefore depends on the cause, not merely on the resignation. section 8.4.2

Root-cause work is both responsive and preventive. After a departure, debrief the employee, gather additional information through human resources, identify trends, and address concerns among remaining team members. Each case can reveal gaps in workload, communication, career opportunities, compensation, or team processes. section 8.4.3 section 8.6

Figure 8.3 A sample offboarding checklist to use for a seamless transition when an employee departs the team

Use the offboarding checklist to support a smooth transition while investigating what the departure can teach the team. section 8.4.3

How Think Like a Software Engineering Manager covers it

How deep it goes

Defines the idea and gives diagnostic categories and responses, but stops short of a formal analytical method or causal model.

Examples

Uses stressed employees, David’s resignation, family relocation, project dissatisfaction, and postdeparture feedback as practical examples.

What it assumes

Assumes responsibility for employee wellbeing or team outcomes and teaches the distinction between controllable and uncontrollable causes.

What you can do after

Diagnose whether a problem is controllable, select a cause-matched response, and turn departures into retention or process improvements.

How it connects

Connects root cause with morale problems, employee attrition, retention, workload management, internal mobility, exit interviews, and process improvement.

liveBookmanning.com

Read Think Like a Software Engineering Manager on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  The Art of CodeA root cause is the underlying condition or defect that initiates or substantially contributes to an observed failure.
• 

  liveBookmanning.com
  Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and TerraformThe underlying condition or defect that produces an observed software problem.
• 

  liveBookmanning.com
  Troubleshooting Java, Second EditionThe underlying reason a software behavior or failure occurs.
• 

  liveBookmanning.com
  Writing for Developers: Blogs that get readThe underlying defect or condition that produces an observed software failure.

Compare how 5 books explain root cause →

Related concepts

• Five Whysaddressed by · The Five Whys is a root-cause analysis technique that repeatedly asks why a problem occurred to trace it toward underlying causes.
• exceptioncontrasts with · An exception is a runtime signal or object representing an abnormal condition that interrupts ordinary program flow and may be handled or propagated.
• cause analysisproduced by · Cause analysis is a systematic investigation of the underlying factors that produced a problem, failure, incident, or other outcome.
• countermeasureaddressed by · A countermeasure is an action or control intended to address a problem or threat by reducing its causes, effects, or likelihood.
• postincident analysisproduced by · Postincident analysis is a structured examination of an incident and its response to understand what occurred, identify causes, and determine improvements or corrective actions.

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.