Time isn't Money

Traditional management wisdom tells us that 'time is money'. However, during the years I have come to find that there is no conflict between learning and productivity, even that productivity increases as learning increases. To me this is such a no-brainer that I have had some difficulty in understanding why some managers might be against learning.

In fact, on closer inspection, the managers I came across were not actually against learning, they are just against 'wasting time' and unaware that their push to save on wasteful activities such as study time was in fact destroying productivity.

As Agilists we know that we should 'watch the baton, not the runners', a parable that signifies that man-hours are not a very good measurement of productivity in knowledge work. This is because our product is more like the baton in a relay race than a product on a conveyor belt. You would consider someone pretty stupid if they were to comment on the fact that the first runner in the relay race had failed to complete the race.

It is why we agree with the principle behind the Agile Manifesto that 'Simplicity--the art of maximizing the amount of work not done--is essential'. There is a 'hard' and a 'soft' side to the antithesis of the 'time is money' hypothesis.

The hard argument

The thing is, a major lag for creative production is lack of knowledge. The sooner you can address this, the more it contributes to productivity. In my experience, the effect in software development is so strong that you are better off regarding software development itself as a learning process than as a production-line process. That means two things:

• learning is the most time-saving activity you can do and
• time-based management of creativity is pretty pointless - that works for conveyor belts and other simple, predictable 'doing' work.

In practice:

• I have seen a team that started to learn Test Driven Development, actually save the time they had spent in learning, in bughunting that they did in the same, two week sprint!
• Thinking, not typing is what determines programming speed. Tim Ottinger's thinking exercise is: "how much time would it take you to retype yesterday's code?". Usually the huge majority of programming is thinking. Better thinking will bring much more improvement than better doing.
• If learning leads to quality or speed increases, the law of compound interest applies. This says that if a day of learning delivers you a 5% quality/speed increase, you will earn back your investment in 14 days. There are very few situations imaginable where you cannot afford that delay.

source: https://www.business-case-analysis.com/interest.html

source: https://www.business-case-analysis.com/interest.html

The soft argument

Like so many complex tasks, development pretty much IS learning. At the beginning of most development tasks, you only really know the best solution to your task once it has actually been made.

Moreover, there is mounting evidence that for knowledge workers, learning is one of the primary motivations for doing work, ranked higher than extrinsic motivators such as pay. So even if learning were a waste of time, a certain amount of learning would be necessary just to keep people working.

The Elephant in the Room

Now before you go off to use these arguments to your boss, consider that often it is not a good idea to try to argue your way to more learning-centric practices (or in fact arguing your way to anything at all). Convincing a manager to refrain from her 'time fetish' is bound to fail, unless you propose a good practice to replace it - the Blue Elephant principle. Luckily, there are a number of learning practices that look like process improvements - a win win! Now your boss can show off a 'New Best Practice', whilst actually promoting learning.

In a future post, I will describe some of these cyclical learning models, why we would want to use them and a few examples like DIBBS and Kolb's Experiential Learning Theory.