It's that time of year again: annual performance reviews (aka, "how big is my raise?")
It happens every year, just before the holidays. However, things are different this year. A few months ago, it was suggested that managers tell their employees that raises would be small for the coming year--part of an effort to keep expenses low. That's good. No, not the small raises. The part about telling employees in advance. It helps to set expectations and make employees feel a bit more involved in keeping the company financially healthy.
But it seems that many managers did not. I'm hearing a lot of complaints from co-workers. They're pissed off about their reviews. Some are suprised by the numbers, while others are surprised by their actual performance review. Some of the second group feel like their managers are nit-picking them on their reviews as a way of justifying the lower increases.
That's just not cool.
The way I see it, if a manager has negative things to say during your year-end review and they surprise you, there's a real problem. You manager isn't doing his/her job by saving up all their complaints for the end of the year. You really ought to be hearing about them during the year so that you have a chance to work on them and show improvement.
Be open and honest with your employees. Try not to surprise them with bad news. Expectations matter. A lot.
(No, I'm not unhappy about the process. I've always had a good relationship with my manager, so I had no problems with it this year. But I appear to be in the minority, at least among those I've discussed it with.)
We take it for granted that many hi-tech workers (often software engineers) have a very hard time seeing their work from a business point of view. To many, it's just technology. They're building software, not business tools. Creating hacks rather than solutions. Companies hire them to work their magic and hope that their managers will keep them in line with the company's goals.
It's a rare engineer who can see both sides of the coin: the technology and its application toward achieving a company's business goals.
However, there's a stranger breed that I've encountered: the engineer who has somehow forgotten how to look at things from a traditional software engineer's perspective. This odd creature has little trouble explaining how his work supports the company's broader goals. Yet he has difficultly communicating with the more common engineers--those who mainly see technology.
I'm really not sure what to make of this.