Last Updated: 31 Mar 2010

   |   

Author: dordal

Conducting The Quarterly Review w/ Engineers

As a manager, I feel it is important to regularly checkin with your development, technical and engineering staff (or any staff, for that matter) to see how things are going. I try to do this either quarterly or semi-annually, and while I like to keep it informal to keep the stress level down, I do make sure to hit on a few points.

Tips

When you're conducting a quarterly review, I like to keep a few things in mind.

  • Keep your questions open ended. You want to provide feedback to your staff, but it's best to listen 80% of the time. So ask questions that don't have a yes no answer, and see where people take them (e.g. 'what other areas would you like to get into?' rather than 'would you like to get into more web development?').
  • Keep things informal. Some companies like employees to fill out scorecards and whatnot; I find that just puts unnecessary pressure on both the reviewer and the reviewee.
  • Make the reviews part of a regular process, and let the employees know that. People can get worried when the boss wants to 'review your performance' all of a sudden; I always remind employees that we do this regularly and “it's just a quick chat”.

High Level Questions

I use these high level questions to help frame the discussion with an employee. They're talking points, not interrogation questions, and so I just make sure I hit on all the points here, but not in any particular order.

  • How are things going? This is a good opener; just get a sense of how life is going.
  • What are you liking/not liking about your job? Try to focus on both the positive and the negative; in particular you want to listen for things that you might be able to change for your employee. I typically try to frame the 'not like' in such a way: 'look, I know there are all some things that we don't want to do in our jobs, but we just have to do them. That being said, my goal is to reduce your list of not-likes to as few as I possibly can, given the needs of the company. So what could we look at improving?'
  • What do you think [ACME Inc.] can do better, and how do you think you can help with that long term? Once someone has spent at least three to six months working in a business, they'll know it pretty well, and they'll frequently have ideas for improvement, some of which they may not mention because they don't want to rock the boat or tell someone higher in the company that they aren't doing an optimal job.
  • What are your personal / professional goals, and how can [ACME Inc.] help make those happen? Ultimately, you want your employees to feel like the company is meeting their needs and advancing their goals; they'll be that much more likely to stick around long term and advance the company goals.

Back Across the Table

You'll certainly want to provide feedback to your employee about how they are doing; afterall, that's the point of the review. I'd recommend doing it toward the end, after they've spent most of the time talking. Let them know:

  • How you think they are doing.
  • What you like/dislike about the work they've done over the last quarter. Compliments are always good here.
  • What you think they need to improve on. If you can, set some metrics around this improvement. For example, if they're not putting enough time into documenting their code, ask them if there are some specific items they could work on (maybe a comment on every function?) that they could work against.
  • If you're prepared to talk about it, discuss how the company may be able to change to meet their personal or professional goals, or to eliminate some of the 'don't like' items that they mentioned.

Taking Notes

I recommend you take notes throughout the process and keep those notes in a file for each employee, so you can refer back to them prior to the next review.

Discussion

Enter your comment. Wiki syntax is allowed: