It’s really easy to mistake “busyness” for productivity. The folks always rushing around, having meetings and complaining about how busy they are certainly LOOK like they’re doing a lot. But the reality is that effort and output are not always related. Productivity is about getting loads done — how you spend your time should be up to you.

Coming in at 8:00 reading email, attending a few meetings while checking your CrackBerry a lot, going to lunch, then spending most of the afternoon writing documentation on software that’s already been completed and tested is very low productivity. Sure you’ve spent 8 hours working, but there’s very little to show for it except say for some very low value documentation that no one else is likely to ever read.

This happens all the time in large consulting projects. After the firm lands the work they go out and hire any contractors they can find on short notice. They dump them out on the client site and start billing 8 hours a day. Maybe the project actually does get done eventually, but generally it’s a few of the developers that do the bulk of the work. Many of the other junior contractors may actually be adding reverse productivity by injecting bugs as they produce line after line of cut and paste code. From a pure clock watching activity the lowest skilled developer on the project has probably put in more time than the most productive person.

The real problem is time is an easy metric to track, while productivity on a software project is difficult. Tracking hours billed or percentage done is easy. Tracking software quality or features completed requires more effort and certainly more technical knowledge. There’s plenty of false technical metrics that have been used from lines of code to the number of function points completed. Both of these measure how much typing you’ve done, but the best systems have as little code as possible necessary to implement the features that are actually used.

The best metric I can see with productivity is how many production quality features are getting done and how quickly. You can measure the ROI on something you can deploy at the end of any iteration, you can’t measure any ROI on the fact that you’re 80% done with the software design.

Apparently Email Free Fridays are catching on. Sport England announced a national ‘E-mail Free Friday’ in a bid to get people walking around the office in the UK. Veritas, US Cellular, PDB Worldwide Fulfillment services and others have all taken up the idea.

The movement appears to be gathering force in the UK where:

A recent survey in the UK revealed that 80 per cent of workers use e-mail politically to cover their backs, while a third admitted to using e-mail to avoid resolving a difficult situation face-to-face or over the phone. It is also common knowledge that up to half of all e-mails sent by workers are jokes, quizzes, forwards from friends, etc, which have become known to some in the communications world as ‘productivity viruses’ for obvious reasons. The e-mail free Friday is an attempt to address these problems, all of which are steadily increasing, by banning e-mail communication on that day, forcing employees to take a different approach and to use their time more appropriately.

— Ideas Bank

The benefits of experimenting with no email one day a week are:

• People are forced to use more robust forms of communications such as walking around and actually talking to colleagues, or picking up the phone.
• You get to see how much more productive you can be rather then constantly checking your email every 10 minutes and firing away quick responses.
• You can resolve even slightly complex problems much more quickly because you don’t need a chain of emails back and forth just to resolve small issues.
• You get a bit of exercise and experience more of the company by just walking around. (Similar to the idea behind management by walking around.)
• It’s really a sneaky way to do good old fashioned team building.

Hopefully we’ll see a lot more people wearing Hawaiian shirts walking around talking to people on Fridays in the future. Who can see your cool casual office attire if you bury yourself most of the day in a cubicle sending email and scrolling through your CrackBerry at lunch.

Came across this job listing a little while back:

Enterprise Technology Strategy Manager/Director

Skills: Has directed technical teams to complete system implementations
in multiple accounts and is still willing to do so.

Do you dive for the closest seat in a meeting? Sit next to your favorite co-worker? Sit in the back away from the table?

Deciding where to sit should be a conscious decision. Common wisdom is that sitting near the front of a class leads to better grades. This may be merely a fact of being forced to stay awake while the slackers hide out in back where they can let their eyes close. Here’s my personal seating rules:

1. Sit near the whiteboard. You’re a techie, chalk talk with a whiteboard should be second nature. If you’re not near the closest whiteboard you’ll hesitate to draw a quick and dirty diagram. Without that diagram a five minute discussion on where we’re going to move some web services can go on for twenty minutes.
2. Mix it up. If it’s a regular meeting pick a new spot. This will force you to meet new people and get to know them a little better. You’ll also be party to some of their side conversations. And you won’t be so tempted to just start a bitching session with your peer about how our process is so screwed up.
3. Sit near the food. OK, this is just a personal thing. Typically if there is food at a meeting it’s candy, and I’m a sucker for candy.
4. Don’t lean back in the chair. It’s been many years since I used to lean back in chairs, but it’s a memorable event when you go spilling over onto the floor.
5. If some of your developers are with you try to spread out. Strength in numbers can be overkill.
6. If someone’s doing a presentation don’t sit with your back to them. Either you’re forced to twist around 180 degrees or you sit with your back to the presenter. The first is uncomfortable, and the latter makes the presenter wonder if you care what they’re saying.

SD Forums opened up the registration for the Silicon Valley Ruby Conference a few days ago. So far they’ve got:

• Charles Nutter and Thomas Enebo: The JRuby Guys from Sun Microsystems
• Asuman Suenbuel: SAP
• Josh Susser: Powerset “Ruby and Rails”
• Tom Preston-Werner: “Chronic”

It’s April 21 and 22, but no location announced yet. But JRuby, Rails, and a natural langauge date/time library sound like good enough topics to me. I signed up tonight. I haven’t been able to take advantage of being so close to the Bay area since I last went to a Web 2001 conference six years ago. Geek weekend.