Welcome to the first in what could be well over two articles on a matter of great importance and interest of mine: Productivity. Here I plan on giving my advice on ways to improve your productivity, based upon ideas of others that I’ve found useful, as well as ideas of my own. I am a software developer, and as such, will relate these articles to the discipline of software development. And yes, I just used the word “discipline” near the phrase “software development”.
The motivating factor in starting this series is that I used to work at one of the most unproductive companies I’ve ever seen. They spent over three years working on a project that shouldn’t have taken more than one year to complete, and weren’t close to a true ‘beta’ (i.e. complete functionality) when I left. I do not have answers to all of the productivity problems at this company, and by writing these, hope to force myself to find some. Prior to starting, however, I need to define what productivity is.
There seems to be confusion as to what productivity is, and how it’s measured. In my world, productivity is the measurement of how much you do in a given period of time. Specifically, the American Heritage Dictionary defines it as:
The rate at which goods or services are produced especially output per unit of labor
However, I will quite often hear something to the similar reported on business news outlets:
XYZ Widget Company reported an increase in productivity for the just ended quarter, thanks in part to the shift to a 10 hour work day.
Sorry, but that’s not an increase in productivity. It is working harder, not smarter. Let me explain a few reasons why I believe this is not an increase in productivity, and may actually be a decrease.
Let’s look at the fictional XYZ Widget Company with the assumption that they produce 1.2 widgets an hour. Over an eight-hour workday, that’s 9.6 widgets a day. If XYZ announces a 20% increase in productivity, it would mean they are creating 12 widgets a day. But if that day extends from 8 hours to 10 hours, itself a 20% increase, that washes out the productivity gain. XYZ is still creating only 1.2 widgets per hour.
To make things worse, if XYZ is a union shop, and the workers get paid 1 1/2 times their normal salary for those last two hours, it means XYZ is spending more on labor, which means XYZ is getting less for their money, another way of saying productivity at a company level declined.
It only gets worse from there. If the creation of widgets is a manual, human-based process, you have to factor in that as humans tire toward the end of the workday, and produce less as they get tired, which means that not only is XYZ paying more for labor, but they’re getting less in return.
Now let’s assume that the widgets that XYZ is producing is actually a software product. The longer software developers work, the more defects (sometimes called ‘bugs’) are injected into the software. These defects must be fixed when found by QA, meaning the developer has to stop the new task they’re working on to fix the old task they did not properly complete. Not only does that add development time (and thus reduced productivity) to the old task, it delays the new task.
To put it simply, working more hours does not mean an increase in productivity, and usually means just the opposite.