Organizational Health and Underperformance

On a fictional software company’s data platform team, the same senior engineer answered the page almost every night. The rotation had four names, but two were recent hires who escalated everything to her, and the lead removed himself during planning weeks. She and the lead argued in a retrospective, and he recorded it as a personality conflict. A new hire missed two deliverables in a quarter when priorities changed three times and was marked as underperforming. In the spring the senior engineer resigned, exposing the ingestion pipeline’s dependence on her knowledge. These events call for investigation into working conditions as well as individual performance. The account below uses this invented case to examine conflict, performance support, on-call capacity, key-person dependency, and organizational health. It draws on Google SRE practice, GitLab’s public handbook, DORA research, and UK management standards; the remedies must be adapted to the service and organization.

Investigating the person and the working conditions

Asking whether another person in the same seat would encounter the same problem is a useful way to find constraints. It is a hypothesis, not an experiment that has already been run. Here, the escalation records establish a concentration of work. To understand the missed deliverables, the manager still needs to establish which commitments changed, what the new hire understood, what support was available, and which parts of the work were within his capability. Structural constraints and individual development needs can coexist. A manager can improve staffing while also giving specific feedback about delegation or conduct.

Google’s SRE model reserves at least half of work time for engineering and describes a 25% on-call allocation alongside other operational work. That 25% is a share of the whole allocation, not a quarter of the remaining half. Its staffing calculation concerns scheduled coverage: with one primary and one secondary continuously assigned, eight engineers give an average assignment fraction of 2/8, or 25%, over the calendar. It is not a calculation that turns every assigned hour into active incident labor or uses a 40-hour workweek as the denominator. Google describes six engineers at each site for a two-site team. These are planning assumptions for its operating model. Another service must establish its required coverage, roles, qualified staff, leave, and sustainable limits. In the fictional team, four names conceal dependence on two qualified responders and repeated concentration on one of them.

DORA’s 2024 report finds a relationship between unstable organizational priorities and worse productivity and burnout outcomes. The survey asks respondents how stable their organization’s priorities are; it does not establish a safe number of changes per quarter. The report’s authors suggest that frequent changes create uncertainty, reduced control, and additional work. A manager can investigate that explanation by reviewing what changed, how much work was discarded, and how people experienced it. Team Topologies adds another perspective: responsibilities and tools consume team attention. The entry on cognitive load explains why the total demand on a team matters.

What was recorded	Possible individual contribution	Possible structural contribution	What to investigate
Senior engineer is exhausted and irritable	Difficulty delegating or asking for relief	Too few qualified responders and repeated overnight interruptions	Compare assignments, actual work, available relief, and her account of the burden
Engineer and lead argue in a retrospective	How each person expressed the disagreement	Unequal load or unclear exemption rules	Separate the facts about coverage from the choices about fairness and the conduct of the discussion
New hire missed two deliverables	A capability or execution gap	Changed commitments, missing access, or insufficient support	Reconstruct the agreed work and changes; ask what blocked delivery
Pipeline knowledge lives in one head	Knowledge-sharing practices may need improvement	No time or assignment for learning, restricted permissions, or system complexity	Test which tasks others can perform and identify the dependency that prevents coverage

The table starts an inquiry. None of its possible explanations follows automatically from the observed event. Confirmed structural problems need action, and confirmed performance or conduct concerns need timely feedback. Work on both when the evidence supports both; neither a staffing change nor coaching should be used to avoid the other responsibility.

Conflict: managed, not avoided

GitLab’s Managing Conflict guidance treats conflict as something to address and gives both perceived inequity and unclear roles as possible causes. The engineer’s complaint contains a substantive question about who carries the service. Classifying it only as personality would miss that question. The manager should establish the distribution of work and hear both participants’ accounts without assuming that the substance determines whether their behavior was appropriate.

