The most common cause of a formal performance process is not sustained underperformance. It is sustained avoidance. The manager who avoids naming a performance problem in October faces a much more serious situation in March, and the engineer who should have received specific, honest feedback months earlier is now in a formal process that will affect their career and their confidence - often without understanding why the situation escalated so quickly.

Addressing underperformance early requires the willingness to have an uncomfortable conversation before it becomes necessary. Most managers lack this willingness, not because they are lazy or callous, but because they have not been equipped to have these conversations, because organisational cultures often punish directness, and because it is genuinely difficult to tell someone that their performance is not good enough.

This section is about building the capability to name underperformance early, distinguish its causes correctly, and intervene in ways that are honest, specific, and genuinely supportive.

Why Managers Avoid It

Understanding why managers avoid performance conversations is not an exercise in sympathy - it is a prerequisite for changing the behaviour. The avoidance is rational given the conditions most managers operate in.

Discomfort With Conflict

Telling someone that their performance is falling short feels like conflict. Most people find conflict uncomfortable. Managers who have not been given explicit training or support for performance conversations will default to avoidance because it is the path of least short-term discomfort, even though it produces the worst long-term outcomes.

Fear of Damaging the Relationship

The manager-engineer relationship is a working relationship that the manager depends on. Naming underperformance feels like a threat to that relationship. "If I tell her this, she'll be upset with me, and then working together will be awkward." This concern is not irrational. Performance conversations can damage relationships, particularly when they are handled poorly.

What managers misunderstand is the asymmetry: the short-term awkwardness of a well-handled early performance conversation is substantially less damaging to the relationship than the long-term resentment that builds when the engineer eventually discovers that the manager was concerned for months and said nothing.

Hope That It Resolves Itself

"Maybe it's just a bad patch." "Maybe the next project will go better." "She's had a lot going on personally." These are not unreasonable thoughts. Performance does fluctuate. Context matters. But the manager who waits for self-correction is often waiting for something that will not happen without intervention. Performance problems that resolve themselves are the exception, not the rule.

Not Knowing What to Say

Many managers avoid performance conversations because they genuinely do not know how to structure them. They have no vocabulary for naming a performance gap without it feeling like a personal attack, no framework for distinguishing underperformance from a bad patch from a system problem, and no practice at having these conversations in a way that produces change rather than defensiveness.

This is a development failure in the manager, not a character failure. If managers are not equipped to have performance conversations, they will not have them.

How to Identify Underperformance Early

Early identification requires knowing what to look for. The signals of underperformance are observable before they become severe, but they require attention to notice.

Delivery Signals

• Commitments are regularly not met, or are met only partially
• The definition of "done" is consistently lower quality than the team standard
• Rework rates are higher than expected - work that returns from review with significant issues repeatedly
• Escalation frequency is increasing - more blockers, more requests for help, more decisions deferred upward

Quality Signals

• Code review feedback is consistently identifying the same categories of issue
• Production incidents are attributable to this person's work at a higher rate than their peers
• Documentation, tests, and handover notes are consistently sparse or absent
• Technical judgement is regularly inconsistent with the expectations of the role level

Behavioural Signals

• Withdrawal from team discussion - less contribution in planning, less visible engagement in reviews
• Communication is becoming reactive rather than proactive - the engineer is not surfacing problems, only reporting them when asked
• Commitments made in 1:1s are not being followed through
• Peer relationships are becoming strained - friction signals from other team members

Distinguishing Underperformance From Disengagement From Burnout

These three conditions look similar from the outside and require different interventions. Getting the diagnosis wrong wastes time and makes the situation worse.

The manager who treats burnout as underperformance will cause significant harm. The manager who treats underperformance as burnout will allow a performance problem to continue. The inquiry at the start of any performance concern should include "what is causing this?" before "how do we address it?"

The Manager's Role

Before naming an individual as an underperformer, a manager should ask "what in the system am I contributing to this outcome?" This is not an exercise in avoiding accountability or in deflecting blame onto structural factors. It is the appropriate first question, because system factors - unclear expectations, poor onboarding, excessive cognitive load, poor tooling, dysfunctional team dynamics - are frequent contributors to what looks like individual underperformance.

