Getting your money’s worth
Everybody wants to get full value for their money. I can pinch a penny as hard as the next guy, maybe harder. But I’ve learned in many ways and many contexts, the very things I do to get more for my money, often result in actually getting less. How can this happen?Let’s look at the case of time utilization of software developers. In most organizations, developers are under pressure to work harder and produce more–no matter how hard they’re working or how much they’re producing now. Many organizations expect overtime, most of the time. The more enlightened organizations merely expect “100% utilization” of their developers. They want to get every minute for which they’ve paid, even if they’re not expecting to get extra hours for free.
Where does this idea come from? From the concept of maximizing the return of capital investment in manufacturing machines. When you’ve got a costly machine, you may want it to be working as much as possible generating return on your investment. Of course, you’ve got to have some down-time so that you can maintain the machine. After all you spent on it, you want it to keep working for a long time. Therefore you have to take care of it.
Ah, but people don’t burn out like machines, do they?
Is it “hours” that we want? With machines, it’s easy to take the cost of the machine and divide by the number of hours it’s in use. But is it “hours of machine time” that we’re buying? Or does the return on our investment come from the ability to sell the results of those hours? What return do we get if we spend those hours producing the wrong thing? Or producing “too much” of the right thing–more than we can sell?
Ah, but people don’t produce the wrong thing, do they? And people don’t get stuck producing the same old thing when they’re pushed to hurry, do they?
What happens when we approach 100% utilization? Go ask your network engineer what happens when the network reaches 100% utilization. Actual throughput slows to a crawl, but network collisions and retransmissions skyrocket. Or think about how well your computer responds to you when the CPU reaches 100% utilization. The computer stays busy, but you can no longer request it to do what you want now.
Ah, but people don’t get mired in rework and rote work, do they?
We should know this by now. Tom DeMarco’s book, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency came out in 2001. I confess that I didn’t read it for many years, thinking I knew what it said. DeMarco makes many more important points than I’ve mentioned. I thought I knew the topic, but learned a lot when I read it.
The Product Owners look at slack as a way to evaluate whether the team is overloaded–and seek to reduce velocity until we hit slack consistently. Otherwise, we fear we’ll be paying for code debt, bug fixes, and reduced innovation that the team can’t really see until they come up for air.
We should all be so vigilant. It’s a very sharp knee in the curve when we reach 100%. As Dickens said in David Copperfield,
‘My other piece of advice, Copperfield,’ said Mr. Micawber, ‘you know. Annual income twenty pounds, annual expenditure nineteen nineteen six, result happiness. Annual income twenty pounds, annual expenditure twenty pounds ought and six, result misery. The blossom is blighted, the leaf is withered, the God of day goes down upon the dreary scene, and and in short you are for ever floored. As I am!’
The same is true of overspending our time.