It’s easy to believe you know good job knowledge when you see it. But nobody ever sees job knowledge. What you see is what a person does with it. You see the answer they give a customer and the step they don’t skip at month-end. You see the fix they find for a bug nobody else could place. The knowledge itself stays in their head. O*NET, the US Labor Department’s database of occupations, describes knowledge as “organized sets of principles and facts applying in general domains.” You can’t watch a set of principles. So a review phrase that only says someone “has strong job knowledge” is an opinion, however sure you feel about it.
This post gives you phrases that point at what you actually saw. It splits job knowledge into four areas, and each area has strength and development phrases side by side. Every phrase is tied to evidence that another person could check. There’s also a short set of phrases for employees writing a self-evaluation. The post ends with the cases where even careful phrases mislead.
What can a manager actually see when they rate job knowledge?
Job knowledge means something different in every role. O*NET sorts knowledge into ten broad domains, from arts and humanities to transportation. That’s why a support agent’s job knowledge and a financial analyst’s have almost nothing in common. So it helps to stop treating job knowledge as one trait. Split it instead into four areas that show up in almost any role:
- Depth of expertise is how far a person’s understanding goes in their own field. It shows most in the hard cases.
- Product and process knowledge is knowing what the company sells and how work moves through it.
- Staying current is keeping that knowledge up to date when tools, rules or products change.
- Sharing knowledge is what the person does with what they know once someone else needs it.
Each area leaves traces you can observe, and each has people who can confirm those traces. This table is the map the rest of the post works from.
| Area | What you can observe | Who can confirm it |
|---|---|---|
| Depth of expertise | Problems other people escalate to them; how they handle cases outside the standard; whether they can explain why an answer is right; calls they made without sign-off, and whether those calls held | Peers who ask them for help; the lead who reviews escalations; ticket or case history |
| Product and process knowledge | Handoffs and onboarding that didn’t need the process redone; questions customers or other teams bring back; steps followed or skipped against the written process; accurate explanations to people outside the team | The next person in the workflow; customers and other teams; the written process and its records |
| Staying current | What changed in their method after a release or rule change; correct answers about the new version; what they taught others about the change | The people the change affected; changelogs and release notes; the employee’s own record |
| Sharing knowledge | Guides they wrote that others now use; questions answered in a shared place; peers they trained; requests for help and what happened next | The people who asked or were trained; the document history; the shared channel |
The right-hand column matters as much as the middle one. The US Office of Personnel Management’s guide to developing performance standards gives two rules that fit here. The first is that “Performance standards should be objective, measurable, realistic, and stated clearly in writing (or otherwise recorded).” The second covers work you can’t count: “If performance only can be described (i.e., observed and verified), clarify who would be the best judge to appraise the work.” Job knowledge is nearly always the second kind. You can’t count it, but you can describe how it was used and name who saw it.
There’s a further reason to anchor a phrase to something other people can check. Scullen, Mount and Goff (2000) studied ratings of managers, where each manager was rated by several people. The quirks of the individual rater explained 62% and 53% of the differences in ratings across the study’s two large datasets. The managers’ actual performance explained 21% and 25%. So that study found more of each rating came from who did the rating than from the person being rated. Evidence that a peer or a ticket history can confirm is one way to keep your own quirks out of the comment.
The rest of the post works best in a set order. First pick the area you want to comment on. Next check that the evidence in the table exists for this person in this review period, because a phrase without it is only an opinion. Once it does, adapt a phrase and swap in your own products, tools and people. If the comment you want to make is really about errors, rework or missed specs, it’s about quality of work and not knowledge. Those comments belong with the quality-of-work phrases.
Performance review phrases for job knowledge, by area
Every phrase below is a full sentence you could say out loud to the person. Each one names something you saw or could check. The development phrases also name a support step, such as a pairing session or a guide to read. That step is there because a gap with no help attached reads like a verdict. A gap with help attached reads like a plan the two of you share.
The people and situations in these phrases are illustrative, not real. They span support, finance, engineering and sales operations so you can find something close to your own team. Replace the products and names with yours, because a support team’s tools aren’t a finance team’s close process. If you can’t back a phrase with evidence from this review period, don’t use it. If you’re building a whole review around competencies, the guide to competency-based performance reviews covers the framework. There are also performance appraisal comment examples for other competencies.
Depth of expertise
Depth is hard to see in someone’s own routine work. A routine task looks the same whether the person understands it deeply or is following a script. Depth shows up when the work goes off the script. So the best evidence is often in what other people bring to this person. Who does the team go to when a case doesn’t fit the usual pattern? Can the person explain why an answer is right, or only that it is? When they made a call without waiting for sign-off, did it hold up? Your ticket history and your peers can answer those questions better than your memory can.
Strength phrases point at one of those moments and say what came of it:
- “Three of the escalations the team couldn’t close this quarter came to you, and the ticket history shows each one was solved on your first try.”
- “You explained why the revenue rule applied to the Morgan contract and not just that it did. The auditors accepted your reasoning without changes.”
- “You approved the database change without waiting for sign-off, and it has held through two releases with no rollback.”
Development phrases name the gap through one case and attach help to it:
- “This quarter you passed most questions about enterprise refunds to Natalie. I’d like you to shadow her on those cases next month so you can take them on yourself.”
- “Your answers on the lease accounting questions were correct, but you couldn’t say why when Mark asked. Let’s go through two of those cases together so the reasoning is yours too.”
- “You told the client the integration handles invoices in more than one currency, and our tests show it doesn’t yet. Before the next call on that topic, please check your answer with Peter, who built that part.”
These are worded with care for a reason. Each one names a single case and the person who saw it, so it describes one gap and not the person’s whole ability. The second phrase gives credit before it names the gap, because the answers really were right. Knowing the answer and knowing why are different things, and the person needs to hear that both are being looked at. The third phrase is the delicate one. It’s about someone who sounded more certain than the evidence allowed. So the phrase states what the test showed and says nothing about confidence. A phrase like “you overestimate what you know” would start an argument. A test result doesn’t, and the check with Peter gives the person a way to be right next time.
Product and process knowledge
These phrases stay on one side of a line. They say the person knew the product or the process. They don’t say the output was free of errors. A handoff can follow the process exactly and still contain a typo, and that typo belongs in a quality-of-work comment. Keeping the two apart matters because the fixes are different. A knowledge gap needs teaching, while a run of errors may need a checklist or more time.
Product and process knowledge shows up at three points in a workflow. The first is the handoff. When work passes from one person to the next, the next person finds out quickly whether the process was understood.
- “Both new sales reps you onboarded this quarter ran the quote approval process with no requests sent back. Their manager said that came from your walkthrough.”
- “Two of your handoffs to the implementation team in May were missing the security questionnaire, which is step four in the written process. Let’s walk through the current checklist together before your next handoff.”
The second point is when someone outside the team asks a question. A person who knows the product can explain it in terms the other team can use.
- “When finance asked how annual plans renew, your explanation matched the contract terms exactly. They used it in their forecast.”
- “Customers came back with follow-up questions on four of your answers about the reporting feature in the spring. I’d like you to spend an hour with the release notes and then sit in on one of Rachel’s demos.”
The third point is the written process itself. Someone who knows the process follows it, and they also notice when the document is out of date.
- “You followed the new month-end checklist from its first week, and you spotted that step nine pointed to a report we’d retired.”
- “In the June close you skipped the reconciliation sign-off twice because you thought it was optional. It’s required, and I’ll go through the policy and the reasons for it with you on Friday.”
Staying current
The place to begin is one change that happened in this review period. It might be a tool migration or a new tax rule. It might be a product release, or a new method your field has picked up. Once you have it, ask what changed in the person’s work after it.
That question matters because staying current shows in the work and not in the training record. A certificate tells you someone sat through a course. It doesn’t tell you whether anything they do is different now. So course attendance is weak evidence on its own. Stronger evidence is a method that changed after a release, or correct answers about the new version. It’s also what the person taught others about the change. The people the change affected can usually tell you, and so can the changelog. How someone picks up new material is a skill in its own right, often called learning strategies. Learning targets for next year belong in a separate plan, and the last part of this post says where.
Strength phrases name the change and what the person did with it:
- “When we moved to the new ticketing system in April, you rebuilt your saved views within two weeks. Three teammates now use your setup.”
- “After the vendor payment rules changed in July, you updated the payment checklist the same week. It’s now the version the whole team uses.”
- “You read the notes for the version 3 release before launch, and you answered customer questions about the new permissions correctly from day one.”
Development phrases name the change and what stayed the same:
- “The API moved to version 2 in May, but your last three integrations still used the old login method. I’d like you to pair with James on the next one so you see the new pattern in practice.”
- “You finished the new CRM training in June, but your pipeline is still tracked in your own spreadsheet. Let’s set up your views in the CRM together this week.”
Some people are up to date in one area and behind in another. The honest phrase says both:
- “You’re fully up to date on the new pricing tiers, and customers get clear answers from you. The new discount approval rules are where you’re behind. I’ve asked Sarah to go through the three requests you sent back last month with you.”
Sharing knowledge
This area needs the most care, because three different situations can look the same from the outside. The first is a person who shares freely. They write things down, answer questions where others can see them and train new people. The second is a person who doesn’t share because the conditions are against it. They have no time, or no habit of writing things down, or they’re on a team where sharing has never been noticed. The third is withholding, where a person keeps back what they know when someone asks. The guide to knowledge sharing in the workplace covers the organizational side of the first two.
Research has a name for the third. Connelly, Zweig, Webster and Trougakos (2012) described knowledge hiding as three related forms of behavior. One is evasive hiding, where a person gives part of an answer or a misleading one, or promises help that doesn’t come. Another is rationalized hiding, where they give a reason for not sharing. They might say the information is confidential or not theirs to give. The third is playing dumb, where they act as if they don’t know. The researchers found that distrust predicted all three. They also treated hiding as separate from simply not sharing, and from the wider idea of knowledge hoarding. But this is a research description of behavior. It isn’t a test you can run on one person in a review.
That leads to the rule for every phrase in this section. Describe what the person did and didn’t do with a named request or situation, and never name a motive. You can see that a question was asked and not answered. You can see that an answer left out the part the person needed. What you can’t see is why. A busy person and a person who is holding back can produce exactly the same ticket history. So words like “deliberately” or “hoarding” don’t belong in the review.
Showing someone how to do a task so they can do it alone is a skill of its own, usually called instructing. Strength phrases point at what that produced:
- “You wrote the guide to the quarterly audit export. It’s now the first link new analysts get.”
- “You trained Jack on warranty claims in his first month, and he has handled those claims on his own since August.”
- “When questions came up about the billing migration, you answered them in the team channel and not in private messages. The answers are there for everyone now.”
- “You took two junior engineers through their first on-call weeks. Both told me your notes were what they relied on.”
Development phrases describe one situation and pair it with a step that makes sharing easier:
- “You’re the only person who can run the partner payout report, and there’s no written guide to it yet. I’ll clear two hours next week so you can write one with Emma, who’ll run it after you.”
- “When Chris asked in June how the pricing model handles renewals, he got a summary but not the spreadsheet he needed. He had to rebuild it. Next time please send the file itself, and I’ll set up a shared folder for it.”
- “Three requests for help with the deployment scripts went unanswered this quarter, and the team waited on each one. I’d like us to talk about what makes those requests hard to pick up, and then set aside a weekly half hour for them.”
- “Most questions about the old billing system still come to you alone. I’d like us to talk about what you’d want in place before passing that knowledge on, so that sharing it doesn’t cost you anything.”
Before any of those development phrases goes into a review, check the conditions first. Ask whether the person had time and a place to share, or whether every hour was already booked. Ask whether sharing has ever been noticed or rewarded on this team, by you or anyone else. You should also ask how much people on the team trust each other right now. Connelly’s team found that distrust predicted all three forms of hiding, so low trust is a team problem before it’s one person’s. If those conditions aren’t in place, the phrase you’re about to write is really about the system. Fix the conditions first, and leave the phrase out of this review.
What should a self-evaluation say about job knowledge?
An employee can see things a manager often can’t. You might have solved a problem quietly before anyone noticed it. You might have written a guide for yourself that the team now uses. Or you might have learned a new tool on your own time. A self-evaluation is the place to name those things. But name where your manager can check each one, so they can confirm it and not just take your word for it. Being honest about a gap helps too, as long as you say what help you want. The guide to self-evaluation in performance reviews covers how to prepare and pick your examples. The phrases below give you wording only.
Depth of expertise
- “I fixed the repeated sync failure on the Carter account in August without escalating it. The fix is written up in the ticket notes.”
- “I can handle standard contract questions, but I still pass complex lease questions to Mark. I’d like to shadow him on the next two so I can take them on.”
Product and process knowledge
- “I wrote myself a checklist for vendor onboarding, and the team now uses it. It’s in the shared drive under onboarding.”
- “I explained the new reporting feature to the regional sales team in May. Their lead, Karen, can tell you whether it helped.”
Staying current
- “I learned the new analytics tool on my own time in the spring. I rebuilt our weekly dashboard in it before the old one was switched off.”
- “I’m current on the new expense policy, but I haven’t caught up on the travel booking changes. I’d like an hour with someone from finance to go through them.”
Sharing knowledge
- “I answered questions about the migration in the team channel so the answers can be searched. The June thread shows most of them.”
- “I haven’t written down how I run the quarterly reconciliation, so I’m still the only one who can do it. I’m asking for half a day to write it up with whoever takes it over.”
When do job knowledge phrases mislead?
The table near the top of this post assumes someone at the review can judge the evidence. Sometimes nobody can. If you manage a tax specialist and you aren’t one, you can see that her answers are accepted. You can’t see whether they were the best answers available. OPM’s advice to “clarify who would be the best judge” is the honest route here, and that judge may be a specialist in another team. But then you’re relying on their reading and not on yours. The quiet expert causes a similar problem. Some people know a great deal and show it only when someone asks. If nobody asks during the review period, the middle column of the table stays empty for them. Your phrase will then understate them, and it will look well supported while it does.
Knowledge held by one person is both a strength and a risk to the team. The engineer who alone understands the billing system really is valuable. But if you rate that as a personal strength year after year, you reward the very setup the team should be fixing. The person has every reason to stay the only one who knows. So a strong depth phrase and a weak sharing phrase can describe the same fact about the same person. It isn’t obvious which one the review should lead with, and the table won’t decide it for you.
A gap may also belong to the company. If nobody trained the person on the new process, or the process was never written down, the gap is real but it isn’t theirs. A phrase that names it as their gap can be accurate and unfair at the same time.
The last limit applies to every phrase in this post. Job knowledge stays an inference even when every phrase has evidence behind it. You watch a handoff go cleanly and conclude that the person understood the process. Maybe they did, or maybe the process was easy that month. Two careful reviewers can look at the same tickets and the same guides and read them differently. Nothing in this post settles which of them is right.
What happens after the phrase is in the review?
A development phrase describes the past review period, so it needs somewhere to go next. There are three likely routes.
A gap with a clear fix becomes a learning goal for the next cycle. The pairing session or the guide named in the phrase is the starting point. The post on goals for performance reviews covers how to write those goals.
A gap that repeats across cycles even after support needs a written record. That’s the paper-trail step, and performance documentation explains how to keep notes that are fair to both of you.
A gap you see across a whole team usually isn’t about one person. If three people are behind on the same new system, the cause is more likely the rollout than the people. That calls for a team-level look, and this skills gap analysis template gives you a structure for it.
Practice the development phrases before the meeting
You now have phrases with evidence behind them. Saying a development phrase to someone’s face is the harder part. The written version reads calmly. But it can come out too soft to register or too sharp to hear when you say it out loud. The person may also push back with a reason you didn’t expect, such as a lack of time or a process nobody showed them.
So practice it out loud before the meeting. Merlin can play the person you’re reviewing and answer the way they might. That way you can hear how your phrase lands and try a second version if the first one doesn’t. Merlin runs natively in Slack and Microsoft Teams. Practice you do on your own with Merlin is private. If you want a wider check on how you give constructive feedback, there’s a short assessment for that too.
Practice the review conversation with Merlin before you book the meeting.