Monday, June 27, 2005

Performance Review by Committee

Over here at SuperMegaCorp, we do annual or semi-annual performance reviews. For as long as I can remember they were a semi-annual event, but nobody had the time for that, so they were only done once a year.

In the Before Time, when we were smaller and more able to manage people effectively, performance reviews were a good thing. Now things are getting crazy. The team leaders can't do performance reviews for their team members because they have no idea what anyone's been doing, or how well they've been doing it. Sure, we can say we're closer to shipping the product, so something must be working, but what exactly?

This has led to a "review by committee" process. The team leaders spam out a dozen "how did Alan Smithee do this year?" emails, and wait for everyone else to do the hard work for them. The problem with this is that there's no accountability for Mr. Smithee, or anyone who slags him. I can say Alan had problems with alcohol and young girls affecting his work this year, and he gets a poor performance rating. He has no way of firing back, except to slag me for my penchant to talk about curling while I should be fixing his bugs, if he can figure out who was doing the slagging. You get the idea.

Some team leaders have tried the "self-review". Alan Smithee's team leader sends him the blank form and asks him to fill it in. That's creative. They're saying, "I have no idea what you've done this year, but if you fill this in I'll take it as gospel, except where it might contradict what your teammates are saying about you." There must be a better way to do this.

To make matters worse, the team leaders all huddle together in a room and project the ratings for each group of developers on the wall. Then they decide if the relative ranking is correct. Did Smithee deserve a better rating than Kruger? I can't even place a face to the name, but I can rank him relative to the rest of the lot? I used to think we were the only place demented enough to do this, but then I read about Microsoft's stack rank meetings. Yikes! I think Josh has a good idea - to apply some sort of weighting based on the team's performance as a whole. I don't know if that would work here, but it couldn't hurt to try.

When I was a team leader, one thing I took pride in was knowing what everyone was doing, and how well they were doing it. If I couldn't answer that, I wasn't doing my job.

Tuesday, June 21, 2005

Is there anybody out there?

Get yourself in the game. Play "Six degrees of [your name here]" and try Linked In.

In an area the size of Waterloo Region (half a million people, 400 high tech companies), there are plenty of opportunities for "networking", or "talking to others" as it was called before it became a buzzword.

The folks at Linked In have taken networking to a new level. You can be instantly connected to thousands of people in your area, and beyond. Sign up and see how fast the connections start pouring in.

Monday, June 20, 2005

So is it bad, or is good?

Looks like IT morale is poor. Maybe it's the media, maybe it's the truth in the numbers.

http://www.devxnews.com/article.php/3513726


Or maybe it's not that bad at all. At least not in Waterloo, where the tech companies are begging for IT people to come home.

Communitech news item

Thursday, June 16, 2005

A first time for everything

I think this is the first time I've agreed with Joel...

"No matter how good a recruiter you are, you can't compensate for working at a company that people don't want to work for"

http://www.joelonsoftware.com/items/2005/06/15.html

Tuesday, June 14, 2005

Small is the new big

Developing software is a very interesting thing. As I've mentioned, there's no silver bullet. No magic here... The process changes as the development group changes. We wrote a PACS client with six people, seven years ago. It's done OK. Now we're writing a PACS client with thirty people. The process we're using is not the same. Is it any better? The real test will come when we measure the success of the product, and when I say success I mean it from a developer's viewpoint. Is it fast? Is it reliable?

Here's an argument why small is the new big.

http://sethgodin.typepad.com/seths_blog/2005/06/small_is_the_ne.html

And how the process can get in the way of doing some good work.

http://www.37signals.com/svn/archives/001050.php

Thursday, June 09, 2005

What WAS in that glass pipe?

So "The Joe" tests positive for cocaine, but claims he never went near the stuff.

http://tsn.ca/curling/news_story.asp?ID=127362&hubName=curling

Curling's only a murder or two away from being a real sport now, like the NFL...

What makes you get up in the morning?

Ever have the feeling of being excited to go to work in the morning? These guys do:

http://www.fastcompany.com/magazine/28/ge.html

Maybe less "leadership", and trusting your employees really is the way to go.

Tuesday, June 07, 2005

Software Development for Marketing

Here's a quick course in software development strategies, aimed at marketing folks. I realize some marketeers are knowledgeable about development, but there are plenty who seem to think software is something that can be made like a bicycle. "Software factory" is a term I hope I never hear again...

1. Pick a strategy

Vision and leadership. Got 'em? Use 'em. Don't got 'em? Go get 'em. Use 'em. Seems simple, no? Pick a strategy that is achievable, and lay out a plan for getting from Point A to Point B. If you aren't sure of something, ask.

2. Communicate the strategy

Communicate it early and often. Make sure you let everyone know what the plan is, and what the expectations are.

It's ok to be a little fuzzy, but if you want to inspire people (there's that leadership thing again) you need to be able to draw on the whiteboard:

Here's where we are today --------------> here's where we want to be x days/weeks/months/years from now

and make your case for how long it should take to get there and what needs to be done along the way.

3. Stick with it

That line should be as straight as possible. Don't draw little circles. Don't get lost along the way. You can change things, but if you do, make sure you follow these steps again.

4. Trust the developers

Tell the developers what you want. Ask them how long it will take. If you don't like the answer, don't tell them to do it faster. Don't tell them to cut corners. It will end up costing more in the long run. Don't believe it? Try it. :)

Developers can be passionate about building good software. They thrive on being able to get work done with minimal interference. When you're putting together a software development team, think about creating the position of "bullshit deflector". More on that later...

Friday, June 03, 2005

Are design patterns a sign of trouble?

They seem to be hot. Everybody want to use them. Everybody wants to be up on the lingo. But are they a sign of trouble?

http://www.codinghorror.com/blog/archives/000308.html

Simple is better. Simple is better. Simple is better.

Don't go looking for a problem just because you read a good solution in a book.

Thursday, June 02, 2005

Increasing success by lowering expectations

Is your office filled with motivational posters, or mangers who soak this stuff up? Plant a few of these in the boardroom:

http://www.despair.com/indem.html