n Reasons to Stop Filling Time-sheets with Booking Codes

Booking codes: those labels for work packages that everyone records on their time-sheets. This means you can track what work has been done and how much of it. Useful, right? You can tell how efficient your various business areas are, right? You can tell what needs shaping up and what needs tweaking, right?

Wrong.

Well, mostly wrong. Here’s why:

• You don’t really use them for tracking – you use them as KPIs. Which means that everybody lies to you. Perhaps you were once aghast at the amount spent on admin, and so you demanded that people do less of it. When the time booked to admin went down, was that because people spent less time administering? No, of course not. Those admin distractions still exist: that poor time-sheet software that requires everything to be entered twice for every entry; that expenses software that keeps crashing; those travel policies that require staff to go through external agencies; those purchase policies that require unnecessary approvals. They still cost you productivity, but now you don’t see it any more. You’ve hidden your business inefficiencies from yourself. Oops.

• Tracking costs you money. When estimating the savings you think you might gain, factor in also the costs for every single one of your productive staff that has to stop producing and instead struggle with whatever painful home-grown system you’ve had cobbled together on the cheap because your customers won’t use it. Find out how much time it actually costs your staff – particularly the valuable ones who work on several projects because they have a lot of in-demand skills. What do you mean you don’t have a booking code for filling in time-sheets? I thought you wanted to know what effort was being spent on what?

• It costs your company agility and responsiveness: “I have an idea but I’m not sure about some technical aspects – can we meet to discuss them?” “Do you have a booking code?” “Er, no, not yet,” “Then no,” “But I can’t get one until I have a business case,” “Sorry, not doing it in my spare time”

• It costs your company conversation: “I have a problem with making a small change to System X, you’re an expert on System X, can you teach me about it?” “Do you have a booking code?” “Yes but it’s spent” “Sorry, not doing it in my spare time”

• It costs your company response time: Every delay added by waiting for a code is added to every task. Every required approval is a barrier to grasping an opportunity, and this shapes responses to changes circumstances.

• Booking codes turn your company into a hierarchical approval chain: managers demand business cases to approve booking codes, and so workers are discouraged from innovating, improvising and initiativising. Every dis-empowered staff member who has to go begging to be allowed to do something for the good of the team is a staff member wondering what loyalty is for. This may well be what you want. No no, don’t mind me judging you. I’m just a guy on the Internet.

You do of course want to track approximate project spend against project budgets. That’s fine – mostly. But proliferating booking codes to fill time-sheets just gives you a range of easy metrics that are not accurate – or even representative. Metrics give you numbers, and numbers are temptingly easy to pointlessly pretend to manage. People are discouragingly harder to manage.

If you employ staff who can be trusted to work for the good of the team then using booking codes is a distraction. If you don’t then you’re not running the team right and the booking codes are lying anyway. If you really really have to track some aspects of the company then sample your staff for a limited period: find volunteers who like this sort of detail, give them a reward and, of course, give them a booking code to book the extra work to.

 

(hat tips to conversations with Marco, Paul and John for their contributions – which are the least unsensible bits)

 

The Gorilla Process Conundrum

There is a story that is told to show us how we all behave stupidly in corporations

1. Place five gorillas in an outdoor cage in a cold, windswept location.
2. Suspend a banana in the cage above a ladder.
3. When any gorilla attempts to use the ladder, soak all five gorillas with a fire-hose.
4. Repeat until they avoid the ladder. After a short period of avoidance, replace one gorilla.
5. Note that when the new gorilla attempts to use the ladder, the other gorillas will beat him up. Take the fire-hose away.
6. Repeat step 4 until all original gorillas have been replaced.
7. Note that at this point, no gorillas use the ladder, any that try are beaten up, and none of them knows why.

…and aren’t the gorillas all stupid and everything for being unpleasant to each other for no reason.

The cheeky bit in this story is that little bit at the end of step 5: we know the fire-hose has been taken away but the gorillas don’t. People who have more information than others should not feel they are being clever, or the others are being stupid, when the difference is merely who has been told what.

If we keep the fire-hose with intent to use it, then the moral of the story becomes very different: the gorillas as a group are behaving in a way that keeps them dry even if they don’t know why.

Which is one use of process. We can follow process without requiring deep understanding, and that means in practice we can quickly learn ways of working usefully before finding out why it’s better to work that way. Once we know the work and the team well enough, then we can – and should – challenge poorly understood process.