The handbook describes competing, avoiding, accommodating, compromising, and collaborating. Each serves a different situation: a person with the necessary authority may need to make an urgent decision; a discussion may need a pause; a minor preference may be conceded; a temporary compromise may permit work to continue; and collaboration may reconcile interests when time and participation allow it. Choose with regard to urgency, stakes, authority, available time, and the working relationship. During an incident, assign immediate cover first. Discuss the enduring rotation rules afterward with the people affected. Pager logs inform that discussion, but cannot choose a fair compensation policy or decide which tradeoffs the organization accepts.

A disagreement can surface a valuable issue while also being handled badly. GitLab asks people to support their position with evidence and remain respectful; the UK line management standards ask managers to address developing tensions early. Assess what the exchange clarified, what behavior occurred, and whether a workable resolution followed. Concerns about conduct may require a separate process. The retrospective raised an important staffing issue, but that alone does not establish the quality of the interaction or the health of the whole team.

Underperformance: investigate and support early

GitLab’s underperformance guidance favors early attention to performance concerns. Missed commitments, unclear progress, and colleagues repeatedly working around someone are reasons to ask what is happening. They are not a diagnosis. The manager should describe the gap against a legitimate, understandable role expectation, consider its impact and context, and hear the person’s account. A serious event can require immediate action; a minor variation does not by itself establish a sustained pattern. There is no universal waiting period of several weeks before a concern can be discussed.

GitLab uses a skill-and-will model to explore performance gaps. It can help distinguish a need for practice or tools from a question about engagement, but observations such as delayed work do not reveal motivation by themselves. Check capability, workload, access, clarity, support, and the person’s explanation; causes may be mixed or unresolved. Ask what support would help without requiring private personal details. The handbook permits people to keep those details private and provides specialist support routes. In the fictional case, changed priorities and unequal pairing warrant investigation; they do not yet establish either a pure skill gap or a purely structural cause. The underperformance entry develops these distinctions.

For routine performance development, GitLab recommends private coaching with a brief written record shared with the team member. Record the concern, expectations, support, agreed actions, and review date, and allow the person to explain, disagree, and correct factual errors. Documentation supports fairness; it does not supply fairness by itself. Involve the relevant people team early under the organization’s process. Serious conduct concerns or immediate risks may need protective action or a separate formal route without waiting for coaching to finish. Investigating causes, providing support, and following the applicable procedure can proceed together. The articles on expectations and feedback and performance management explain the ongoing conversations and assessment process.

The UK standards connect fairness with impartial treatment and equality of opportunity. Applying that principle requires adequate support for the person’s role and needs. Identical onboarding sessions or pairing hours do not necessarily provide an equal opportunity to succeed. In the case, one new hire received a month of pairing and the other did not. The manager should determine what each needed and received, rather than infer fairness solely from matching or different schedules. Support, expectations, and opportunities to respond must be substantive as well as recorded.

Workload and on-call: limits you can count

On-call load needs several measures. Track the fraction of the coverage schedule assigned to each person, actual response work, interrupted rest, and follow-up commitments. Google estimates an average of six hours for an incident including investigation and remediation, which motivates its example limit of two incidents per 12-hour shift. Those are planning values, not fixed durations for every incident. Deduplicate pages into incidents and inspect the distribution and backlog: nine quiet shifts and one with twenty incidents still have a median of zero. Local limits should reflect severity, peaks, recovery time, and available help. The on-call rotation entry explains the coverage and workload calculations.

When load exceeds sustainable limits, assign improvement work, an owner, and measurable targets. Google’s chapter identifies misconfigured monitoring as a common source of overload. Remove duplicates or route low-priority conditions appropriately while verifying that conditions requiring urgent action still reach a qualified responder. A lower page count alone cannot demonstrate that detection improved. Work that is repetitive and automatable belongs in the discussion of toil. If another team’s changes create the load, negotiate ownership and remediation. Transferring a pager requires an accepting owner, an agreed cutover, working access and escalation, and fallback cover; it cannot leave the service unattended. At the other extreme, responders need enough practice to retain competence. Google’s once-or-twice-per-quarter guidance is a useful prompt to review readiness in a quiet or large rotation, not a guarantee of it.

