It is a great selling point for many networking vendors to point out exactly how much money you lose when networks aren’t performing to peak efficiency – and there are real savings from faster round trip application response times.

But as Mark Gibbs at Network World points out, when you start to equate worker productivity to network performance, it gets a little hairy.

The problem with these kinds of analyses is they aren’t identifying real costs because you can’t equate a solid hour of an employee’s time with an hour of his time that’s broken up into chunks of minutes or even seconds over a long period. 

If you are calculating the value of an employee it has to be on the basis of actual productive work done and revenue derived from that work.

So, for example, shaving 2 seconds off login times each day may make people slightly happier, but those two seconds really don’t “add up over time.” In many occupations, it is not the volume of transactions that determines the value the employee brings to the company – the creatives in marketing, the go-getters in sales, the brainiacs in R&D, and the psychos in management typically aren’t affected by the extra minute of time that it takes to log in each month.

This type of mentality – that all employees earn X dollars per second, and any second they are not working costs the company money – is a bit alien to me. And by “alien” I mean the kind of alien that enslaves the human race to make them build statues to their leaders and orbital brainwarp lasers. Yes, work ethic is important. But micro-managed employees are stressed and unhappy, and stressed and unhappy workers make mikstakes.

Of course, if you’re waiting 1 or 2 seconds for transactions that you do repeatedly, that does save time – and this is where latency actually produces a serious problem. Delay, the way a human normally thinks about it is a function of latency times the number of transactions. Focusing on latency is good, but focusing on the end-user experience is better – a lightning fast pipe doesn’t mean much if you’re sending data across it 30 to 40 times more than you have to.

For example, any automated system, like, say, algorithmic trading, will receive tons of value from lowering latency considering that robots, like interns, are well suited for mindless, repetitive tasks because they have no souls.

But back to the point; there are some jobs in the organization where network delay actually does affect productivity. I remember working at a medium sized supermarket retailer in the Northeast straight out of college as a data entry clerk. We used a piece of Java-based database software that was slow as hell – it would take seconds just to switch fields between different pieces of data entry on the same form. If I knew then what I know now, I’d probably say that the problem was that the software was designed for a low-latency LAN and had tons of connections through a higher-latency WAN. This caused tons of problems – what could have taken minutes took hours, what could have taken hours took days.

Of course, back then I was just a data entry clerk. I decided not to bring this up with management, considering that I didn’t want management to think about ways to improve network response times. After all, I had figured out by week three that my employment was preconditioned on management never figuring out that since we were just entering data that someone else printed out from Excel spreadsheets sent in by regional managers, the entire department could have easily been replaced by a very small shell script.