Work: being productive… or keeping busy? (part 2)

(NOTE: reading part 1 first may be a good idea. :))

To explore the “acting busy” vs. “doing actual work” theme, I want to share (without the sordid details, of course) a situation I’ve been in.

A few years ago, I worked as a sysadmin in a company which had about 20-30 Linux servers, and about the same number of Windows (NT 4 and 2000, at the time) servers. There were two separate teams of sysadmins, one for each type of servers, though both teams had the same boss, and worked in the same room.

The two teams, however, had a very different philosophy of work…


First, except for the initial server installations, almost all the work of the Linux team was made remotely, using ssh. Except for coffee/lunch/toilet breaks, we were at our desks for most of the time. On the other hand, the Windows team did their work inside the datacenter, physically on the servers (at the time, remote desktop utilities were less used than they are today).

When the Linux team encountered a problem in a server, we would figure out what the problem was, what caused it, and how to prevent it from happening again in the future - most problems, indeed, only happened once. The Windows guys, however, were of the philosophy that the only thing that mattered was to quickly make the services available again - by rebooting. If it happened every week - or, indeed, every day, tough. They had, they believed, to be getting paid for something, right?

The result of this was that we Linux guys were, most of the time, calmly sitting on our desks, and had a lot of free time (which we sometimes used for research, for staying informed about our field of work, for trying out new solutions on test servers, and so on - but which we also used, sometimes, simply for resting, or for browsing non-work sites). The Windows guys, on the other hand, were often inside the datacenter, most or all of them at the same time, putting out the latest “fire” - which would likely repeat itself in a couple of days, since they never attacked the cause, only rebooted the servers. And when it happen, they made sure they looked very alarmed - and that everyone saw them (there were other non-sysadmin teams in the same room) running to the datacenter to solve the latest crash.

The Windows servers had a lot of downtime, but the Linux ones’ was almost nil.

Now… guess which team the bosses preferred. Which team was seen as “competent” and “hard working”. Which team got promotions, pay raises, and shiny new laptops.

Related posts:

  1. Work: being productive… or keeping busy?
  2. Internal Jabber servers
  3. Work: why a good sysadmin has a lot of free time
  4. Why I’m not a Sysadmin anymore
  5. Ubuntu vs SUSE

4 Responses to “Work: being productive… or keeping busy? (part 2)”


  1. 1 Sparkling

    Noone ever said life was fair. The Windows team was seen as the hard working team.

  2. 2 4_ever

    Well, one solution to this kind of problem is being pro-active, if everything is working ok, if you have free time to upgrade your knowledge, apply that knowledge to the systems.
    Try to suggest new ways of doing things, migrate things to the stable systems, give more options to the users, find something that it is not being done and do it.
    Of course, some people must be kept informed of what you are doing, consider it like publicity, it is the lesser-evil.

  3. 3 Dehumanizer

    4_ever: I said that I already did that (looking for things that could be improved, implementing new stuff, etc.), to an extent. But that still didn’t take up all of my free time. If I can do something in 10 minutes, I do it in 10 minutes - I lack the ability to extend that to a week or too (and appear extremely busy during all that time), that apparently most people have.

    Besides, at that particular job, improving things wasn’t encouraged - much the opposite. It upset the status quo too much. That was one of the reasons (the other, of course, was a permanent excuse to appear busy) why they never solved the many problems with the Windows servers, only rebooted them.

    I guess they thought - and they were probably right, in a way, which is sad - that if everything ran smoothly, management would then believe that there wasn’t need for the entire teams, and start downsizing. So they ensured a continuous source of work by not doing anything about the causes of problems.

    If that meant downtime and bad service, tough.

  4. 4 Joao

    The aweful

    I’ve even seen this taken a step further. I’ve witnessed various people in management and leadership positions actually tailor make problems so that they could make a large amount of noise in the process of showing everyone ( directors especially ) how good they are at fixing problems and running everthing. Of course it’s easy to fix problems that you orchestrate yourself.

    But then how does one actually go about correcting these injustices? Beat them or join them?

Leave a Reply




Creative Commons Attribution-NonCommercial-NoDerivs 2.5 Portugal
Creative Commons Attribution-NonCommercial-NoDerivs 2.5 Portugal