Creating Conditions for Performance

The manager's primary responsibility is to create conditions in which the engineers in their team can perform effectively. Those conditions include:

Clarity of expectations. Does the engineer know what is expected of them? Not in a vague, "work hard and deliver" sense, but specifically: what does "done" look like, what does "good quality" mean for this work, what are the expectations of the role at their level? If expectations are unclear, the performance gap may be a clarity gap.

Effective onboarding. A new engineer who is underperforming six months into a role may be underperforming because they were not given the context, relationships, and early support they needed to succeed. Poor onboarding is a system problem that manifests as individual underperformance.

Manageable cognitive load. An engineer who is context-switching across five different workstreams, who is asked to hold context for systems they barely understand, who is continuously interrupted - is being set up to underperform. The cognitive load of the role matters. Before diagnosing individual underperformance, the manager should examine whether the work design is reasonable.

Team dynamics that support performance. A team where knowledge is hoarded, where collaboration is competitive rather than cooperative, where psychological safety is low - is a team where individual performance will be lower than it would be in healthier conditions. Team dynamics are a manager responsibility.

Managing Consequences vs Creating Conditions

The manager who only addresses underperformance through consequence (feedback, PIPs, formal processes) without examining the conditions in which the underperformance is occurring is managing the symptom rather than the cause. Both matter. The distinction is:

• Creating conditions: "I've given her unclear requirements, I've not prioritised her development, I've kept her on the same domain for two years without new challenge. Some of what looks like underperformance may be a motivation and capability-stagnation problem that I've contributed to."
• Managing consequences: "Her code quality is consistently poor. I've named that, offered support, and nothing has changed. I need to be more direct about the consequences of continued underperformance."

The effective manager does both, in sequence. Start with conditions. If conditions are right and the performance is still below expectations, then manage consequences.

Having the Early Conversation

The early performance conversation is not a formal process. It is a direct, honest conversation between a manager and an engineer, held because the manager has observed something that needs to be named. Getting this conversation right is the single most important skill in underperformance management.

What to Say

The conversation should be structured simply:

Name what you have observed. Specifically and behaviourally. Not "your performance has been poor" but "I've noticed over the last four weeks that three of your stories have come back from review with significant issues, and two were incomplete at sprint end without prior communication. I want to understand what's happening."

Invite their perspective. "What's your read on this? What's been getting in the way?" Listen to the answer. It may reveal system factors you were not aware of. It may reveal personal circumstances that explain the pattern. It may reveal that the engineer was not aware there was a problem - which is itself important information.

Be clear about what needs to change. Not vague encouragement, but specificity. "What I need to see over the next six weeks is [specific standard, specific observable criteria]."

Offer specific support. Not "let me know if you need anything" but "I'm going to pair you with [name] on the next delivery so you have a close technical partner. I'll also move the Friday 1:1 to Monday so we can plan the week together."

Set a follow-up date. "Let's talk about how this is going in three weeks."

Document the conversation. Write a brief note for your own records: the date, what was discussed, what was agreed. Not shared with HR unless escalation happens, but essential as a record.

What Not to Say

• "I just wanted to let you know some people have noticed..." - never. Attribution to unnamed others is cowardly and unhelpful. Own your observations.
• "I'm sure it's just a bad patch." - If you say this, you have undermined the seriousness of the conversation.
• "HR told me I needed to have this conversation." The manager is having this conversation because it is the right thing to do, not because it is required. Presenting it as a compliance exercise signals that you do not take it seriously.
• "I know this is hard to hear, but..." This is usually a preamble to softening what follows until the message is lost. Say what you mean directly.
• Ultimatums in a first conversation. "If this doesn't improve, I'll have to start a formal process" in the first early conversation is escalation before intervention. Save the escalation language for when it is actually the next step.

The Difference Between a Performance Conversation and a Disciplinary One

A performance conversation is about capability, delivery, and development. It is forward-looking. A disciplinary conversation is about conduct - behaviour that breaches professional standards or the terms of employment. These are different processes with different HR frameworks and different implications.

Examples of performance (wrong track, wrong output, insufficient quality): consistently missing sprint commitments, technical quality below expectations, insufficient collaboration behaviours.

Examples of conduct (behaviour requiring disciplinary not performance process): aggressive behaviour toward colleagues, dishonesty about progress, deliberate sabotage, breaches of data policy.

Treating conduct as a performance problem dilutes both processes. If conduct is the concern, it should be named as conduct and the appropriate process followed.

When It Is a System Problem

The following situations should lead a manager to question whether what looks like individual underperformance is actually a system problem:

Multiple people in similar roles showing similar patterns. If three engineers are all struggling with the same types of tasks, the issue is more likely to be in the task design, the tooling, or the expectations than in the individuals.

The engineer was previously performing well. A drop from previous performance is more likely to signal a change in circumstances - new manager, new team, different type of work, personal circumstances - than a change in the person.

The engineer cannot describe what success looks like in their role. If the expectations have not been clearly defined, the performance gap may be an expectation gap.

The onboarding was poor or absent. Engineers who joined with inadequate context, poor system access, and no effective mentoring are at a structural disadvantage that takes time to overcome.

The team dynamic is dysfunctional. An engineer performing poorly in a dysfunctional team may be a perfectly capable person responding rationally to an environment in which strong performance is not rewarded or is not possible.

System problems require system interventions. Addressing a system problem by managing the individual is unjust and ineffective. Rule out system causes before concluding that the issue is with the person.

Escalation Path

The escalation path from first concern to formal process should be clear, proportionate, and documented.

Stage 1 - Early Informal Conversation

Triggered by: first observation of a performance pattern that warrants attention.

Purpose: understand what is happening, name the concern, agree what improvement looks like, offer support.

