I recently got a letter from a frustrated TechRepublic member that clearly illustrates the dangers of a cardinal managerial sin—blowing off your employees’ performance reviews as meaningless chores to hustle through as quickly as possible.
We’re all guilty to some degree—I know I’ve punched in more than one “meets expectations” because I couldn’t think of anything better to say—but this seemingly innocent corner-cutting will invariably come back to haunt you. It’s certainly causing some problems for the manager of the TechRepublic member who’s concluded that leaving the company or transferring to another manager may well be her best career option after just four months with her current company.
I thought it would be a good idea to get a little more info from the reader, a developer at a computer services company who asked that we keep her identity confidential (she is currently pursuing complaints about her recent review through her company’s HR department—yep, that happens). The developer, who told me she has had previous managerial experience, struck me as a conscientious (maybe even a little tense) employee who certainly isn’t used to being damned with faint praise like “adequate” and “meets expectations” in personnel reviews. She says that after a career marked by a positive attitude and numerous accomplishments, she’s now uneasy about sending her weekly status reports because she’s been criticized for “communicating too much.”
In a 30-minute phone conversation, she related to me what seems to be a textbook case of a sloppy review process gone way wrong. Before I get into dissecting the common managerial missteps I see here, let me clarify that I’m not suggesting the manager actually had any unfair criticisms of the developer I spoke to—I’m certainly not close enough to the situation to make a call like that. But the entire point of personnel reviews is to constructively point out employees’ strengths and weaknesses and give them a path for growth. After my phone call with the developer in question, I can say pretty confidently that this employee-manager relationship has strayed far from that growth path.
And now, on to the lessons to be learned from this sad story.
Always base a review on a formal set of goals
This was my first critical question for the developer during our conversation, and sure enough, she had entered her first three months at a new company with no clear-cut goals for her initial three-month review. Her new boss had simply handed her a formal job description and told her she “would grow into all the aspects of the job description over time.”
A formal job description is not a set of goals; you can’t measure “works well with others.” Employees are far more comfortable with any criticisms you may need to level at them if those criticisms are tethered to tangible deliverables and timelines. The last thing you want to happen in a review is for the employee to say, “You never told me that I had to do that.” Tell them in writing, and make sure the paper is in an HR file someplace.
Use the employee's self-review as the basis of your review
The developer seemed most perturbed by the fact that her review included a lot of conclusions and opinions about her abilities but almost no reference to actual projects to which she contributed. This, despite the fact that she took the initiative to send her boss an informal self-review in advance of her review session that spelled out her contributions to six separate projects, one of which she said was key to the company.
“I’ve been around and I’ve been reviewed by a lot of people, and I know I have outstanding analytical abilities,” the developer told me in a highly displeased tone.
Many companies actually include a formal self-review as the kickoff point for personnel reviews; if yours doesn’t, you should push for the procedure to be implemented. It’s a great way to get a sneak peek at any possible disconnects that may arise during your review session with the employee. And pay particular attention to the accomplishments your team members consider important enough to cite to their own credit; nothing will tell you more about where their professional priorities lie.
Always synch your criticisms to the next round of goals you set for an employee
As expected, the developer told me she was presented with no quantifiable goals for her next review period. When I told her that insisting on set goals is a great way to make sure your manager doesn’t zing you with unfounded criticisms, she seemed a little baffled. I then asked her what kind of goals a manager could tie to a criticism like “communicates too much.” Stop sending status reports? Skip team meetings? Hide in your cubicle?
In all fairness to the manager in question here, it’s entirely possible that the developer I spoke to came from a markedly different work environment than the one that’s working for the team right now. But if you can’t suggest some tangible walk-away to a criticism—something like “condense weekly status reports into bi-weekly reports that include a one-page executive summary”—then maybe you don’t have anything to complain about. I can promise you that without such action plans, your employees will find your criticisms capricious and unwelcome.
If you’re going to include peer input, do it formally
The thing that really steamed our letter-writing developer was her belief that many of the criticisms in her review were based on input from one peer with whom she has “style differences” and who has the ear of her boss. At the very least, she said her boss confirmed that much of his critique of her soft skills was based on peer input.
I’m never going to suggest that you should turn a deaf ear to one employee’s complaints about another. But that’s just your cue to dig a little deeper and see what’s going on; that kind of hearsay should never make its way sight unseen into formal HR documents, such as reviews. It’s an invitation to a world of trouble, including questions of gender equity, which have been raised by the developer I spoke to.
If you want to include some kind of direct peer input into your personnel review process, formalize it. Either work with HR to add the form to the review regimen or, as I suggested to the developer in our conversation, close each project with a formal post-mortem that covers not only code deliverables but other issues like timeliness, innovation, and covering for peers. Feedback from open-air sessions like this is far more palatable to employees than closed-door murmurings.
For Pete's sake, take the review process seriously
In conclusion, the developer told me her best guess is that her review was just slapped together at the last minute. She said most people she’s spoken to at the company consider annual reviews to be kind of a joke, and certainly no tool for professional development. I know that getting through 10 reviews in addition to stepping in for a sick employee can be a strain, but plan for the review process as you would any other key responsibility. It’s that important.
The irony here is that your potentially best employees are the ones who will be most discouraged and irked by a lackluster review effort. They actually take their performance and reputation seriously. Sloppy reviews erode their confidence in you and the company and start them looking for new opportunities.
The end of this story is all too common; the developer I spoke to went to HR with her concerns, and now other managers in the company are being polled for feedback on her performance that may contradict the review she received. Whatever the outcome of that exercise, her faith and confidence in the manager who wanted to hire her in the first place has been shaken deeply—all because of a three- or four-page document prepared without the proper planning and care.
Got a management question?
Don’t know how to deal with a troublesome employee? Want to know the best ways to conduct a team meeting? Send us some mail or post a comment.
Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRepublic.com and ITBusinessEdge.com.