Google describes an out-of-hours compensation cap that functions as a workload constraint in its own arrangements. A pay cap elsewhere can simply leave continuing work unpaid. Enforce the actual assignment limit, identify relief, and escalate staffing shortfalls. Response also requires clear escalation, incident procedures, and learning after failure; blameless postmortem explains the last of these. Follow-the-sun coverage can reduce night work when time zones, staffing, and handoffs fit. Check the local hours across the full schedule, including seasonal clock changes, and account for emergency fallback that may still interrupt rest.

DORA’s findings are a reason to investigate unstable priorities alongside workload and support. They do not diagnose burnout in a particular person from a change count or pager log. Ask about exhaustion, recovery, and the experience of work through appropriately confidential conversations or surveys, then act on what is learned. The UK standards place ongoing attention to wellbeing within line management. Explain who can see responses and what support or follow-up is available, especially where a small team’s comments could identify someone.

Key-person dependency: a risk, not a rating

A system depending on one person’s knowledge has an operational exposure regardless of that person’s rating. GitLab’s talent guidance distinguishes a single point of failure from key talent. The distinction does not mean that every dependency has the same consequences: consider what work stops, how quickly harm develops, and how recovery can proceed. The bus factor is the minimum number of people whose simultaneous absence would make work fail under a defined scope and disruption criterion, following the truck-factor definition used by Avelino and colleagues. For the pipeline, a value of one requires evidence that a particular person’s absence is sufficient to prevent the required work.

Start with the actual dependency. Another operator may need knowledge, permissions, practice, or enough available time. Have them use the documentation, perform representative recovery tasks, and demonstrate readiness before taking independent responsibility; a pairing end date is a review point, not proof of competence. An expert can remain available as backup during supervised practice. Automation, simpler systems, alternate support arrangements, and properly authorized access may address other dependencies. The UK capability framework makes developing others part of senior technical work, but managers must also allocate time and resources. In this fictional case, the new manager confirms that no learning assignment or protected teaching time had been provided. The article on talent and succession covers succession readiness, while the career framework connects development work to role expectations.

Organizational health as a set of observable signals

Organizational health can be investigated through both working conditions and people’s experience of them. Telemetry can reveal concentrated interruptions; a conversation or survey can reveal how predictable, recoverable, or threatening those interruptions feel. Neither gives a complete account. Use the following signals to decide what to investigate, with the population, period, and reporting limits made clear.

Signal	Evidence to combine	Questions to investigate
Scheduled on-call share and incident work	Coverage, severity, peaks, follow-up work, and rest	Is there enough qualified coverage and capacity for the actual workload?
Distribution of interruptions	Shift hours, difficulty, escalation, role, and availability	Is one person carrying hidden work, and what support or redistribution is needed?
Priority changes	Changed commitments, discarded work, and reported stability	Which changes affected delivery or control over work?
Dependency on particular people	Task coverage, permissions, demonstrated competence, and availability	What would stop during an absence, and which mitigation addresses it?
Conflicts raised and revisited	Accounts from participants, conduct, decisions, and follow-through	Is the issue unresolved, recurring for a new reason, or now easier to report?
Response to performance concerns	Initial evidence, discussion, support, and applicable process	Was action timely and proportionate, with a chance to respond?
How people experience raising concerns	Confidential feedback and observed responses to concerns	What made speaking up possible or difficult, and are other channels being used?

Fear can suppress reporting, but some people speak despite it. Silence can also mean that a person did not know about the problem, lacked time, or used another channel. Automated logs do not depend on a person choosing to report, though their coverage and interpretation still need checking. The psychological safety entry separates shared perceptions from individual events. The article on measuring friction explains how to combine workflow observations with reported experience. The retrospective is evidence that one issue was raised, not a measurement of everyone’s safety.

The team, a year later