Outcome: documented (manager's record only), clear actions, follow-up date set.

Stage 2 - Follow-Up Conversations

Triggered by: stage 1 conversation has not produced sufficient improvement within the agreed timeframe.

Purpose: review progress, name specifically what has and has not changed, be clearer about the expectation and the consequence of continued underperformance.

Outcome: documented, updated actions, shorter review period.

Stage 3 - Informal Performance Support Plan

Triggered by: two or three conversations have not produced sufficient change, or the gap is more serious than initially assessed.

Purpose: set specific, written expectations for a defined period, with structured support and checkpoints. This is not a formal HR process but is more structured than a conversation.

Outcome: written document shared with HR awareness, regular checkpoint schedule.

Stage 4 - Formal PIP

Triggered by: informal support has not produced required improvement, or the performance gap is serious enough to warrant skipping earlier stages.

Purpose: formal improvement process with clear criteria, timelines, and consequences.

Outcome: full HR involvement, formal documentation, defined consequence.

The principle throughout is proportionality - the intervention should match the severity and persistence of the concern. Jumping immediately to a formal process for a first instance of concern is disproportionate. Staying at informal conversation for six months when the concern is serious is avoidance.

Protecting the Team

Underperformance that is not addressed has costs beyond the individual. The team observes it, interprets it, and responds to it - and not in ways that are good for cohesion, delivery, or morale.

The Cost of Tolerating Underperformance

Morale impact. The team members who are performing well observe that underperformance has no consequences. They draw conclusions about what the manager values, what the team standards are, and whether performance matters. Some will reduce their own effort to match the de facto standard. Others will become resentful.

Delivery impact. In a team context, underperformance rarely stays contained to the individual. Work comes back, deadlines slip, other team members carry more load, technical quality problems created by one person's work become the next person's problem to solve.

Trust impact. When the manager finally does address the underperformance - often through a formal process that arrives as a surprise to everyone - the team loses confidence in the manager's judgement. "Why did it take this long?" is the most common reaction. "What else is being tolerated that we don't know about?" is the second.

Balancing Individual Fairness With Team Impact

The individual has a right to be treated fairly - to receive specific feedback, to be given support, to have time to improve. This is non-negotiable. At the same time, the team has a right to standards being maintained and to not carrying an unfair burden because a performance problem is being managed slowly.

The balance is struck by moving at the appropriate pace - neither so fast that the individual has no genuine opportunity to improve, nor so slow that the team pays a prolonged cost for the manager's discomfort with directness.

Common Failures

Avoiding the Conversation Until It Is Too Late

The most common failure. By the time the manager has decided they have to say something, the performance has often been below standard for six months or more. The first honest conversation arrives simultaneously with the formal process, the engineer is blindsided, and the subsequent process is tainted by the manager's prior avoidance.

Being Vague to Be Kind

"I just want to say I've noticed your impact could be stronger in some areas." This is not feedback. It is vagueness deployed as kindness. The engineer leaves not knowing what "stronger impact" means, what areas, or what they should do differently. The manager has had a conversation that felt like a performance conversation and produced none of the benefits of one.

If there is something to say, say it specifically. "Your code review feedback has been consistently superficial - you're approving PRs with significant issues without raising them. In the last three PRs, issues that would have affected production were missed at your review stage." That is a manageable, actionable piece of feedback. The vague version is not.

Confusing Activity With Performance

The engineer who works long hours, who is always visible, who appears busy - but whose actual delivery and quality does not meet expectations - is underperforming. Activity and performance are not the same. A manager who assesses performance on the basis of visible effort rather than outcomes will systematically misidentify underperformance and over-reward busyness.

Making It Personal

"You just don't seem to care about quality." "I don't think this role is right for you." "Your attitude to feedback is a problem."

These are character and attitude assessments, not performance observations. They invite defensiveness, they are not actionable, and they damage the relationship without producing any useful information. Performance conversations must be about observable behaviours and their impacts, not about who the person is.

The Indefinitely Deferred Consequence

Some managers name performance concerns repeatedly over a long period, without ever being clear that continued underperformance will have consequences. The engineer learns that the performance conversation is a ritual - that it arrives, produces some discussion, and then nothing structurally changes. This communicates that the standard is actually lower than stated, that the consequence is not real, and that the conversations are noise.

If a consequence has been named and the required improvement has not followed, the consequence must be enacted. A consequence that is repeatedly threatened but never enacted teaches the organisation that threats are not real.

Connection to Your Operating Model

Addressing underperformance effectively depends on the surrounding system:

Clear role expectations and a capability framework. Underperformance can only be named clearly against a clear standard. If the expectations of the role are not defined, the performance gap cannot be objectively assessed. The capability framework and role archetypes provide the standard.

A functioning feedback culture. Underperformance conversations arrive less as a shock when feedback has been flowing regularly. An engineer who has been receiving specific, regular feedback from their manager and peers is unlikely to be surprised by a performance concern - they have been hearing the signal throughout.

Manager capability. Having early performance conversations requires skill that must be developed explicitly. If managers are not supported in developing this skill - through training, coaching, and access to HR guidance - they will default to avoidance.

HR as a partner, not a last resort. HR should be involved early in performance concerns as a resource, not only when a formal process is inevitable. Early HR involvement helps managers calibrate their approach, understand the process, and avoid the procedural errors that make formal processes more difficult.

Psychological safety. The engineer who feels safe enough to raise their own struggles - "I'm finding this harder than I expected, I could use some support" - is an engineer whose underperformance can be addressed earlier and more collaboratively. Psychological safety does not mean performance has no consequences. It means that the conversation about performance can happen honestly, in both directions.

This section connects directly to: Modern Performance Management, Feedback Systems, PDPs and PIPs, Talent Reviews and Calibration, and the Career and Capability framework.

The Early Conversation in Detail

The early performance conversation is described in outline above. The following provides greater specificity for managers who have not had this conversation before and need more detailed guidance.

Before the Conversation

Be clear on what you have observed. Write down three to five specific examples. Not impressions - examples. "Sprint 14: the authentication PR was returned with 11 significant issues after review. Sprint 15: the data layer story was carried over because it was incomplete at sprint end. Sprint 16: the API contract PR was merged without the integration tests that were discussed in the planning session." This specificity is essential. Generalisations invite dispute. Specifics invite reflection.

Be clear on what you need to see change. Before you can name the expectation, you need to know what it is. "PR quality that does not require more than minor corrections at review stage" is an expectation. "Better code" is not. The cleaner your expectation, the more useful the conversation.

Check your own contribution. Have you given enough context? Have expectations been clear? Have you provided the development support that would have enabled better performance? If your answers reveal that you have contributed to the situation, say so in the conversation. Acknowledging your own contribution is not weakness - it is accuracy, and it changes the character of the conversation from "here is what you are doing wrong" to "here is a situation we need to address together."

Decide on the outcome you want. The outcome of the early conversation should be: shared understanding of the concern, clear expectations, agreed support, a follow-up date. Not a formal process, not a judgement, not a threat. If you find yourself planning an outcome that involves consequences or formal process, you may be past the early conversation stage.

During the Conversation

The conversation should be held in private, with enough time protected (30-45 minutes), and without other agenda items competing for attention. It should not be sprung on the engineer at the end of a regular 1:1 without warning.

Opening: "I wanted to have a specific conversation with you about some things I've been observing. I want to be direct with you because I think that's more respectful than being vague, and I want us to figure this out together."

State the observations: Present your specific examples. Give them time to absorb each one before moving to the next. "In sprint 14, the authentication PR was returned with eleven significant issues after review. In sprint 15, the data layer story carried over. In sprint 16, the API contract merged without the integration tests that were discussed in planning. I've been noticing this pattern across three consecutive sprints now."

Invite their perspective: "What's your read on this? What has been getting in the way?" Stop talking. Listen to the answer. The answer may contain information you do not have. Do not use this as an opportunity to rebut - use it as an opportunity to understand.

Acknowledge any system factors they raise: If they identify blockers, unclear requirements, or team dynamics factors that have contributed, acknowledge them. "That's helpful to understand. Let me make sure I address the unclear requirements issue - that's on me. I also want to be clear that the pattern I'm describing is still something I need us to address, regardless of the contributing factors."

State the expectation: "What I need to see over the next four weeks is [specific, observable standard]. I want PRs that come back with minor corrections only. I want sprint commitments met or exceptions flagged in advance. That is the standard I need you working toward."

Offer support: "What would help you get there? I want to make sure you have what you need. I'm available for a brief code review session before you submit PRs if that would help - let's try that for the next three sprints."

Agree the follow-up: "Let's meet in four weeks and talk through how this has gone. I'll put it in the diary."

Closing: "I want to be clear - I'm having this conversation because I want you to succeed in this role. This is not a threat and it is not the start of a formal process. It is me being straight with you because that is more useful than not saying anything."

After the Conversation

Write a brief note within 24 hours: date, what was discussed, what was agreed, the follow-up date. Store it somewhere you can retrieve it. If the situation escalates to a formal process months later, this note is the evidence that the early conversation happened.

Check in informally within a week. Not a formal review - just "how are you getting on?" The signal that you are paying attention, without making every interaction feel like surveillance.

Specific Underperformance Scenarios

The Previously Strong Engineer Who Has Declined

An engineer who was performing well and has declined is a different situation from an engineer who has never met expectations. The decline has a cause. The most common causes:

Role scope has grown beyond current capability. The engineer was strong at level 2 and has been promoted to level 3, but has not yet developed the capabilities the new level requires. This is a development gap, not a performance failure.

Motivation has declined. The work has become repetitive, the challenge has been insufficient, the relationship with management has deteriorated, or something outside work is affecting engagement.

Health or personal circumstances. Not a performance issue - a human circumstance that requires empathy and appropriate support.

Team dynamics have changed. A new team member, a reorganisation, or a change in working relationship has affected the engineer's ability to perform effectively.

The manager who treats all of these the same way - as a performance issue requiring a performance conversation - will be ineffective in most cases and actively harmful in some. The inquiry before the intervention is essential: what has changed, and why?

The Engineer Who Does Not Know They Are Underperforming

Some engineers are genuinely surprised by performance feedback. This is always a sign that the feedback system has not been working. The engineer's surprise is information about the quality of previous feedback.

The conversation with this engineer should acknowledge the gap: "I want to take some responsibility for the fact that you may not have seen this coming. I should have been more direct with you earlier. Here is what I'm observing now..."

This acknowledgement does not remove the engineer's responsibility for their performance. It does make the conversation more honest and less adversarial.

The Engineer Who Disputes the Assessment

Some engineers will dispute the performance assessment. They may argue that the examples are unrepresentative, that the expectations were not clear, that the manager is applying the wrong standard, or that external factors explain the pattern.

The manager's approach:

Take the dispute seriously. The engineer may have valid points. If they can demonstrate that your examples are genuinely unrepresentative, update your assessment.

Separate valid context from deflection. "The requirements were unclear" may be valid context. "The requirements were unclear so I can't be held responsible for the quality of what I delivered" is deflection. Both can be true simultaneously.

Do not be argued out of an accurate observation. If you have three specific examples of a pattern and the engineer disputes one, you still have two. A pattern does not require every example to be unimpeachable.

Name what you are seeing. "I hear that you see this differently. I want to be clear that I'm not asking you to agree with my interpretation. I am asking you to take the feedback seriously and engage with what I need to see change."

Reference: Underperformance Conversation Preparation Checklist

Before having any early performance conversation, complete this checklist:

Observations:

• I have at least three specific examples with dates, contexts, and observable behaviours
• My examples cover a pattern over time, not a single incident
• I can describe the impact of each example on the team, product, or quality

System check:

• I have considered whether unclear expectations have contributed
• I have considered whether workload or cognitive load is a factor
• I have considered whether team dynamics or onboarding have contributed
• I have considered whether this might be disengagement or burnout rather than performance

Expectations:

• I can state clearly and specifically what improvement looks like
• I can describe how we will assess whether improvement has happened
• I have a realistic timeframe in mind (not less than four weeks)

Support:

• I can offer at least one specific form of support - not generic "let me know if you need anything"
• I have considered what I need to do differently as manager to enable improvement

Process:

• I know the follow-up date before I have the conversation
• I have time to document the conversation within 24 hours
• I have spoken to HR if the situation is already beyond informal conversation

A manager who cannot complete this checklist is not ready to have the conversation. Preparation is not optional - an unprepared performance conversation is more likely to damage the relationship and produce defensiveness than to generate improvement.

Reference: What to Document and When

The documentation question makes many managers uncomfortable. It feels bureaucratic, or like building a case against someone. Done correctly, documentation is neither of those things. It is a record that protects the engineer (by ensuring their progress is tracked accurately) and the manager (by ensuring that conversations that happened are not later disputed).

What to Document

After every early performance conversation: Date, what was observed (specific examples), what was discussed, what expectations were set, what support was offered, what the follow-up date is. Four to six sentences is sufficient. This is a manager's personal record - it does not need to be shared unless the situation escalates.

After every PIP checkpoint: What was the specific assessment against each success criterion. What progress has been made. What has not improved. What the manager said and what the engineer said. Next steps. This is shared with HR.

When a positive performance trend is observed: Documentation is not only for problems. If an engineer who was struggling has made genuine progress, documenting that progress protects them from having the earlier difficulties unfairly weighted against them in future conversations.

What Not to Document

Character assessments, opinions about motivation, and interpretations of intent should not be documented. "She seems disengaged" is a subjective impression that could be read as evidence of bias. "She has not raised any new ideas in the last six planning sessions and has declined two pairing invitations" is observable behaviour that can be discussed with the engineer and addressed.

The test for documentation: would I be comfortable if this engineer read what I have written? If not, rewrite it until the answer is yes. The documentation should be something you could show to the engineer as an accurate record of the conversation and its context.

How Long to Retain Records

Documentation of performance conversations should be retained for at least two years. In the event of a formal employment dispute, records from earlier in the employment relationship may be relevant. Check your organisation's HR policy for the specific requirement, but err on the side of retention for significant conversations.