Turning Struggle into Structure: How to Set the Right PIP Goals for Junior Engineers

Here’s a situation no manager wants to face - a junior engineer, about two years in, is falling short. Not disastrously. But deadlines slip. Reviews feel surface-level. Communication gets vague. You start wondering: Are they in the wrong role? Did I miss a coaching window? Can this still be turned around?

That’s where a Performance Improvement Plan (PIP) comes in. Not as punishment. Not as paperwork. But as a structured reset - a way to draw a line, define expectations, and give someone a fair shot at growth with guardrails and support.

Borrowing from recent research, field-tested management frameworks, and industry practices at companies like GitLab, Microsoft, and Meta, this post covers:

What makes a PIP fair, effective, and legally sound.
Why junior engineers need a different approach than senior staff.
Concrete goal-setting strategies that won’t backfire or overwhelm.
Real-world insights and data on what actually works - and what to avoid.

If you’ve ever wondered how to use a PIP as a real growth tool - not just an exit formality - you’re in the right place. Let’s start with why this question matters more than most people think.

TL;DR

Performance Improvement Plans (PIPs) for junior engineers can be either a humane reset or a slow-motion exit, depending on how they’re designed and implemented. This guide walks through the full decision process so that, by the time you write actual goals, they’re fair, realistic, and backed by evidence - not vibes.

Define what a PIP is and when it’s the right tool.
Treat junior engineers as early-career, not failed seniors.
Diagnose gaps (skills, behavior, or context) before writing goals.
Pair goals with support, cadence, and clear outcomes.
Ground your approach in research and real-world experience, not templates.

What a PIP Is (and Isn’t)

A Performance Improvement Plan is a time-boxed, written agreement between an employer and an employee that spells out three things:

The specific performance gaps that are unacceptable.
The concrete goals that would count as improvement.
The support, timelines, and possible outcomes at the end of the period.

When done well, a PIP is a structured reset. It gives clarity to both sides, documents expectations, and creates a shared reference point. Liane Davey’s work on PIPs in Harvard Business Review emphasizes that they should be used as a genuine coaching tool in situations where performance gaps are real but improvement is plausible, and where the employee understands and agrees with the issues being addressed.

That’s the ideal. In practice, many organizations use PIPs very differently.

Organizational psychologist Karlyn Borysenko reports that veteran employment attorney Alan Sklover estimated 95% of PIPs he sees are used as “paper trail” documentation to justify a firing, not to help someone actually improve. Mary Corrado’s analysis for the American Society of Employers similarly notes that many employees experience PIPs as a “setup for inevitable failure,” not a fair second chance.

So we need to hold both realities at once:

A PIP can be a developmental tool.
A PIP is often perceived as pre-termination formality.

The rest of this article assumes you want to use PIPs in the former sense. To do that, you first have to understand the specific situation of junior engineers.

Why PIPs for Junior Engineers Are a Special Case

A junior engineer with two years of experience is still on a steep learning curve. They’re often dealing with their first large codebase, first production incidents, and first time working with a multi-disciplinary team spread across time zones. They are not “mini seniors” who simply failed to meet a fully-formed bar.

That matters because expectations differ by level. A senior engineer might be expected to independently design systems, manage stakeholders, and lead cross-team projects. A junior is expected to:

Deliver well-scoped tasks with support.
Build reliable habits around communication and collaboration.
Learn from feedback and improve over time.

Camille Fournier, in The Manager’s Path, warns that PIPs should never be used casually or as a generic template. She argues that managers need clear written expectations and timelines, but also stresses: “Don’t put anyone on a plan whom you wouldn’t be happy to lose.” For a junior engineer, that raises an uncomfortable but important question: are you using the PIP as a true development plan, or as a formality before exit?

If you write a PIP for a junior engineer that would just as easily fit a staff engineer - full feature ownership, complex architectural work, autonomous cross-team leadership - you’ve silently re-leveled them. The plan is likely to fail, and the failure is on the plan, not the person.

Understanding why junior performance is different sets up the next question: what is this particular PIP for?