A year after the resignation, the fictional company’s new manager has changed the response arrangement. She first traces recurring pages to duplicate notifications and low-priority conditions, changes their routing, and tests that urgent failure scenarios still page the right responders. Daily pages fall by two thirds in this invented example; detection checks, service outcomes, and responder feedback are reviewed with the count. She then pools coverage with another site, reaching six qualified responders at each site, twelve in total. Site A covers 00:00–12:00 UTC and site B 12:00–24:00 UTC, each with a primary and secondary. The sites confirm handoff acceptance and designate qualified relief for planned leave and missed handoffs. At equal allocation, the baseline is 28 assigned hours per person per week, or 16.7% of 168 calendar hours, before relief and handoff overlap. The manager verifies each actual roster against its limit. She checks local shift hours and rest, including clock changes, rather than claiming that two sites eliminate night work. Nighttime escalation remains a tracked burden with explicit backup and recovery arrangements.

The manager pauses the new hire’s performance conclusion while reviewing the earlier commitments and support. She agrees on stable deliverables for a quarter and provides a month of pairing. He meets the new commitments. That supports continuing the arrangement, but the simultaneous changes in tasks, support, and experience do not identify one cause of the earlier outcome. For ingestion, the revised plan assigns one of the qualified responders as the current operator; this is the role a year after the resignation, not the departed engineer. A second operator demonstrates the defined recovery tasks with the necessary access before taking independent primary duty. The current operator remains backup during the transition. Their immediate goal is to cover one planned absence for those tasks; the service’s other capacity and simultaneous-absence risks are assessed separately. They review the evidence quarterly and after relevant changes. The working agreement allocates shifts with regard to qualifications, availability, role, night work, and actual effort. Exceptions have a reason and review arrangement; equal shift counts are not treated as proof of equal burden.

The manager also asks about workload and speaking up through confidential feedback, explaining access and reporting limits. She compares those accounts with the operational record and discusses what action followed. A survey without follow-through would leave problems unresolved; a pager log alone would miss parts of the experience. The earlier argument leads to a discussion of staffing and fairness, with the participants’ conduct considered separately. The manager records what has improved and what remains uncertain.

What a reviewer should ask

A team’s health, or a manager’s handling of a person problem, can be reviewed with a short list, each item tracing to something above.

• What evidence supports structural, capability, or conduct explanations, and could several apply?
• Who is qualified and available to cover the required roles? How do scheduled coverage, active work, follow-up tasks, peaks, and recovery time compare with local limits?
• Which pages require action? After a monitoring change, what evidence shows that important conditions still trigger an effective response?
• Which priority changes altered commitments or discarded work, and how did people experience them?
• Which parts of a conflict concern facts, values, authority, or conduct? What immediate decision and later participation does the situation require?
• Has a performance concern been discussed promptly against clear expectations, with support and an opportunity to respond? Are mixed causes and any separate formal process being considered?
• Did the person have support appropriate to their role and needs? Does the proposed allocation account for differences in actual burden?
• For each critical service, which absences would disrupt defined tasks? Have alternate operators demonstrated capability, access, and availability, and are other mitigations needed?
• What do reported experience and observed responses reveal about raising concerns? Which perspectives or events may be missing?

In this case, the concentration of response work required a staffing and dependency remedy. The missed deliverables and the argument required their own evidence and conversations. A manager’s record should make those distinctions visible: what happened, what was investigated, what changed, and what still needs review.

References

• Google, Site Reliability Engineering, Chapter 11: Being On-Call (2017, CC BY-NC-ND 4.0).
• Google, Site Reliability Engineering, Chapter 29: Dealing with Interrupts.
• GitLab Handbook, Underperformance, updated 4 September 2025.
• GitLab Handbook, Managing Conflict.
• GitLab Handbook, Talent Assessment (single point of failure and key talent).
• DORA, Accelerate State of DevOps Report 2024 (burnout and unstable priorities).
• UK Civil Service, The Line Management Standards: Core stage, April 2025, V1.2.
• Matthew Skelton and Manuel Pais, Team Topologies: Key Concepts.
• UK Government Digital and Data Profession Capability Framework, Software developer, updated 29 August 2025.
• DORA, 2024 Research Questions.
• Avelino et al., A Novel Approach for Estimating Truck Factors (2016).