In the last podcast I told you that focusing on 100% utilization is the wrong thing for return on investment.
But how can that be?
Are we not taught that utilization means productivity?
Are we not encourage to stretch our staff?
To get the most out of the staff salary?
Are we not even told its a good thing to sweat the asset?
Or listen at:
Published: Wed, 10 Jul 2019 15:32:28 GMT
Transcript
Traditional management techniques would certainly tell us that sweating the asset is how we improve productivity.
If we can get more work out of the same staff, then that's great right?
In the 1880's Frederick Taylor found that he could increase productivity though piece rate. He would break the work down into management bite-sized tasks, train the employees how to perform those tasks in a standard way and then incentivise an employee on how many times they can perform that task in a given period.
This is great right?
The employee works harder, they get paid more.
The company gets the work done faster.
Everyone wins.
Does this sound familiar?
Management decide how long a task should take to complete, then expect the individual to complete that task within a given period. The individuals remuneration linked to that task having been carried out?
Now this can work - for very repeatable bite size tasks. BUT it really needs to be thought about within the full Scientific Management rigor that Taylor advocated.
Software development is definitely not repeatable. By its very nature its "thinking for a living" (its knowledge work as briefly discussed in the last podcast). At its heart it is problem solving - something I will dig into in a future podcast.
Ultimately, even Taylor wouldn't advocate his approach for knowledge work.
He said "In our scheme, we do not ask the initiative of our men. We do not want any initiative. All we want of them is to obey the orders we give them, do what we say, and do it quick."
Now that is completely at odds with any definition of knowledge work where a key aspect is initiative.
And yet I see this everyday;
Trying to slice up a developers time to "fill" it as much as possible. They should always be at the keyboard, head down working.
Anything else means we aren't getting the best from them. Right?
And I'll admit to having made those mistakes myself in the past.
But the focus should never have been on the developers utilization.
Its the value that their work delivers.
The minute you focus on the benefit delivered by the work rather that the cost of producing it, then you start to think in a much better way for achieving better return on investment.
Don't worry, I'll come back to cost as part of investment in a future podcast - its obviously important in any conversation about investment ... but not as important as the benefits.
And it's a rare thing to measure the benefits of software development work.
We will normally track the work as a project, a row on a spreadsheet to be delivered. We celebrate the completion of the spreadsheet column, not the value that the work actually delivered.
We'll dive into that more in the next episode.