The first time you get a self-evaluation back from one of your direct reports, you will probably read it and feel a small amount of despair. It will be too long or too short. It will be vague where it needs to be specific. It will overclaim a project they had a small role in, or it will underclaim work that was genuinely impressive. It will not give you the thing you actually wanted, which is a clear, honest read on how this person sees their own year.
That is not because your direct reports are bad at writing. It is because nobody ever taught them how to write a self-evaluation that helps them and helps you at the same time. They learned it in a vacuum, copying the format from whoever was on their team last year, and then the format calcified.
This guide gives you five templates organized by career stage, with sample answers, common pitfalls, and a paragraph at the end of each one explaining what their manager (you) is actually trying to learn from it. Send the relevant template to each of your direct reports before review cycle starts. The reviews you get back will be dramatically more useful, and your conversations will be sharper because of it.
This article is one cluster under the Performance Management hub. The full operating manual for the review cycle itself lives in the complete guide to performance reviews for first-time managers, which covers the four systems that make reviews actually work. If you want phrases to use when writing your half of the review, the companion piece on 150 performance review phrases by competency is the other half of the toolkit.
Why most self-evaluations do not help anyone
A typical self-evaluation looks like this. The employee opens the form on a Sunday night. They scroll through the year in their email and Slack. They write a mix of recent wins, a paragraph about “areas for growth” that they hedge carefully so they do not look incompetent, and a closing line about “looking forward to next year.” Forty-five minutes, submit, done.
Now read it through their manager’s eyes. The manager already wrote a draft of the formal review. They are looking for one of two things from the self-evaluation: either a piece of context they did not have, or a signal about how this person sees themselves relative to the bar. The vague Sunday-night version gives them neither. The manager skims it, files it, and writes the review they already had in their head.
That is a failure mode for both sides. The employee spent 45 minutes on something that did not move their case. The manager lost their best chance to catch a blind spot in their own draft. Both walked away from the cycle worse off, and neither of them noticed.
A self-evaluation that works does three things, in this order.
- It reduces the chance of a surprise in the review meeting. If you write what you genuinely think about your year, your manager either agrees (and you avoid getting blindsided) or they disagree (and you find out before the meeting, when there is still time to discuss). The point of the document is not to lobby. It is to surface gaps in perception while there is still time to close them.
- It gives your manager raw material they could not produce themselves. Your manager has at most 30 to 50 percent visibility into your day-to-day. They cannot describe the calls you took with the customer at 8pm, the cross-team coordination that happened in DMs, or the moment you decided to escalate something they never saw. The self-evaluation is the only place that work surfaces. Use it for that, not for restating things they already know.
- It tells your manager what you want next. Almost no self-evaluations do this. The ones that do change conversations. A clear sentence about “I want to lead a feature end-to-end next quarter” or “I am ready to start managing one direct report” gives your manager something concrete to advocate for, both with you and with their boss. Without it, your career is steered by other people’s assumptions about what you want.
If you read those three goals back, you will notice that none of them are “list everything you did all year.” The self-evaluation is not a CV. It is a tool. Most people use it like a CV anyway, and the document does not work as a result.
The four things every self-evaluation needs
Before the templates, the structural skeleton. Whatever stage of career you are at, a useful self-evaluation has these four components in roughly equal weight. The templates flesh these out for each level.
1. Outcomes (what actually happened). Specific work, specific results. Not “led the migration.” Specifically: “Led the migration of 14 reports from the legacy system to the new dashboard. Hit the November 1 cutover. Zero rework requests in the first month.” Be willing to put numbers when you have them and avoid them when you do not. Made-up numbers are worse than no numbers.
2. Context (what shifted mid-cycle). The world rarely cooperates with a January goal. Document what changed: a project pivoted, a colleague went on leave, the customer killed a roadmap item. This is the place to surface things that affected your year that your manager may not have visibility into. Do not use it to make excuses. Use it to give an honest read on the conditions you were working in.
3. Self-awareness (what you would do differently). This is where most self-evaluations either go vague (“I want to communicate more proactively”) or go falsely modest (“I should be more confident”). Both fail. The version that works is concrete. “I waited too long to flag the security review risk on the Q3 launch. I knew in week two and brought it up in week six. Next time I will raise it in week three even if I do not have a full plan, because the plan can come together once the risk is on the table.” That is a specific behavior with a specific change. It is also the section where your manager will look hardest, because it is the strongest signal of whether you are growing.
4. Forward (what you want next). What is the role you are growing into? What stretch project would help you get there? What support do you need that you are not currently asking for? Be direct. The manager who is reading this is your single best ally for getting it. Do not make them guess.
If a self-evaluation has these four things, even briefly, it is doing its job. If it has only outcomes (the most common pattern), it is half the document.
Five templates follow. Each is structured around these four components, with stage-appropriate prompts and a sample answer that is realistic, not idealized.
Template 1: Early career, 0 to 3 years experience
Use this template if: You are in your first or second professional role, or you have been in your current company less than three years.
How long it should take: 60 to 90 minutes of focused writing. Your first one will take longer because you are building the habit.
Structure:
Section 1: What I worked on this cycle
List the three to five most significant things you contributed to. Do not try to list everything. Pick the work that mattered most or that you learned most from. For each, write two to three sentences: what you did, what changed because of it, what you learned.
Section 2: A specific moment I am proud of
Pick one thing. A presentation that landed, a customer ticket you resolved well, a moment you spoke up in a meeting and were right. Tell the story in 100 to 200 words. Be specific about what you did, not how it made you feel.
Section 3: A specific moment I would handle differently
Same format. Not “I want to be more confident.” Specifically: “When the senior engineer pushed back on my design in the review, I backed down too quickly. I had a real reason for the decision and did not say it. Next time I will say the reason and then ask for their pushback, instead of conceding first.”
Section 4: What I want to learn or do next cycle
Be concrete and ambitious without being unrealistic. “I want to take on a project that ships externally” or “I want to start contributing to design reviews even though they are above my level.” If you do not know yet, say that, and ask your manager for input.
Section 5: What I need from my manager
One specific thing. More 1-on-1 time. Faster feedback on PRs. An introduction to someone in another team. Concrete asks get answered. Vague asks get filed.
Sample answer (annotated):
Section 1: I worked on the customer dashboard redesign (shipped in March), the Q2 onboarding flow improvements (shipped in May), and the data export feature (shipped late, in July). On the dashboard, I owned the front-end and worked closely with Mei on the data layer. The biggest learning was that I underestimated the time the legacy CSS would take to untangle. On the onboarding work, I led the experiment design with Diego and we saw a 14 percent activation rate lift. On the data export, I made a call to use a third-party library that turned out to be wrong for our use case, and we had to rebuild it in week four.
Section 2: I am proud of the way I handled the customer ticket from the Acme account in April. The customer reported a sync issue that I traced to a config we had set incorrectly during onboarding. I rolled it back, wrote up what happened, sent the explanation to the customer myself instead of routing it through support, and the customer wrote back saying it was the most direct response they had gotten from any vendor that quarter. The piece I learned: writing the explanation in plain language and owning the mistake was more effective than trying to make it sound less bad.
Section 3: When the data export library turned out to be wrong, I should have flagged it earlier. I knew by Tuesday of week two that the library was struggling at our scale. I did not raise it until Friday of week three because I wanted to come with a fix. Next time I will raise the problem first, even if I do not have a fix, because the fix can come together faster with the team aware of the issue.
Section 4: I want to take on a project that ships to external customers end-to-end, including the customer-facing communication. I have done pieces of this but never the whole thing. I think I am ready and want the chance to find out.
Section 5: I would like more time on PR feedback. The current pattern is that I open a PR and the senior reviewer leaves comments two days later, which means my context is gone and I have to reload everything. Could we set a soft expectation of same-day or next-morning review on my PRs? I will commit to the same on theirs.
Common pitfalls at this stage:
- Listing too many things. Five strong examples beats fifteen weak ones. The reader cannot remember fifteen.
- Apologizing in the “would do differently” section. This is not a confession. It is a signal of growth. Pick something real, frame it as a future change, and move on.
- Vague forward asks. “I want to grow” is not actionable. “I want to lead a feature end-to-end” is.
What your manager wants to learn from this:
Your manager has limited visibility into the day-to-day at this stage of your career. They are looking for two things specifically. First, are you self-aware? The “would do differently” section tells them more than any other. Second, what do you want? They will use that to advocate for you in calibration conversations and to plan next cycle’s work. Give them the ammunition.
Template 2: Mid-level individual contributor, 3 to 7 years
Use this template if: You are well past the early-career signals stage but not yet senior. You probably have one or two areas of deep expertise and have started contributing to design or strategic decisions.
How long it should take: 90 minutes. The mid-level review is where the document does the most work, because your range of impact is widening and a lot of it is invisible.
Structure:
Section 1: Outcomes summary, by area
Group your work into two or three areas (for an engineer: features shipped, technical investments, mentorship). For each area, write a paragraph: what got done, what changed because of it, what is the headline. Save the longest section for the area where you had the most impact.
Section 2: Where I owned the call
Pick two or three moments where you made a judgment call that shaped the outcome. Could be a technical design decision, a scope cut, an escalation. Describe the call, the alternatives, and why you chose what you chose. This is where mid-level becomes senior.
Section 3: Where my judgment was off, and what I changed
Specific, not generic. The mid-level move is to name a real call that did not work and what you took away from it. Avoid the trap of picking something so minor that the section reads as humble-bragging.
Section 4: How I have grown into the next level
Concrete examples of work that is one level above your current title. Cross-team coordination, mentorship of newer hires, taking ownership of an ambiguous problem without being assigned to it. The case for promotion is built here, not in the ask itself.
Section 5: What I want for next cycle and what I need from you to get there
Direct ask, with reasoning. “I want to lead the next platform initiative because I have led pieces of it for the last two cycles and I want to own the whole thing.” Or “I am not ready to formally lead but I want to deepen on the security side, and I would like to work with [senior engineer] on it.”
Sample answer (excerpt, Section 2):
The biggest call I made this cycle was on the search rewrite scope. The original spec had us migrating both the indexing layer and the query layer in one project, on a six-month timeline. In month two, after the indexing migration uncovered three legacy issues we had not scoped for, I proposed splitting the project: ship the indexing migration as v1 in month four, then start the query work as a separate v2 project. The PM pushed back because it broke the announcement plan. I argued for the split anyway because shipping a working v1 in four months was higher value than landing a half-working combined version in six. We split it, the indexing migration shipped on time and clean, and the query work is now in progress with much better requirements. I was right on the technical and timeline call. Where I would do it differently: I should have raised the scope concern in month one when I first saw it forming, instead of waiting until I had a full counter-proposal in month two. The PM lost time replanning that they would not have lost if I had flagged earlier.
Common pitfalls at this stage:
- Treating the self-eval like a promotion case. It can support a promotion case, but if you write it as a sales pitch, the manager reads it as one and the trust drops.
- Hiding the “where I was off” section. At mid-level, the absence of a clear “I was wrong about X” answer is a signal of immaturity, not strength.
- Forward asks that are not connected to your actual recent work. Asking for a leadership track when nothing in your year shows leadership behaviors is a tell.
What your manager wants to learn from this:
At mid-level, your manager is calibrating two things. Are you ready for the next level (the case for promotion). And how much trust do they put in your judgment for the next cycle’s hard calls. Both of these are answered in your “where I owned the call” and “where my judgment was off” sections. These sections matter more than any other.
Template 3: Senior individual contributor, 7 plus years
Use this template if: You are operating as a senior in your discipline. You probably have ownership over a substantial area, are the technical or domain lead on multiple projects, and other people on your team or in adjacent teams ask your opinion on hard problems.
How long it should take: 90 to 120 minutes. The senior self-evaluation needs more thinking and less writing. The document should be short and dense.
Structure:
Section 1: The headline of the cycle
One paragraph. What is the headline of the year for you, in your manager’s vocabulary. Not “I worked on X.” Specifically: “This was the year I shifted from owning the platform to growing the next layer of platform engineers.” That is a sentence your manager can use in calibration.
Section 2: The work, with leverage as the lens
List your three to five biggest contributions. For each, the question is not “what did I ship” but “what did I unlock for others.” Code you wrote that another team built on. Decisions that gave the org clarity. Mentorship that compounded.
Section 3: The judgment calls, including the ones I made wrong
Two to four. Same as mid-level but with more context. At senior level you are expected to make calls under more uncertainty, and you are expected to be wrong sometimes. Document the wrong ones with the same specificity as the right ones. Manager hires senior people to make judgment calls; they need to see your judgment on display, including its failure modes.
Section 4: The team and org, not just me
Senior contributors shape the environment around them. What did you do for the team this cycle that was outside your role? Mentorship, hiring, design review investment, documentation that compounded. This section is the difference between senior IC and lifer mid-level.
Section 5: Forward, with strategic ambition
What is the next thing you should own that you do not currently. What would compound your impact most. Where is the org going that you could be ahead of. The forward section at this stage is partly a prediction about where the org needs to invest, not just a personal ask.
Sample answer (excerpt, Section 4):
Outside the direct work, I spent meaningful time this cycle on the team. I ran two design reviews per month that became the place where most of our medium-sized decisions got debated. I mentored Priya through her first solo project (she shipped it in month five and is now leading the follow-up). I rewrote the onboarding docs for the platform that I had been complaining about for a year, which cut new-hire ramp time from six weeks to three based on the last two hires. I also made the case to Maya for the new mid-level hire we landed, which I think is one of the most consequential things I did this cycle even though it does not show up in my project list. I want to do more of the second category next cycle: shaping the team so it can grow without me being the bottleneck on every decision.
Common pitfalls at this stage:
- Writing too long. Senior writing is dense, not extensive. If your self-evaluation is more than two pages of prose, you are over-explaining.
- Forgetting the team section. Senior individual contributors who only document their own work read as not yet senior, regardless of title.
- Soft forward sections. A senior who does not have a clear opinion on what should happen next is signaling stagnation, even if they are otherwise crushing it.
What your manager wants to learn from this:
At senior level, your manager is reading for three things. Are you still growing (where are you stretching). What is your read on the team and the org (because they trust your read more than most). And what should they be doing differently to make you more effective (the ask is information, not a complaint). The self-eval that lands at this level is short, opinionated, and useful to the person reading it.
Template 4: Tech lead or senior plus, transitioning to leadership
Use this template if: You are an individual contributor who has started doing leadership work without yet having the title. You are leading projects across multiple people, you are spending real time on hiring or coaching, and your title has not caught up with what you actually do.
How long it should take: 90 minutes. The transition self-eval is high-stakes because it is making the case for the next level, and it has to do that without sounding like it is making the case.
Structure:
Section 1: The work I led, not just the work I did
Two to four projects where you were the lead, even if your title says senior. Describe how you led them: who you coordinated, what calls you made on scope and timeline, what you did when things went wrong. The leading is the thing being evaluated, more than the shipping.
Section 2: The people I grew
Specific names, specific outcomes. “I worked closely with [name] on their first design review and they are now running their own.” “I helped [name] reframe their performance gap conversation with their manager and they got a clearer next step out of it.” Leadership is visible in the people who got better because of you.
Section 3: The decisions that needed me, and the ones that did not
Tech leads have to learn what to delegate. Two to three examples where you stepped in correctly. Two to three where you should have stayed out and let someone else handle it. Both are evidence of leadership maturity.
Section 4: The non-coding work
Hiring loops you ran. Cross-team meetings you coordinated. Strategic planning sessions you contributed to. This work usually does not show up in OKRs but is exactly what manager track readiness looks like.
Section 5: The next role and what is still missing
Direct: do you want to formalize into management or stay on the senior IC track and just lead more. Both are valid. Be honest about which one you want and what you think the gap is between you now and being ready for that title.
Sample answer (excerpt, Section 5):
What I want next is to formalize as engineering manager. I have been doing the work of one for three quarters: I run weekly 1-on-1s with Priya and Diego, I led the latest hiring loop end-to-end including the offer call, and I have been shaping the team’s project plan with Maya for the last two cycles. The piece I think is still missing is the formal performance conversations. I have given feedback in 1-on-1s and helped Priya prep for her own self-eval, but I have not yet owned a written review or a difficult performance conversation. I would like the next cycle to include shadowing Maya through her review work as the explicit growth area, and then I would like to have my own direct reports formally next cycle. If the answer is “stay on the IC track and just keep leading projects,” I am open to that conversation, but I want to have it explicitly rather than drift.
Common pitfalls at this stage:
- Underclaiming the leadership work. People in transition often default-describe their year as IC work even when 40 percent of their time was leadership. The self-eval is where you make that visible.
- Asking for the title without showing the growth. A clean transition asks happen after you have demonstrated the work for two cycles, not after one project.
- Not naming whether you want IC or manager track. Ambiguity here is the single biggest signal that you are not ready, regardless of skill.
What your manager wants to learn from this:
At the transition stage, your manager is making a case (or not making a case) for your promotion to a calibration committee. The self-eval is the document they pull from when writing that case. Make it easy for them. The four sections above give them four paragraphs they can lift directly.
Template 5: First-time manager, in role for 6 to 18 months
Use this template if: You are managing people for the first time, or have been in a manager role for less than two years. The self-evaluation at this stage is structurally different from any IC self-evaluation, because most of the impact you are creating is no longer your own work.
How long it should take: 90 to 120 minutes. The first manager self-evaluation is the hardest to write because the lens has shifted and most templates are still written for IC work.
Structure:
Section 1: The team’s outcomes
Lead with what your team shipped, not with what you did. Two to four big things. For each, briefly what your role was: were you setting direction, unblocking, hiring, coaching, advocating upward. Your contribution is real, but the team’s work comes first.
Section 2: The people
Specific named outcomes for your direct reports. Who grew, what they grew into, what work you did to support that. If someone struggled or left, name it. Avoiding it reads as defensive, addressing it reads as honest.
Section 3: The judgment calls I owned
Promotions you advocated for, hires you brought in, scope cuts you defended, performance conversations you ran. Two to four. The judgment calls of a manager are different from an IC’s: more about people, more about context, more about timing.
Section 4: Where I am still growing
Be specific. First-time managers often write generic answers here (“delegation, communication”). The version that works is concrete. “I was slow to give feedback to [specific report] when their work started slipping. I had the conversation in month three when I should have had it in month one.” Or “I struggled to push back on my own manager when she added scope mid-cycle, and the team felt it. I am working on the upward conversation with her this cycle.”
Section 5: The forward, both for you and for the team
Two parts. What you want for the team next cycle (a hire, a structural change, a piece of work that will compound). What you want for yourself (more scope, a different stretch, eventually a director track or a return to IC work). Both belong here.
Sample answer (excerpt, Section 2):
The team grew this cycle in ways I am proud of. Priya stepped from senior into tech lead on the search team, which she earned through the platform work in Q2 and Q3. I started talking to her about the next step in February, we used the spring as the stretch, and the formal change happened in September. Diego shifted from being a strong individual contributor to someone who takes ownership across team boundaries; I am not sure how much of that was me versus the work, but I made sure he had the projects that gave him room. The harder one was Sam, who left in June. The honest read is that we did not move fast enough on the role mismatch. I knew by month two that the work he was being asked to do was not his strength, and I tried to redesign the role. I should have had the harder conversation with him sooner about whether this team was the right place for him. He left for a job that is a better fit for his actual strengths, which is the right outcome, but it took longer and was more painful for him than it should have been. The piece I am taking forward: I will run the role-fit conversation explicitly in month two going forward, instead of trying to redesign quietly first.
Common pitfalls at this stage:
- Writing the self-eval as if you were still an IC. First-time manager self-evals that lead with “I built X feature” miss the point. Your team built X feature. Your value is in how you set them up to.
- Avoiding the people part. If your direct reports are not named in the self-evaluation, you have written a CV instead of a manager evaluation.
- Not addressing what went wrong. First-cycle managers always have at least one thing that did not work. Naming it specifically is a sign of maturity. Hiding it is a sign of insecurity, regardless of how clean the rest of the year looked.
What your manager wants to learn from this:
Your manager is trying to figure out if you have made the shift from IC to manager identity. The four signals they are reading for: do you lead with the team’s work, do you name your people specifically, can you describe judgment calls in people terms, and can you name what went wrong without flinching. A first-time manager self-eval that hits all four is rare. Make yours one.
What to do if your team writes weak self-evaluations
The templates above are written for the person filling out the form. Your job, as the manager, is not to enforce them. It is to coach quietly, two weeks before review cycle starts, so that what comes back to you is more useful.
The lightest-weight version of this is a single pre-review nudge. About two weeks before self-evaluations are due, send each of your direct reports a short message:
“Self-evaluations are due [date]. Quick note before you write yours. The version that helps your review the most is one that does four things: tells me what specifically got done and what changed because of it, names one moment you would handle differently and how, says what you want next year, and tells me what you need from me to get there. Skip the long list of everything you did. I have most of that already. Use the document to surface what I do not have.”
That message alone, sent every cycle, lifts the median quality of self-evaluations meaningfully. People want to do this well. They just have not been told what “well” looks like.
If you want to go further, link them to the relevant template above (career-stage matched), and tell them the document does not need to be long. Two pages is plenty. One page is fine if the page is dense.
If you have a direct report whose self-evaluations are consistently weak across cycles, that is also a data point. It usually means one of three things: they do not yet trust the cycle (they are writing defensively), they have not been coached on what good looks like (your job to fix), or they do not yet know themselves at the depth a self-evaluation requires (a development conversation, not a writing conversation). The first and third are common. The second is the easiest one for you to fix in a single cycle.
For the deeper structural question about whether your team’s goal-setting is even working, the are your team goals setting you up to fail free assessment catches the most common pattern, where employees cannot write good self-evaluations because the goals they were measured against were never specific enough to begin with. That problem is upstream of the self-evaluation form, and no template fixes it.
The biggest mistake managers make with self-evaluations
There are two equally bad patterns, and most first-time managers fall into one of them.
The first is to ignore the self-evaluation entirely. The manager already wrote their version of the review, the self-eval comes in, the manager skims it, files it, and writes nothing into the conversation that came from the document. The employee correctly senses that the document was theater and stops investing in writing it well. By the third cycle, the self-eval is two paragraphs of nothing and the document is dead. The manager loses their best window into how the employee sees themselves.
The second is to use the self-evaluation as a weapon. The employee writes something specific, and the manager uses it later as evidence in a difficult conversation. “You said in your self-eval that you would do X differently, so here we are.” This kills self-evaluations forever. The next cycle, the employee writes the safe version, because they have learned that honesty in this document costs them later.
The version that works is in the middle. Read the self-evaluation closely, before you finalize your own draft. Bring it into the meeting explicitly: “I read what you wrote about the security review. I want to talk about it, because I had a different read.” Use it as a conversation opener, not a verdict. Update your own draft if their context genuinely changes your view. Do not use it as ammunition.
Self-evaluations work when both sides treat them as a shared document for a shared conversation. They fail when either side treats them as a unilateral record. Most of the failures come from the manager side because the manager has more power in the dynamic. Your job is to make this document worth writing well, every cycle, by treating it that way yourself.
Frequently asked questions
How long should a self-evaluation actually be?
Two pages, plus or minus. One page is fine if the page is dense and specific. Three pages is too long unless you genuinely have something to say in every paragraph. Length is not a signal of effort; specificity is. Most managers reading these will give the long ones less attention than the short, sharp ones.
What if my company gives a long template with rating scales for every competency?
Fill in their template (you have to). Then write a short, two-page personal version that follows the four-component structure above and bring it to your meeting. Most managers will read the short version more carefully than they read the long one, because the long one is mostly checkboxes. The short version is where you actually make your case.
Do I need numbers and metrics in every section?
Use them where you have them, do not invent them where you do not. A made-up “10x improvement” reads as untrustworthy. A specific “led the migration of 14 reports, hit the November cutover, zero rework” reads as honest and credible. The point is not to look quantitative. The point is to be specific about what happened.
What if my year was bad and I do not have wins to lead with?
Be honest about what happened, name the context (what shifted, what you tried, what did not work), and use the “what I would do differently” section more heavily. A self-evaluation that is honest about a hard year is much stronger than one that performs success that was not there. Managers can tell the difference, and the honest version often surfaces the support you need to have a better next cycle.
Should I share my self-evaluation with peers before submitting?
If your peers are writing their own at the same time, a quick swap is useful. Read each other’s drafts, give one piece of feedback each. Two patterns to watch for: are they specific enough, and did they include the forward section. Most drafts get tighter and more useful with a single round of peer review.
How do I write the “what I would do differently” section without sabotaging myself?
Pick something real but not catastrophic. The goal is to demonstrate self-awareness, not to confess every mistake. The strongest version is a specific behavior that you have already started changing, with evidence of the change. That reads as growth in motion, not as a problem.
What if I disagree with how my manager rates me after the review meeting?
The self-evaluation is your strongest position to disagree from. If you wrote a clear, specific document with concrete examples, and your manager’s draft does not match it, you have an artifact to point to. Disagreements should happen during the conversation, not after. Bring the self-eval back into the room and ask your manager to walk through where they see it differently. Most disagreements are about a piece of context one party did not have.
Should I use AI to write my self-evaluation?
Carefully, and not for the parts that matter most. AI is fine for tightening the prose, for suggesting structure, for catching where you are being vague. AI is not fine for the “what I would do differently” or “what I want next” sections, because those are exactly the parts where your manager is reading for self-awareness and direction. A self-evaluation that reads as AI-drafted lands as ungenuine, and your manager will treat the document accordingly. Write the substance yourself, then use AI for editing if you want.