Google+ Followers

Monday, June 15, 2009

It's that time of year again....

It's June and at ICPSR that means it's nearing the end of another quarter and also the end of the 2008-2009 fiscal year. And that means it's time to start writing formal performance reviews, and to create the formal work plans for next year.

I've worked at a lot of different places, managed many different types of technology groups, and used different mechanisms for this activity. At our start-up software company, almost nothing was written down; at the UUNET portion of MCI Worldcom the process was surprising lightweight - everyone was just a number in a spreadsheet; and at ICPSR the process is more heavyweight.

Each had it's virtues and vices, but a heavyweight process requires more writing, and more careful thinking. If one is distilling performance over the past year into a digit between 1 and 4, then the "writing" aspect it pretty easy; if one is writing a handful of paragraphs about the person's performance over that same time period, it takes a lot more time and thought.

There are a lot of different ways to measure performance, but for my money the best performers demonstrate their value to the organization in the following seven ways. Sometimes you'll have that rare person who shows four, five, maybe all seven of these characteristics, and my bet is that they're your top performer.

Quantity. Whether its troubleshooting network problems, solving desktop or server issues, or writing code, the top performers are the people who get a lot of stuff done. They don't sacrifice quality for quantity, and they do the little things right like commenting their code or tickets, and making sure they've left behind a good trail that others can follow. When they take a vacation the rest of the team groans because they know they'll have to pick up a ton of slack.

Quality. These are the people that write the applications that look great and work just like you'd expect them to work. Their stuff is good, and intuitive to use. They are the people that really come to understand the appropriate technology and standards, and they solve the problem once and for all. They don't use a band-aid when major surgery was the necessary solution. (Or vice-versa.) Once they fix it or write it, it just works.

Flexibility. Knowing one thing well is useful. Knowing one thing really, really well is really useful. Knowing a lot of different things reasonably well is gold. Having the attitude to say, "Well, I don't know how to do that using X, but I'll go find out." If I can only give a certain kind of project to someone on the team, then their usefulness and ability to contribute is really constrained. If I can throw almost anything at them, then their value to me is huge.

Knowing the business. Someone who really understands what the business is, how it makes its money, how its key processes operate, and how the major pieces fit together is essential for certain types of problem-solving. These are the people who can tell that something isn't quite right, and they dig into the business and people processes to find out what's really wrong. And then they fix that thing, not the symptom. It takes a while for new staff to really get good at this, but it is a critical area for their growth and development. It keeps them in the core of the business, and makes them a partner in its success.

Teaching. Key staff are good teachers. They teach themselves new technologies. They teach their peers new ways of solving old problems. They teach their managers about new developments in technology and problem-solving. They email you links to articles or blog posts or book reviews that are interesting and timely. They teach their colleagues and customers why something broke, and how they fixed it. They learn stuff well enough that they can teach others about it, and they have the patience and skills to explain things in a lucid, disarming manner. They are like MVP point guards in basketball: they make the whole team better.

Writing. Good writers help the whole organization. They write clear comments in code and tickets. They post illuminating and interesting content in blogs, wikis, and support forums. They put together good information to share with the boss (theirs and mine). They can put together those "all organization" emails that explain clearly and concisely what sort of maintenance is going to happen next week at 6am, or why the server blew up yesterday at noon. They don't just forward that long email; they annotate it with two sentences that deliver the punchline, inviting you to read the whole thing if you want to see the details. You make time to read their long emails because you know it's long for a good reason.

Asking for help. No one knows everything about everything. There is always a time when someone gets stuck with a problem, whether it's interpersonal, technical, political, or other. The top people know when they've stopped making progress and are spinning their wheels. Instead of waiting for the boss to notice, poke into the situation, and then call for relief, they contact the boss first. Or one of their colleagues. Or the customer. The point is that they know when to reach out to others in order to finish the job. Their ego is strong enough that they aren't afraid to say "I don't know."

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.