Clarifying the Purpose of the PIP: Rescue, Reset, or Exit?

Before drafting a single line of goals, a manager needs to answer a blunt question:

Are we trying to rescue, reset, or exit this engineer?

Those three purposes are very different.

Rescue means you genuinely believe the engineer can perform at the required level with focused help. The plan is an intensive coaching container.
Reset means expectations have drifted or were never clearly articulated. The plan formalises norms, timelines, and consequences after a long period of fuzziness.
Exit path means you see low likelihood of long-term success, but the organisation must still act fairly and transparently.

This is not a purely philosophical distinction. It shapes the design of the plan. Liane Davey, writing in Harvard Business Review, argues that PIPs should only be used when there is a credible path to improvement and the employee can agree on both the gaps and the goals. If you treat an almost-certain exit as a “coaching plan,” your goals will either be impossibly strict or quietly dishonest.

At the other extreme, Patty McCord’s experience at Netflix led her to scrap PIPs entirely; she describes them as “fundamentally dishonest” and a “slow-moving car crash” where everyone knows the outcome but prolongs the pain. Netflix’s alternative is to be candid about fit and, where necessary, provide generous severance instead of a protracted performance ritual.

Where you place yourself between Davey’s constructive PIP and McCord’s no-PIP philosophy will influence your goals. This article assumes you are closer to Davey’s position: if you choose to use a PIP, you intend it as a good-faith attempt at improvement, not a legal formality.

Establishing Baseline Expectations for a 2-Year Junior Engineer

You can’t talk about “improvement” if you don’t define what “good enough” looks like in the first place.

A clear, level-appropriate baseline might include:

Code quality and independence: Can the engineer complete small to medium tickets with review-level support, not constant hand-holding?
System and debugging fundamentals: Do they understand the main components of the system and basic debugging flows?
Reliability and communication: Do they show up to standups, flag blockers early, follow through on commitments, and respond reasonably quickly?
Collaboration: Do they participate in code reviews, ask for help when needed, and work constructively with peers?

These baselines are not about being brilliant; they’re about being trusted. When those fundamentals are unstable, teammates feel the drag. Research summarized in Crucial Conversations shows that having just “one or two” underperformers on a team can drag overall results down by up to 24%. That’s why ignoring junior underperformance isn’t just unfair to the individual - it’s unfair to the team.

At the same time, many juniors are never told explicitly what “good” looks like. Their first feedback is often negative, and it arrives late. Fournier stresses that you should always have a written record of feedback and expectations before a formal PIP is even considered. Without that, you’re asking someone to hit a moving target.

Once your baseline is explicit, you can use it as the reference point for diagnosing what’s actually going wrong.

Diagnosing the Performance Gaps: Skill, Behavior, or Context?

If you skip diagnosis and go straight to goals, you end up with vague instructions like “be more proactive” or “write better code.” Those are feelings, not diagnoses.

In practice, most junior performance issues fall into three overlapping buckets:

Skill gaps – The engineer lacks certain technical skills or experience. Examples include weak debugging, difficulty working in the codebase, or slow implementation due to unfamiliar patterns.
Behavioral gaps – The skills are present but aren’t applied consistently. Patterns include missed deadlines, not flagging blockers, defensive responses to feedback, or inconsistent communication.
Context/system gaps – The environment makes success hard. Onboarding was rushed, documentation is incomplete, the team is chronically overloaded, or the engineer is isolated on a remote team without effective support.

Karlyn Borysenko’s critique of PIPs emphasizes that managers often jump to formal plans instead of addressing these underlying causes, using PIPs as a “fix” when the real issues are leadership, training, or structure. Similarly, Engagedly’s analysis suggests that reactive PIPs - only triggered when things “hit rock bottom” - are far less effective than earlier interventions structured around continuous feedback and coaching.

For a junior engineer, a skill gap might be solvable with targeted training and pairing. A behavioral gap might respond to clear expectations and fast feedback. A context gap might require changes in how work is assigned or how the team supports remote staff.

The diagnosis determines the kind of goals that make sense. That’s why the next step is gathering evidence carefully instead of relying on vague impressions.

