NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to Please jump across to the new site for the latest articles (and all old archived articles).



  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • Advertisements
  • This blog has moved!

    This blog has now moved to Please jump across to the new site for the latest articles (and all old archived articles).



  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Why you should love timesheets

Posted by Preston on 2009-11-04

This is no time to talk about time. We don’t have the time! (Star Trek: First Contact)

Are you one of the unlucky IT staff who don’t record timesheets? If you are, here’s what you can do to (a) convince yourself that you’re unlucky, and (b) convince your management that they need to change, quickly!

[Edit, 2009-30-11: I get a few visitors a few times a week from searches such as “timesheets are a waste of time”. If you’re one of those visitors, I hope I am able to convince you otherwise.]

When I was first a system administrator, I had to do timesheets. Each week I’d grumble about having to do them, but compared to others in my team who would frequently be months or more behind, I’d usually get them in “on time”.

In my next system administration job, I didn’t have to do timesheets and initially thought I was blessed. After a while I noticed though that a lack of timesheets made for some very odd management attitudes. I’ll get to those in a minute – they’re at the crux of what I want to discuss.

Then I moved out of system administration into consulting, and pretty much ever since then I’ve had to do timesheeting. In fact, I ran a team of up to 20+ engineers for a couple of years and they can probably all attest to the fact that I used to bug them weekly to make sure they had their timesheets up to date.

You might say that I’m a believer.

I’ll do some initial qualifications here – I’m not a believer in a micromanagement timesheet approach that requires accurate measurement of time in 6 minute incrementals. Anything less than 15 minute intervals is entirely wasteful and creates too much administrative overhead. (Alternatively, if time recording should be done in increments of less than 15 minutes, then it should only be done in systems where the work flow, and the recording, can be done automatically. E.g., in call centres, etc.)

There are two common complaints that IT staff tend to have about timesheets:

  1. They’re a waste of time that could be better spent doing “real” work.
  2. The perception that they’re used by management to micromanage or even “punish” staff.

In any normal work environment, neither of these are remotely true.

Let’s look at each one to see why it’s wrong, and point out the counter argument to it.

They’re a waste of time that could be better spent doing “real” work.

I used to get this argument from time to time – heck, when I was just doing standard system administration work, I used to give this argument all the time. The simple fact of the matter is – it’s wrong.

When we work for someone, our work duties entail … what we’re told they entail. If part of that is timesheet entry, then that’s real work too. Call it “meta work” if you will … it’s “work about work”, but it’s still work.

They’re not a waste of time either. If a timesheet system is properly run, managed and reported from, it exists to allow the company to determine how resources are currently being utilised and how they’re trending. It also allows management to see how long tasks take. For IT staff themselves, that’s by and large the most liberating aspect of timesheets.

Particularly in companies that do consulting, timesheets fulfill another very important role – they allow the company to see how profitable they are, which in turn allows them to plan work cycles, which (ultimately for us) means they know they can pay us. This Is A Good Thing.

They’re used by management to micromanage or even “punish” staff

OK, there’s no backing away from this one – in some companies this has been the case. But those companies are relatively rare. Most companies want this information so they can work out how much it costs them (for in business, time is money) to do particular tasks – most good companies want this information so they can plan for personnel growth – i.e., to help normalise hours. Since (in Australia at least) it seems that practically 99% of IT people are on salaries rather than wages, this helps people get their personal lives back by having sufficient staff to meet business activity requirements.

Why you should be thankful for timesheets

Recall before I said that timesheets are liberating, because they track how long tasks take? I’ll bet at least 50% of people who read that statement chortle and think I’m off my rocker. Trust me, I’m not.

Regardless of whether you’re a consultant, or an administrator, or an operator, having empirical evidence of how long an activity takes can provide significant shielding from unrealistic expectations. Not only in my own personal experience, but talking to people who complain about unrealistic management expectations of tasks, there’s a very common link between management who request extremely unrealistic deadlines from IT staff across companies – it has a high tendency to happen in companies that don’t do timesheeting.

Why? Because the management don’t know how long things take. They don’t know how long an operating system install takes. They don’t know how long it takes to setup a lab AD server. They don’t know how long it takes to fix networking between branch offices. They don’t know how long it takes to do anything – not because they’re deliberately ignorant, but because they have no data available. That’s why, for instance, at 4pm on a Friday afternoon they’ll flick someone an email about needing to have a full Oracle development server ready by Monday morning when the hardware has been waiting idle for 2 weeks.

Guess how you make management understand how long things take? Timesheets.

If you work in an environment where timesheets aren’t done, stop kidding yourself that you’re lucky. You’re not.


Sorry, the comment form is closed at this time.

%d bloggers like this: