Seriously, this week I had my annual performance review, and my manager pointed out several weak areas, and I have no plans to address these weak areas. In fact, as a professional, my answer to this performance review could even end up getting me fired.
In our company, I as an employee am expected to fill out a self-evaluation, my manager is also to fill out an evaluation, and then we discuss the differences and file the forms with HR. The first thing I noticed is that I didn’t know how to fill out my copy of the form. Each line item I could rate as “strong point,” “satisfactory,” or “needs improvement.” I knew what each line item meant, but I didn’t know what my manager actually expected of me, so I didn’t know how well or how poorly I had achieved it.
Now, I could have just evaluated myself against my own personal yardstick, in which case I would have had a dozen strong points. Isn’t that a little disingenuous? Well, no, actually. Because I achieved measurable progress in all areas I had set goals for, and I was happy with my performance in all the other areas.
But it would impact my manager more if I were to drive home that he and I need to talk more. So, for all line items, I marked down “satisfactory,” neither good nor bad. The only further comment I left was that I thought better communication with management would make my job easier.
But then came the meeting with my manager and his evaluation. In almost 20 years as a software developer, I have never had less than a stellar performance review. Now, one year with one manager, and I finally understand. Well, I understood before, but I had not internalized it. Now I can internalize it: Performance evaluations are not about actual performance. They are about the relationship with the guy filling out the evaluation form.
I don’t want to make it sound as though the evaluation was all bad. For example, my manager thought I had strong organization skills. He particularly like my “system of breaking down a project and organizing the individual tasks.” Ah yes, I am proud of my system. It’s a system I began using years ago in a prior job, to track features and tasks and to estimate how long new features would take to develop. As a result of this system, I actually know how much I can safely commit to, and I actually deliver when I say I will. It’s a marvellous system, one we should all try. Those of us in the know call them story cards.
Then there was the fact that my code has fewer bugs than anyone else’s. I produce high-quality code. I was actually surprised to hear this, because I didn’t think we counted bugs. Well, as it turns out, we don’t. I still believe I probably introduce fewer bugs, because I’m the only one of our little team that uses unit tests, at least on new code. I hate bugs, both the software kind and the multi-legged kind. And as far as I know, the few I have introduced into our system have all been in non-unit-tested code.
(As you can probably see, I’ve been reading Extreme Programming Explained and Crystal Clear. Actually, I read them both long ago. But I also have them both on my shelf at work, and they are my plumb line.)
So I do deliver quality code on-time, but my productivity “needs improvement.” Apparently, I often require “more than [the] ‘normal’ amount of time.” Is that true? How do we know? What’s the “normal” amount of time? We don’t actually have a way to measure feature size or velocity. I’m the only one of the team who measures his velocity. (Remember the story cards?) But how do you compare that to other members of the team? And why would you want to?! Gack! Talk about sabotaging teamwork!
Fortunately, no one’s talking about sabotaging teamwork. But I have a sneaking suspicion that because my code actually works the first time (usually), and because I don’t have to spend endless hours after-hours tracking down yet another defect in our legacy system, it looks like I’m getting less work done. I’m not speaking ill of my teammates, mind you, because they really are doing the best they can with a system and process that fights against them at every turn. They are good programmers, each according to his experience level, and I truly vouch for each of them. And if any of them were to ask for a job reference, I’d give it in a heartbeat. This includes my manager, who is also the team-lead. (If a job reference from a wash-out like me is worth anything.)
But I’m a toxic employee. So my “attitude… needs improvement.” Seriously. I “often look distressed and disgruntled.” This in addition to some not-so-stellar properties of my communication and teamwork skills. According to the report, I’m always arguing everything, and this puts off the other team members.
This confused me greatly. Yes, I am always ready to point out alternatives, especially the challenging ones that require us to think outside the box. This could come off as argumentative, but I consider a good thing. It’s called collaboration. Just this past week, one of the other engineers came to me for advice. She wanted to talk to me. I did not ask her. Together, we delved into the engineering problem she was working on.
My manager from his desk he had heard everything we said, and he cited it in my performance review. He noted how I had picked over everything, always giving a contrary viewpoint. Well, yeah. That’s what she had wanted. I had asked her what kind of input she wanted from me, and she had said she just wanted my thoughts on this design problem. So that’s what she got, my thoughts, no matter how challenging they were. I also told her I might be talking out of the back of my head and that I wouldn’t be offended if she ignored everything I said. They were just ideas, and she was doing the actual work.
The next day, she came to me again and discussed the same engineering problem some more. I did not bring up the subject; she did. If I had made her feel so bad, why did she keep coming back for more? I asked her an open ended question: “What did you think of our meeting yesterday?” She said that she thought it was constructive and useful and that she appreciated my spending my time to hash through her design problem. (I later gave her feedback on how constructive it was for her to give me feedback on our interactions, but that’s another story.)
This all actually did tell me something useful. It told me that I have not been smiling enough at my boss.
It also reaffirmed something else I already knew. My manager and I do not talk enough. We talk about my tasks and my status, but about personal and social issues we are in two seperate worlds. I don’t really know what he expects of me, much less whether I can deliver it. I’ve never really asked. I do not know how what I do fits into the broader corporate vision, or how it fits with what my teammates are working on. I’ve never really asked. And he does not know what excites me about my job, what gets me down, or what my aspirations are.
I asked him if we could have a short, weekly meeting to discuss these issues on an ongoing basis. Or at least every other week. He’s very informal and doesn’t need a set time, but I told him it would help me remember. Otherwise, I might forget and put it off, and it would slip through the cracks. And I didn’t want that to happen, because once a year is not frequent enough for a performance review. So I asked him for a weekly meeting.
I had no real choice. The performance review was a disaster, because once a year is not frequent enough for a performance review. (I know I’m repeating myself, but that bears repeating.) In order to be effective, performance reviews must happen every month, every week, and even every day. It’s that darned feedback cycle again. Agile management, anyone? I need feedback frequently and quickly in order to address workplace issues.
So I plan to discuss these things with him, for better or for worse. I’m taking the first step, which may help. Or it may bring to the surface those issues that are more comfortably left submerged.
Hmm. I see here under the “Leadership/Initiative” line item — “Able to take charge and direct and coordinate activities; able to work independently; seeks increased responsibilities” — he marked, simply, “satisfactory,” no specific comments.
Oops. I think I mentioned unit tests to one of the other developers today.