The Productivity Trap
Last time I looked at one of the common traps an organisation can fall into - the solution trap. Going straight for a solution rather than stopping and thinking about the problem first. Today I'd like to explore another common trap - the productivity trap. Productivity is usually seen as a good thing. The more productive we are, the more we get done with the same level of investment, so we are better off. The more time we spend on productive tasks (and the less we spend on unproductive tasks) the better.
Generally that is the case. The difficulty comes in the definition of what is a productive task. Working directly on something that is valuable to customers and will make money for the organisation is clearly a productive task. But what about things like maintenance? Upgrades? Training? Process improvement? Exploration of new ideas? Where do you draw the line between a productive task and a non productive task? And why does it matter?
Many organisations take a very narrow view of what a productive task is - something directly related to delivering customer value. New features. That sounds fair enough. The organisation exists to deliver value to its customers (well, actually it exists to make a profit, which it does by delivering value to its customers) so new customer features is clearly productive work. What about the rest though?
If we take a narrow view of productivity and limit it to just the things that directly deliver customer value, when we optimise our organisation to maximise productive work and minimise non productive work, we then tend to spend most of our money on delivering new features and everything else gets money spent on it grudgingly and only if it's really urgent. After all our focus should be on productive work right?
But look at those things we just left off our productive list - maintenance, upgrades, exploration, training. Under our narrow definition of productive, none of those things count. But what happens when we underspend on them?
Underspend on maintenance and the infrastructure you rely on to build new product features starts to suffer. In a software development world, the code base becomes clogged with ugly code warts because no one wants to spend money on refactoring. Test environments suffer, development environments become unreliable. If you are building physical products, a maintenance underspend means your production equipment becomes unreliable. Either way, your cost of production goes up and you end up delivering less and less. Underspending on maintenance destroys future productivity. I worked for one organisation where underspending on maintenance lead to a code base that was so badly mangled that something simple like changing the text on a screen would cost upwards of $100K. Another organisation ended up with a key component with so much technical debt that it had to be rewritten from scratch, at the cost of hundreds of thousands of dollars and worse, an 18 month delay to the next release.
What about upgrades? Again, no upgrades and your equipment goes out of date. New features or productivity improvements that are in the new version (and are available to your competitors) are not available to you. Underspending on upgrades also destroys future productivity.
Training? Same thing only this time it's your people who go out of date and can't make use of new technologies. If you are lucky, underspending on training just means that all your good people leave for somewhere they can develop their skills. If you are unlucky, your people stay and you are stuck with an outdated, unmotivated, unambitious workforce. Either of those outcomes is not great for future productivity either.
Process improvement? Exploration of new ideas? Same thing. They don't directly contribute to customer value but they are enablers for future productivity.
Most organisations will tell you that they do in fact spend money on this non productive stuff. And they do. Just not nearly enough in most cases. Money is spent but it is spent grudgingly and when push comes to shove and a decision has to be made on whether to spend on a new feature or some maintenance, guess which one gets the cash?
There is often a plan to spend money on maintenance and the like but in reality, there are always more new features to build than there is new feature budget to build them, so the maintenance budget gets raided to pay for them.
The organisation is in the productivity trap. New features get prioritised, maintenance type work gets systematically deprioritised and suffers from chronic underspend. Infrastructure, skills and processes start to decay. Quality suffers. Build and test time increases and productivity drops. Drops in productivity mean fewer new features delivered and even more pressure to deliver customer value, so the maintenance budget gets raided more and more, and so the cycle continues until things become so bad that the organisation throws up its hands in disgust and decides to rewrite the whole thing from scratch. Or goes bust. I have seen both happen.
Generally this sort of thing only happens to IT companies. Not companies that make physical things. Companies that make physical things generally understand the importance of maintenance and upgrading equipment because they can see the impacts of poor quality directly. The cardboard boxes your box making machine turns out have ragged edges. The parts your machine spits out don't meet the specifications. But for IT companies, a lot of the impacts of poor maintenance are hidden. And they accumulate slowly. Your developers spend a few hours more here and there, struggling with poor environments. It adds up slowly. It becomes the new normal. That organisation where it cost 100K to change text? It wasn't always like that. It took 5 years of steady decay before it got to that point and by then it was considered normal. No one batted an eyelid when the quotes came in. That was just what it cost.
The productivity trap is very easy to fall into if the impacts of poor maintenance are hidden.
How do you get out of it? It's easy. Just redefine what productive means. How about this for a new definition - productive work is work that directly delivers customer value or enables future productivity gains. Now that enablement stuff is on an equal footing with the new features. Should we build the new feature or fix the environment? One will bring in X customer value, the other will improve our future productivity, which is worth Y. You can make the call based on the value both will bring to the organisation rather than just dismissing one as unproductive.