Free template for engineering managers
A performance improvement plan written to help someone succeed.
Pick what needs to change, from PRs that need rework to missed sprint commitments, and write a goal you can both measure and the support you'll give. You get a complete PIP with every check-in on a real working day, ready to review with HR, and the plan on a timeline you can download or keep in Forgot.
The plan runs
Oct 19 to Dec 18, 2026
45 working days, 10 meetings
- Mon, Oct 19Kickoff
- Mon, Oct 26Check-in
- Mon, Nov 2Check-in
- Mon, Nov 9Check-in
- Mon, Nov 16Midpoint
- Mon, Nov 23Check-in
- Mon, Nov 30Check-in
- Mon, Dec 7Check-in
- Mon, Dec 14Check-in
- Fri, Dec 18Final review
Performance improvement plan: Sam Lee
Employee: Sam Lee, Software Engineer II, Payments Manager: Dana Cho HR partner: [HR partner] Plan dates: Mon, Oct 19, 2026 to Fri, Dec 18, 2026 (60 days, 45 working days) Check-ins: every week, 30 minutes, 10 meetings including kickoff and final review
Why we're doing this
This plan sets out where Sam's work is not meeting the expectations for the role, what success looks like, and the support Sam will get. The goal is for Sam to succeed. Each area below has a specific example, a goal we can both measure, and what Dana and the team will do to help.
Areas to improve
1. PRs often need major rework
What we've seen: In the last six weeks, 5 of 8 PRs needed a second design pass after review. For example, [PR link] changed the data model after two rounds of review, which pushed [feature] back a week.
What success looks like by Dec 18: By the end of the plan, at least 4 of every 5 PRs merge after no more than one round of significant changes. For any change over about 300 lines, a short design note or a 20-minute walkthrough with a reviewer happens before coding starts.
Support: A weekly 30-minute pairing session with [senior engineer]. A one-page design note template. [Manager] reviews the first two design notes within one working day.
2. Misses sprint commitments without raising risk
What we've seen: In 3 of the last 4 sprints, committed tickets were not done and the first signal came at sprint review. For example, [ticket] was marked on track in standup until the last day of the sprint.
What success looks like by Dec 18: Raise any risk to a committed ticket in standup or the team channel as soon as it appears, and no later than the sprint midpoint. Finish at least 80% of committed points in each sprint of the plan, or have agreed changes to scope recorded in the ticket.
Support: Help breaking tickets into pieces of two days or less in planning. A mid-sprint check with [manager] each sprint. Fewer interrupts: [name] covers support questions during the plan.
Check-in schedule
| # | Date | Meeting | Focus |
|---|---|---|---|
| 1 | Mon, Oct 19, 2026 | Kickoff | Walk through the plan together. Agree what good looks like for each goal and answer questions. |
| 2 | Mon, Oct 26, 2026 | Check-in | Progress on each goal, with examples from the last period. What's helping and what's in the way. |
| 3 | Mon, Nov 2, 2026 | Check-in | Progress on each goal, with examples from the last period. What's helping and what's in the way. |
| 4 | Mon, Nov 9, 2026 | Check-in | Progress on each goal, with examples from the last period. What's helping and what's in the way. |
| 5 | Mon, Nov 16, 2026 | Midpoint review | Midpoint review: an honest read on each goal, written down and shared. Adjust support if needed. |
| 6 | Mon, Nov 23, 2026 | Check-in | Progress on each goal, with examples from the last period. What's helping and what's in the way. |
| 7 | Mon, Nov 30, 2026 | Check-in | Progress on each goal, with examples from the last period. What's helping and what's in the way. |
| 8 | Mon, Dec 7, 2026 | Check-in | Progress on each goal, with examples from the last period. What's helping and what's in the way. |
| 9 | Mon, Dec 14, 2026 | Check-in | Progress on each goal, with examples from the last period. What's helping and what's in the way. |
| 10 | Fri, Dec 18, 2026 | Final review | Final review: the outcome for each goal and the next step, with HR. |
How we'll track progress
- Dana writes short notes after each check-in and shares them with Sam the same day.
- Sam can add comments or disagree in writing at any time.
- We look at examples from both sides: what went well and what didn't.
- If a goal turns out to be unclear or out of reach for reasons outside anyone's control, we change it together and write down why.
Possible outcomes
- Goals met: the plan closes and normal 1:1s and reviews continue. We keep meeting on these areas for a while so the progress sticks.
- Clear progress, not all goals met: the plan may be extended once, for a set time, with the remaining goals.
- Goals not met: next steps are decided with HR and follow company policy. This can include a change of role or ending employment.
Acknowledgement
Signing confirms you received this plan and discussed it. It doesn't mean you agree with everything in it. You can add your comments below.
Employee: Sam Lee · Signature: ______________ · Date: ______
Manager: Dana Cho · Signature: ______________ · Date: ______
HR: [HR partner] · Signature: ______________ · Date: ______
Employee comments:
Copy pastes as formatted text into Google Docs, Notion or Confluence. Markdown is for GitHub, Jira or Slack.
Paste it into Google Docs, Notion or Confluence. Replace anything in [brackets], and go through it with HR before you share it.
4. The plan on a timeline
Kickoff, every check-in, the midpoint and the final review as key dates, with both of you and any time off. It follows the builder. Drag things around on it, then download it or keep it in Forgot.
- Check-ins need both of you: time off on one shows a warning
- Drag a key date or a bar to try another day
- PNG or PDF for the plan document or HR
- Open in Forgot, then Save as my board to keep it
What a PIP is, and what it's for.
A performance improvement plan is a written agreement that says where someone's work isn't meeting the expectations for their role, what good looks like, by when, and how you'll help. It usually runs 30, 60 or 90 days with regular check-ins.
A PIP has a bad reputation, and sometimes it's earned: at some companies it's paperwork before an exit. It doesn't have to be. A good plan is the clearest feedback someone will ever get: specific examples, a bar they can see, real support and a date. Many engineers come through one and do well. Write it as if you expect that outcome, because your expectation shows.
Try these first. A PIP should never be a surprise.
If the first time someone hears about a problem is the day you hand them a PIP, the process has already failed. Before you write one, check you've done these.
Clear feedback in 1:1s
Name the gap with examples, more than once, and write it down afterwards. Ask what's getting in the way. Many problems end here.
Written expectations
Show what good looks like at their level: your career ladder, an example of a strong PR or design doc, what 'done' means on your team.
Fix the environment
Unclear tickets, constant interrupts, a heavy on-call load or a bad project fit look like performance problems. So do health or family issues. Ask, and adjust.
An informal plan
A few weeks of agreed goals and weekly check-ins, without the formal process. It gives the same clarity with much less weight.
A formal PIP makes sense when the gap is clear and documented, feedback hasn't changed it, and the role needs it to change. Talk to HR before you start. They know your company's process and the rules where the person works, which differ a lot between countries. This page isn't legal advice.
Goals that are fair and measurable.
Every goal should pass four checks. Observable: you can both see whether it happened, without arguing about it. In their control: not dependent on another team shipping or a project getting staffed. Reachable in the time: a 30-day plan can't require a quarter of results. The same bar as peers: what you'd expect from anyone else at their level, not more.
- Improve code quality.At least 4 of every 5 PRs merge after no more than one round of significant changes.
- Be more proactive.Raise any risk to a committed ticket in standup by the sprint midpoint.
- Communicate better with product.Send a written update on [project] every Friday with progress, risks and decisions needed.
- Take on-call more seriously.Postmortem draft within five working days of each incident; no open action items older than two weeks.
- Review faster.First review on assigned PRs within one working day, checked weekly from GitHub data.
Two to four goals is plenty. More than that and the plan reads like a list of everything wrong, which makes it harder to succeed. For each one, write the support next to it: pairing with a senior engineer, a design-note template, protected time, fewer interrupts. Support is what makes the plan fair, so be specific and then actually provide it.
Running the check-ins, week by week.
- 1
Keep the kickoff about clarity
Walk through every goal and ask what's unclear. Agree how you'll measure each one. Tell them you want this to work, and mean it.
- 2
Meet on schedule, every time
Weekly or every two weeks, 30 minutes. A skipped check-in tells someone the plan doesn't matter, or that the outcome is already decided.
- 3
Bring examples, both ways
What went well since last time and what didn't, with PRs, tickets or incidents. Ask what's helping and what's in the way, and adjust support.
- 4
Write it down the same day
A few lines per goal, shared with them after each meeting. They should be able to add their view. Nobody should be surprised at the final review.
- 5
Be honest at the midpoint
Say clearly where each goal stands. If it's going well, say so. If it isn't, say that too, while there's still time to change it.
Plan check-ins around time off, before it moves them for you.
A 60-day plan crosses holidays, vacations and on-call weeks. If the person is out, pause the plan and move the end date, so they get the full time. If you're out, move the check-in rather than skip it. The builder above does both. The timeline above shows the conflicts before you pick the dates.
How a PIP ends: three outcomes.
Success
The goals are met. Close the plan in writing, say so plainly, and keep talking about these areas in 1:1s so the progress sticks. Treat them like anyone else on the team from here.
Extension
Clear progress, but not every goal is met. Extend once, for a set time, with only the remaining goals. An open-ended extension helps nobody.
Exit
The goals aren't met despite real support. Next steps, which can include a role change or ending employment, are decided with HR and follow company policy and local law.
Whatever the outcome, involve HR from the first draft to the final meeting. Keep your notes factual and dated. And look after the rest of the team: a PIP is confidential, so don't discuss it with anyone who doesn't need to know.
For the conversations around the plan, the 1:1 meeting template gives check-ins a shape, and performance review phrases for engineers help you describe the gaps and the progress in plain words.
Questions
What is a performance improvement plan?
A performance improvement plan (PIP) is a written plan that names where someone's work isn't meeting expectations, sets specific goals to reach in a fixed time, usually 30 to 90 days, and lists the support they'll get. Done well, its aim is to help the person succeed.
How do you write a PIP?
Name each gap with a specific, recent example. Turn each into a measurable goal the person can reach in the time, at the same bar as peers at their level. Write down the support you'll give, set a check-in schedule, and say what happens at the end. Review it with HR before you share it.
What should a performance improvement plan include?
The employee, manager and HR contact, the start and end dates, each area to improve with an example, a measurable goal and the support offered, the check-in schedule, how progress is tracked, the possible outcomes, and space for signatures and the employee's comments.
How long should a PIP be?
Long enough for real change to show. For engineers, 60 days is common: it covers several sprints and enough PRs, reviews or on-call shifts to judge. 30 days suits one narrow, frequent behavior, and 90 days suits larger goals. Check what your company's policy says.
Does a PIP mean you're getting fired?
Not necessarily. Some companies use PIPs as a formality before letting someone go, and some use them to help people recover, so outcomes vary a lot. A fair PIP has goals the person can actually reach, real support and regular honest check-ins. If you're on one, ask your manager and HR what success looks like.
Can a PIP be extended?
Often, yes. When someone has made clear progress but not met every goal, many companies allow one extension with the remaining goals and a new end date. Time off during the plan usually pauses it. Check with HR on your company's policy.