Labour Theory of Value: Why It's Instinctive and Enduring, and how it shapes Product/Engineering Delivery
In a world where time is often mistaken for value, it’s essential to understand that expertise—not effort—is what truly drives results.
My friend owns a local car repair garage…
It’s a testament to my car's quirks that I’ve spent so much time at the garage that the mechanic is someone I call ‘friend’, but let’s move on from that!
Anyway, he takes on a lot of apprentices and from what I see he’s an excellent tutor.? The last time I spoke to him… (I’m not joking, my car has had new brakes, clutch, power steering and ENGINE in the last few years.? But I digress). ? The last time I spoke to him we were talking about apprentices and he shared a hard lessons he has to teach them.
Early on when they are really struggling they will spend a day working on a car, getting it wrong, forgetting something, spilling oil and having to spend time cleaning it up and banging their thumbs with a wrench and fiddling with a light bulb fixture.?
When the customer comes to collect the car and pays for it, the apprentice thinks it’s ridiculous and not worth the effort for the mere ￡75.? They think that the effort they’ve put in deserves multiples of that.? They go home exhausted (note: puns are always intended).
As time goes on they learn hard lessons, build up a wealth of experience they know where the pitfalls are and how to avoid them and become more content with the time/money exchange, but inevitably, as sure as smoke follows a blown gasket they start to do the following:
They’ll be fixing some brakes,? and when the customer arrives to collect they’ll say something like ‘I tightened up some loose spark plugs, checked the oil and refilled your water for you, don’t worry no charge, it only took 5 minutes’?
They have a Labour Theory of Value. ? The experienced garage owner has to teach them that the only reason that job only took 5 minutes or indeed the only reason you knew to do that job was due to the training and investment you put into gaining that expertise. The value exists where the customer says it is, the relation to time and physical effort is incidental.
In the world of software development, much like the mechanics in the garage, engineers often conflate the time spent coding with the value of the result. A junior developer might measure their success by how many hours they’ve spent coding, debugging, and reworking an issue, much like the apprentice who feels that a full day’s hard labour must be worth more than their salary. The reality is that time isn’t a direct reflection of value delivered.
It’s easy to fall into the trap of measuring effort purely by "days spent" or "hours logged." We often hear conversations around how long a work item took or how many stories were completed in a sprint. These measures help inform the discussion but they are blunt instruments. They fail to capture the essence of what’s truly valuable: the outcome, the problem solved, the efficiency gained by the end user.
Just like the mechanic tightening the loose spark plugs in five minutes, the more experienced software engineer may solve complex problems in mere hours—not because the problem is trivial, but because of the investment of years of learning, experimenting, and failing. The solution time may be short, but the value delivered can be massive. The engineer's skill and expertise make that quick turnaround possible.
Yet, we often don’t reflect this in how we measure effort in software engineering. A 30-minute fix that prevents a critical system outage might be far more valuable than a week spent adding a new, seldom-used feature.?
Shifting the Focus: Measuring Value over Effort
This brings us to a crucial question: how do we better measure value and effort allocation in software engineering? Effort, in itself, can be a misleading metric if taken in isolation. We need to shift focus toward the impact and value the work delivers, rather than simply tracking the number of days or hours an engineer has worked.
These are the questions we should be asking, and they often have no direct relationship to the number of hours logged by an individual or team. The senior engineers who’ve mastered their craft will know which knobs to turn, which bugs to squash, and how to avoid roadblocks before they appear—all of which take far less time than it might for a less experienced team member. But the value they provide is exponential.
In both car mechanics and software engineering, it’s not about the time spent but the value delivered. How do you measure the impact of your work?