The art of constructive peer reviews

Goal

Peer-generated, targeted quality improvement on ticket handling (professionalism + technical skills), including responses and escalations

Process

I suggest tickets from 2 separate days owned entirely by the selected TSE.

• Quickly review any notes from the last episode to see if there is anything in particular to focus on, eg, "reviewee needs to provide more documentation links instead of cutting and pasting answers from the docs site", "reviewee is new to Java", etc.
• Then begin reading tickets; anything notable - good, bad, or ugly, should be noted with a link to ticket. Include what was wrong or right, where the facts are (verify your recollection that the docs are as you imagine them to be), and consider: would you review this ticket differently if you didn't know who had worked on it?
• Each ticket should be assigned scores or given individual ratings like good/bad/noteworthy (w/explanation) for each category. Categories could be as simple as "professionalism and technical skills" or as detailed as relevant to your workflow (for instance, "was ticket tagged and retitled appropriately? escalation procedure followed? macros used when appropriate? spelling and grammar correct?"). Once you've given the reviewee a solid chunk of your time (uninterrupted, preferably), take the time to summarize each ticket (if complex & desired) but definitely summarize the corpus of work you've reviewed. Focusing on trends and highlights in this "executive summary".
• Now, go over the most important points of your review (as well as anything you think the reviewee would be surprised by) with the reviewee. This is their chance to explain their actions in case they see something differently than you. This is your chance to teach gently where appropriate but definitely a good time to call out wins as well during this conversation. Once you've worked through the review with the reviewee, pass it on to management.

Once you've completed your rating, please leave a brief summary in the spreadsheet of review history, following the column headers (Name, summary, score, recommendations, reviewed by, review date), and add anything you'd like to communicate to the next reviewer of this TSE. This sheet may also be added to by the reviewee's manager or another senior TSE who notices something especially great or concerning about the reviewee at any time. The "score" column should be an average of the individual ticket reviews.

Guidelines

...mostly boil down to: be nice, be constructive, be honest.

Don't forget to call out the clear wins, for instance:

• "your handling of this irate customer was great, despite what he had to say about it"
• "your solutions are consistently superior and your tickets close with few turnarounds and high satisfaction"
• "your speed does not seem to impede your high quality"

If you're going to call someone on something more contentious than spelling, try to do it constructively: "I don't think that customers understand your standard terminology for the "WSM", perhaps you could spell it out?"

Further, be sure to include the following:

• Raise 'Stop'/'Address this immediately' concerns
• Follow-up on concerns on past reviews
• Depending on someone's last review, consider reviewing again sooner the more concerns are raised.

Things to check for

• escalation quality If a development team member put a reply of any kind into the ticket, verify that all homework was done beforehand (logs gathered, docs checked, problem reproduced if possible), a nice summary presented (if necessary), and that the agent hero didn't notice anything obvious that was missing.
• appropriate use of cut and paste content We've got the first touch for PHP tickets down to a science textbook. For everything else, effort should be made to make the pasted response personal - mention the customer by name, restate their specific problem, and any links used should be fresh (to the latest agent version at the time, for instance, but even screenshots should be glanced at to make sure they're not exposing NR tags or old or unreleased UI content)
• effective understanding of the customer question While we all know the customer doesn't always understand what they are doing, we need to be a little clairvoyant or at least make sure we're clear that we aren't sure what they're asking, ala "I think you're trying to X, and here is my suggestion for solving that. In case I misinterpreted what you were asking, could you clarify?"
• effective communication Did the customer understand the answer, and if not, did we notice and respond usefully?
• grammar & tone Since all we have is words, we have to present our best face. Don't be a grammar nazi (unless you see a typo in pasted content, in which case it's appropriate to request that they fix it), but look for trends you can comment on usefully. Useful feedback I once received: "Your sentences frequently take up a paragraph and are thus sometimes hard to parse. Semicolons are more appropriate in ancient works of literature, though they are delightfully quaint here."
• good use of private comments Did the TSE show the thought process or rationale, complete with permalinks or screenshots? It's helpful for other TSE's who might work the case as well, and who may not know why we requested a particular piece of information (as an example.)
• audience-appropriate language Does the writing target the customer? Company-specific vocab words or acronyms should be intelligible and consistent with documentation (eg: Network rather than TCP Stack). For non-native English speakers, is the writing clear and free of too many colloquialisms, slang and idioms, or would it break Google Translate?
• efficient use of ticket iterations Are we doing as much as we can to move the ticket toward a resolution in each response? What else can we ask for besides just logs or a permalink in the opening moves of troubleshooting? For example: What application details might be relevant? If possible, provide more than one diagnostic step so that we can make the most of a round trip.
• thorough research Did the TSE make use of public docs, the wiki, JIRA, discussion forum, StackOverflow, Zendesk and subject matter experts on the team?
• adherence to procedures - have the correct tags been applied, Zendesk categories adjusted, ticket workflow procedures followed?
• extra credit: note whether the reviewee is exhibiting next-level skills
  • correlating trends across tickets
  • answering an incredible volume of complex tickets well
  • getting a lot of positive reviews
  ...and call that out (as a plus).