That is, there are of course problems with simply accepting process or traditional practice, but there are also problems with letting every new gorilla climb the ladder to find out for himself: it takes time, and everyone gets wet and cold and miserable.

—

Many skilful tasks can be reduced to a checklist for routine use. For example, deploying webapps to Weblogic can become a routine task and there is no need (or wish!) for a skilled Weblogic guru to do this simple task when it can be written on a list and given to ‘junior’, cheaper staff, leaving the expert to work on other things.

Having a check list improves organisation capability and reduces effort. Coders whose attention is on building applications to solve difficult business problems can work from that checklist to to deploy their work themselves, without also having to learn the quirks of this particular web container or wait on the expert The checklist will tend to be written for simplicity and readability, so may contain some redundant or long-way-around methods. As odd problems arise, extra steps may be introduced (such as routinely restarting the container) that are not strictly necessary. It is not the ‘correct’ way to deploy, but a pragmatic one.

The list can be distributed without the expert which can be useful for quickly gaining capability, or can cause failures where they are not appropriate and people have referred to the list rather than look up an expert for their particular problem. The expert might leave out of boredom when all the challenging setup work has been done, or be ‘leaned out’. In both these cases we now have a checklist, or process, without the expertise to monitor it or review it. Workarounds are added by ill-informed rumour and the process gains warts and weights. Business needs change and the tools change, and process users attempt to shoe-horn them into the process, because there is no-one around to review it, or even authorise change to it – or worse, there may be people around whose job it is to enforce use of it, without understanding it.

Discarding process at any excuse is also not helpful as people then continuously relearn tasks, and the mistakes of the past, to a depth that exposes the reasons why the discarded process is the way it was.

So where then is the happy medium? An organisation should be willing to challenge process by the users of that process. It should have, ‘close’ to that process, experts who can carry out the technical arbitration when process users want different things from it. And the risk holders must be aware that not changing a process might be more harmful than changing it.

Holidays and Engineers

It was holiday season and staff all over the place were going away and coming back a couple of weeks and lots of miles and unfulfilled dreams later. Everyone had forgotten to plan holidays into the schedules, and all sorts of key knowledge was away on the beach getting soaked in bubbly or gin, or high in the mountains getting altitude sickness, or somewhere steamy getting cerebral malaria. Those minions left behind flit from crisis to crisis, usually head-down in the detail, and working through those incremental changes and discussions and events and reasoning that those away are blind to in their holiday-bubble-bliss.

So when they come back, feeling like they have lived for years on a different planet, there is always some reconciliation and adjustment.

For returning seniors this is easy. Usually they expect things to continue according to plan, which of course they never have. “Why isn’t it different?!” they roar, and I shamelessly cower shamefully beneath their fury and whine “But sir! Without the tingle tangle of your invigorating lashes, smarmy-smarm, how can we work without you? toady-flinch” and they swear undying punishment and spit fiery acid and depart, mollified by this proof of their motivational powers, to make a new Action Plan and Move the Dates to the Right.

Returning engineers are more tricky. Engineers expect things that ‘belong’ to them – the things they look after, or have created, that are therefore personally theirs – to remain the same. It doesn’t matter if they knew it was a bug-ridden fragile morass of spaghetti code, or if they’d not even finished it, or even if they’d only just started sketching out some ideas. Beware anyone who has touched it, let alone written a replacement! “Why is this different?!” the returning holiday-enhanced minions cry, aghast at the Unexpected Thing that occupies their gaze. “This was working fine!” and “We agreed to do it my way!” they outrage, being free with the meanings of ‘this’, ‘working’, ‘fine’, ‘we’, ‘agreed’ and ‘do it my way’.

The usual response by the bitter, tired and holiday-less minion is personal and tactless: “Your stuff wouldn’t work” to which the outraged minion replies disbelievingly “Oh yes? What was wrong?” followed by a short verbal debug, an outline of why it was stupid to try using it that way, barely veiled assertions on each other’s appalling lack of skills, and further discussion until Huff.

Tact can only add a single step to the start of the sequence, such as the impersonal “We couldn’t get the existing set to work” to which the returning minion cries “what, my stuff?” and the discussion continues as without tact.

About the only useful mollify is to blame external factors or teams: “We were tasked to provide the outer nodule with more kahoobles so we had to do it this way” at least brings on Straight Huff, possibly with faint “This could have done it” whine, and reduces the shouting.

I’m going on holiday soon. Don’t Touch My Stuff.

Obvious deficiencies

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature.”

– Tony Hoare in his Turing Award speech, 1980