Gathering Evidence and Avoiding Bias

Performance conversations are emotionally loaded for everyone involved. Without evidence, managers tend to over-index on recent incidents, personal chemistry, or communication style.

A fair PIP rests on patterns, not anecdotes. Before drafting goals, collect:

Specific examples: PRs that required multiple reworks, incident tickets where handoffs broke down, missed release milestones, or repeated last-minute surprises.
Time patterns: How long has this been happening? Did performance dip after a context change, such as a team switch or remote transition?
Multiple perspectives: Peer feedback, tech lead observations, and, where appropriate, product or QA input.

This also means watching for bias. Crucial Conversations research highlights that only ~1% of employees feel “extremely confident” speaking up about serious concerns at work. If you’re managing someone from a different cultural background or whose communication style is more reserved, their silence may be self-protection, not disengagement.

Patty McCord’s critique of PIPs at Netflix adds a strong ethical dimension here. She calls traditional plans “fundamentally dishonest” because they rarely accomplish what they claim and instead prolong an outcome everyone can see coming. If your evidence doesn’t actually support a realistic path to success, using a PIP as a scripted performance is worse than being candid about separation.

Good evidence doesn’t just protect the company; it protects the engineer from arbitrary or biased expectations. Once you have it, you must still remember you’re working with a human being under pressure.

The Emotional and Psychological Weight of a PIP

For a junior engineer, being told they’re going on a PIP is often the most frightening moment of their career so far. Many will interpret it as “I’m about to be fired,” not “I’m being given a structured chance.”

Engagedly notes that employees - especially high performers - often disengage quickly after receiving a PIP, updating their résumé and mentally checking out within weeks. When the plan feels like a verdict rather than a possibility, motivation collapses.

This psychological load affects behavior:

Risk-taking drops. People avoid complex or ambiguous tasks for fear of failure.
Learning slows. They may stop asking questions to avoid “looking weak.”
Communication becomes guarded. They say less, and you learn less about what’s really blocking them.

The Crucial Conversations work is useful here: it shows how unspoken fear and silence corrode team performance, and how the failure to have honest, safe conversations leads to lasting damage. The same dynamic plays out inside a PIP if you don’t explicitly address the emotional reality.

For a junior engineer, setting a goal like “Own a production-critical feature end-to-end in 60 days” may look impressive on paper but be psychologically impossible. A better starting point in a PIP context might be “Independently deliver one well-scoped change with documented design and proactive check-ins.” Ambitious but believable.

If you want the plan to work, you must treat emotional safety as a first-class constraint alongside technical scope. That leads naturally to the question: what is your role as a manager inside this process?

The Manager’s Responsibilities During a PIP

A PIP is not an exam the engineer takes in isolation. It is a joint project, and the manager owns the structure.

At a minimum, your responsibilities include:

Holding regular, focused 1:1s to discuss progress, obstacles, and support.
Removing unnecessary ambiguity from tasks and expectations.
Coordinating mentors, reviewers, and pairing opportunities.
Documenting both the support you provide and the employee’s responses.

GitLab’s public handbook is explicit about this: “Taking early action to address underperformance is an essential manager skill… the expectation is that all team members are provided coaching and feedback prior to a decision to exit.” The company treats coaching as the default first step; PIPs or written performance letters are used later and often required by local law, not as a casual managerial shortcut.

Andrew Grove, in High Output Management, frames managerial interventions like training as high-leverage activities: if training 10 employees for 12 hours increases their output by just 1%, that translates to 200 extra hours of productive work per year. That same logic applies here: time you put into focused coaching and clarification during a PIP can yield disproportionate gains, especially with juniors who are still forming habits.

A PIP where the manager simply writes goals and then “waits for the result” is at best lazy and at worst negligent. Your involvement is part of the plan’s design, not an optional add-on.

That managerial obligation sits alongside legal and fairness constraints you cannot ignore.

Legal, HR, and Fairness Constraints (Briefly)

This article is not a legal guide, but ignoring the HR dimension would be naive.

