Make Tasks Earn Your Attention

One of the banes of my life, usually within larger organisations was the annual performance review process. That delightful time of year when you have to scramble round your colleagues for feedback and fill in a mountain of paperwork justifying to your boss (who you'd have hoped would be up to speed on your performance already) as to why you deserve to receive whatever pay rise or bonus they've already decided they're going to give you.

After one particularly annoying experience, I decided to test a theory. One year, despite my having excellent feedback from colleagues and clients, and having billed 105%, my manager threatened to grade me as 'Not Meeting Expectations' because I hadn't contributed enough to the company's internal (virtual) software development community. No, the extra money they'd made from my overtime didn't make up for that, and after all, he had a curve to grade all his employees against. After much to-ing and fro-ing, and a hastily thrown together paper (that I'm pretty sure nobody ever read), I was graciously admitted to the 'Meets Expectations' group. At which point we were told that the company's performance hadn't been great, so the pot of money for bonuses would only be sufficient to pay 50% of what we'd otherwise expect. And no pay rises.

Basically, after several hours of pestering colleagues for references (whilst they're doing the same), and filling out dozens of open-ended questions, all in your own time (no billing code for internal paperwork), and the result is based on which of 5 categories you get lumped into, and how much money the company has decided to give to that group. All rather detached from what was (presumably) the original intent - to recognise and reward/manage employee performance.

I wrote previously about the reasons for doing things being lost over time (because of inertia, or whatever), and it strikes me that the same is true of organisational policies and procedures as it is of software development.

So what is the answer? In this case, I decided to take a leaf out of 37Signals' book. When deciding what features should go into their products, they take a simple approach - they listen to what their customers ask for, then ignore it. Anything that is truly important will bubble to the surface again, and you'll soon get an idea of what is truly important. The same goes for 'corporate' stuff - those small (and large) demands on your time that come from within an organisation. Everybody is busy within an organisation, so although something is being asked for, doesn't make it important. Saying no (or simply ignoring requests) seems to be a pretty effective filter - people will push for the things that they really need, and let the trivial stuff slide. In other words, make tasks earn your attention.

And the result of my experiment? Well, after another year of billing over 100%, I didn't spend tie filling out the reams of performance review paperwork, nor did I pester my colleagues for reviews. And ended up with the same result as I had the previous year...

About the Author: Chris is an experienced Software Developer, having been cutting code for organisations large and small since graduating in 2000. He currently specialises in building simple, secure, and elegant Java-based backend services. An Agile enthusiast and Certified Scrum Master, you can find his professional profile at LinkedIn. Away from work you'll probably find him playing football, training for various obstacle course and endurance events, or with his feet up having injured himself doing one.