Mary Corrado’s 2024 report for the American Society of Employers points out that documented performance procedures, including PIPs, rose from 33.4 per 1,000 employees in 2020 to 43.6 per 1,000 in 2023. That uptick reflects organizations tightening processes, often under pressure to demonstrate fairness and consistency.

Three implications follow:

Consistency matters. You can’t create radically different PIPs for employees with similar issues without being able to explain why.
Objectivity matters. Goals like “stop being negative” or “show more passion” are not observable in a defensible way. Goals rooted in behaviors and outputs are safer.
Documentation matters. As Fournier emphasizes, formal PIPs should be preceded by clear written feedback; otherwise they look like retroactive justification.

Some companies, taking a cue from Patty McCord’s experience at Netflix, choose to bypass PIPs entirely for certain situations, offering generous severance and candid conversations rather than prolonged formal plans. Her critique is blunt: she calls PIPs “fundamentally dishonest” and likens drawn-out processes to a “slow-moving car crash” where no-one benefits in the end.

Whether your organization uses PIPs or alternatives, the legal and ethical bar is the same: treat people consistently, base decisions on evidence, and avoid hiding behind process.

With that foundation in place, you can finally talk about the principles of good PIP goals.

Principles of Good PIP Goals (Before We Talk Specifics)

Only now are we ready to talk about the shape of good goals.

Most frameworks converge on a few shared properties. Effective PIP goals for a two-year junior engineer are:

Small in number: Three to five serious goals are easier to execute and measure than a list of fifteen.
Observable and verifiable: Anyone familiar with the work should be able to tell whether the goal was met.
Time-bound but realistic: A 30–90 day window must account for learning time, not just output.
Directly tied to diagnosed gaps and baseline expectations: Every goal answers, “Which gap is this addressing?”
Paired with support: For each goal, there is a named manager commitment or resource.

The popular SMART acronym (Specific, Measurable, Achievable, Relevant, Time-bound) still applies, but on its own it is too generic. Grove’s systems view and Fournier’s emphasis on “no surprises” add nuance: goals must sit within a broader management system where expectations and feedback have been present all along (Grove | Fournier).

If you jump directly into examples like “Ship 2–3 features end-to-end per month” without this framing, readers will copy and paste them into situations where they don’t fit. The principles ensure that whatever examples you choose are adapted, not transplanted.

Choosing the Scope: What Not to Put in the PIP

It is tempting, once you start listing goals, to add everything that has ever annoyed you about this engineer. That impulse produces unworkable PIPs.

Corrado notes that some organisations respond to performance concerns with increasingly heavy formal processes, which employees then experience as “setups for inevitable failure.” One way that shows up is in overloaded plans: ten or more goals, conflicting priorities, and vague personality targets alongside substantive performance work.

For a junior engineer, a scoped PIP should not include:

Every minor quirk or preference mismatch.
Goals that depend heavily on others’ behaviour (“be liked by the team”).
Sweeping character judgments (“show more passion”, “be more positive”).

Borysenko’s critique is useful here: if PIPs are perceived as tools to document failure rather than enable success, employees will disengage or resign rather than meaningfully attempt the plan. By focusing on a few leverage points - say, estimation reliability, basic testing discipline, and proactive communication - you increase the odds of visible improvement that matters.

Scope is an ethical choice. For a two-year engineer, humane focus is part of fairness.

Integrating Support: Mentorship, Pairing, and Training

A PIP that lists outcomes but not support is essentially a test. For a junior engineer, that’s rarely fair and often counter-productive.

The research on training and coaching suggests that relatively modest investments of focused support can yield meaningful gains. Grove’s training example in High Output Management - 12 hours of training leading to a 1% productivity lift, or 200 extra hours of output per year across 10 employees - illustrates the leverage managers have when they invest in capability building.

Support can take multiple forms:

Mentorship: Assign a clear go-to senior engineer for technical questions and design reviews.
Pairing: Schedule regular pairing sessions on representative work, especially early in the PIP.
Resources: Point to specific documentation, courses, or labs relevant to the gaps.
Process clarity: Ensure the engineer knows how to get help quickly when blocked.

Engagedly’s work on alternatives to PIPs shows that organizations adopting continuous, coaching-centric approaches - where feedback and support are built into normal operations - see 26% improvements in performance and higher engagement, compared to reactive, plan-only models. Adobe’s well-known move to frequent “check-in” conversations led to about a 30% decrease in voluntary attrition.

In practice, this means your PIP should read less like:

“Deliver X, Y, Z or you’re out.”

and more like:

“Here are the core gaps. Here are the specific goals. Here is exactly how we’ll support you over the next 60 days.”

Once support is defined, you still need a cadence and feedback loop to make it real.

Defining Review Cadence and Feedback Loops

A PIP without regular check-ins is a “see you in 60 days” trap. That is bad management and bad process.

A reasonable cadence for a junior engineer might be:

Weekly 1:1s focused on PIP goals.
Mid-point review at 30 or 45 days, depending on plan length.
Ad-hoc check-ins when major milestones complete or new blockers appear.

Evidence from performance management experiments shows that frequent, structured conversations significantly improve both engagement and retention. Organizations that replaced annual reviews and reactive PIPs with continuous feedback saw 40% higher engagement and notable drops in turnover (Abhishek).

This cadence isn’t just for tracking; it’s for adjusting. If it becomes clear that a goal was mis-scoped - too easy or too hard - you can formally revise it, documenting why. That’s better than silently watching a plan you know is broken.

For a junior engineer who is already anxious, these regular touchpoints also serve as emotional stabilizers. They signal that you are paying attention, that improvement is visible, and that feedback is not reserved for the final verdict.

Once cadence is defined, you need to decide what, concretely, you’ll call “success” at the end.

Success and Failure Criteria: What Happens at the End?

A PIP is time-bound. At the end of that time, you owe the engineer a clear, honest outcome. Vague endings are demoralizing and legally risky.

Broadly, you’ll see three types of outcomes:

Success: The engineer met the key goals, and you have renewed confidence in their ability to perform at their level. The PIP closes, and they return to normal performance management, ideally with some ongoing coaching.
Partial success: Some improvement is clear, but not enough. You might extend the plan with narrowed scope, or consider role adjustments.
Failure: Core goals were not met despite support and clear expectations. At this point, most organizations move to exit or, in rare cases, redeploy to a significantly different role.

The data suggests that many PIPs end in the third category. Engagedly reports that 59% of employees on PIPs do not successfully remain in their roles, while a specific HBR case study showed only 15% of PIP’d employees at one firm improved enough to keep their jobs.

Patty McCord’s Netflix experience led her to bypass PIPs in many cases, opting instead for candid conversations and severance when she believed the probability of real improvement was low. Her argument is that it is kinder, faster, and more honest for everyone involved.

For junior engineers, you may be more willing to invest in partial success and extensions, especially if the trajectory is clearly upward and the gaps are skill-based. But even then, the key is transparency: the engineer should never be guessing which outcome you think is likely.

With outcomes defined, you can place the PIP in the broader context of career progression.

How PIPs Intersect with Career Progression and Leveling

For many juniors, a PIP feels like a permanent stain on their record. Managers can unintentionally reinforce this by treating PIPs as an irreversible label rather than a checkpoint.

In a well-designed system, the PIP should connect directly to your career rubric:

If your ladder expects L2 engineers to independently deliver small features, participate in code reviews, and reliably communicate status, your PIP goals should target exactly those capabilities.
Successful completion of the plan should return the engineer to a clear growth path, even if promotion timelines are reset or delayed.

The alternative - treating PIPs as a mysterious side-channel that doesn’t integrate with leveling - creates mistrust. Employees don’t know what bar they’re being held to, or how to recover.

The continuous feedback approaches highlighted by Engagedly and others are useful here: they normalize the idea that performance dips and course corrections are part of a career, not a unique shame event. Nearly everyone hits a rough patch at some point; what matters is how transparent, fair, and supportive the response is.

If you frame PIPs as explicit checkpoints tied to documented expectations, junior engineers can see them as tough but understandable steps - not as random punishment.

Of course, all of this can still go wrong in predictable ways.

Common Anti-Patterns: How PIPs Go Wrong

By now, a pattern should be clear: it is easy to misuse PIPs.

Several anti-patterns show up repeatedly in the literature and in practice:

The ambush PIP: Months or years of vague praise, then a sudden formal plan. This violates the “no surprises” principle and destroys trust (Fournier, 2017, keyvanakbary.github.io).
The impossible exam: Goals that a strong engineer at the next level would struggle to hit in the timeframe. Common for juniors when managers paste in senior-level expectations.
The personality plan: Goals like “be more positive” or “show more passion” without any link to observable behaviour or outcomes. These are almost impossible to evaluate fairly.
The paper-trail plan: A PIP used purely to satisfy internal process on the way to a decision already made.
The support-less plan: Goals without mentoring, training, or extra feedback. In these cases, success depends on the engineer fixing everything alone, under maximum stress.

Abhishek notes that when employees see a PIP as a sign that leadership has already given up, many “mentally check out” almost immediately, updating their résumé and quietly leaving before the period ends. If you want a chance of a different outcome, you have to actively design against these anti-patterns.

So, What Goals Belong in a PIP for a Two-Year Junior Engineer?

With all that context in place, we can finally answer the headline question.

The “right” goals will depend on your diagnosis, but a well-constructed PIP for a two-year junior engineer will usually touch four areas: code quality, reliability and planning, communication, and learning/ownership. Here is how that can look in practice, assuming a 60-day plan.

Code Quality and Testing

“Over the next 60 days, for all new work, the engineer will write tests that cover the main happy path and one edge case, and will have no more than one high-severity defect per sprint attributable to missing tests.”

This goal is specific, observable, and directly addresses a common skill gap. Support might include pairing with a senior on test design and attending a short internal workshop on the team’s testing framework. Grove’s training leverage applies here: a modest investment can yield large gains in reliability.

Delivery Reliability and Estimation

“For the next three sprints, the engineer will commit to a small set of tickets agreed with the manager and will deliver at least 80% of those commitments on time, with any risk to delivery surfaced at least 24 hours before the deadline.”

This ties to baseline expectations about independence and reliability. The manager’s role includes helping break down work into manageable tasks and reviewing estimates in advance (Fournier).

Communication and Collaboration

“Before starting a new ticket, the engineer will summarise their understanding of the requirement in writing (e.g., in the ticket comments) and confirm it with the manager or product owner. They will provide daily stand-up updates including what they did yesterday, plan for today, and any blockers.”

This addresses behavioural gaps in clarity and visibility. It also connects to the Crucial Conversations insight that performance improves when people speak up early about problems rather than letting them fester.

System Understanding and Learning

“Within 30 days, the engineer will complete a guided walkthrough of subsystem X and produce a short internal note or diagram summarising how requests flow through it. Within 45 days, they will independently debug and resolve at least one non-trivial bug in that subsystem, with support available but not driving.”

This goal builds domain understanding and measured autonomy. It also signals that the organisation is investing in their growth rather than just their output.

Each of these goals should sit in a written plan alongside:

The specific evidence that prompted it.
The support the engineer will receive.
The cadence of check-ins.
The criteria for success at the end of the period.

Taken together, they sketch a PIP that is tough but fair, honest about the stakes but committed to giving a junior engineer a credible chance to succeed.

Closing

A well-designed PIP isn’t a shortcut, and it isn’t a verdict. It’s a moment of clarity: a chance to pause, define expectations, and invest deliberately in someone’s growth. For a junior engineer still shaping their habits and confidence, that moment can change everything.

Will the plan become a genuine reset, or just a slow confirmation of what everyone already suspects? That depends on whether the manager approaches it with honesty, preparation, and support. When we design PIPs with integrity - and show up consistently throughout the process - we give people a real chance to succeed. And even when the outcome is a transition, we can do it in a way that preserves fairness, dignity, and trust.