In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why of the podcast. Over the coming episodes, I'll take a deeper dive into the themes of the pitch and why they made the cut. In this episode, I want to take a deeper dive into the management practices of yesterday - where they came from and why they gave us success yesterday but are failing us today and certainly not fit for tomorrow
Or listen at:
Published: Wed, 30 Nov 2022 16:51:00 GMT
Links
- Episode 150: An updated pitch for the podcast
- Wikipedia: Scientific Management
- Wikipedia: Deterministic System
- Lumen Learning: Principals of Management
Transcript
Hi. In episode 150, I reintroduced the series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes and almost 33 hours of content and updating the "why" of the podcast.
Over a number of episodes I'm taking a deeper dive into the themes of that pitch and why they made the cut.
If you've not had a chance to listen to the pitch, it's worth pausing and going back to episode 150 for context.
In episodes 152 to 154, I talked about the business side of the pitch. Almost half of the pitch was devoted to the business context that we are doing our Software Development in and why our organisations are under so much pressure to change - and how each of our organisations needs to embrace change as something they do rather than something that happens to them.
I've now moved on to exploring the second half of the pitch, the actual Software Development part. In last week's episode, I talked about how Software Development was a young, evolving field - a long way from achieving maturity and as such, needed support from organisational leaders to learn and improve. I also touched on the courage needed by those organisational leaders to acknowledge and change their practices to support that - changes to management practices that gave us success yesterday but are failing today and certainly not fit for tomorrow.
In this episode, I want to take a deeper dive into those management practices of yesterday, where they came from and why they have brought a success previously.
From the pitch:
"We have tried to use our "tried and tested" approaches to manage our software development, but much of our management techniques rely on techniques pioneered two ages ago - back in the Age of Steel and Heavy Engineering.
We incorrectly assume that, those techniques that have served us so well, techniques that have served our parents and grandparents, will give us the same level of success in this new age.
We are learning that this is not true.
These techniques rely on the work being deterministic - the work being knowable before we start it.
By applying deterministic practice over an emergent, unknowable domain, we attempt to exert a level of control over risk and outcomes that simply isn't possible. In attempting to do so, we give a false representation of the world - one that we would like to exist, but one that simply cannot be.
Not only do these techniques fail to take advantage of this new age, they actively cause our organisations harm."
So where do these tried and tested approaches, our practices of yesterday, come from?
Much of our management techniques stems from the work of Frederick Winslow Taylor, and his contemporaries, around the start of the 20th century within the Age of Steel and Heavy Engineering. While often villainized by today's standards, his work on the Scientific Management, also known as Taylorism, was groundbreaking at the time and is the ancestor of many of the management techniques that we recognise today.
Note that Scientific Management and the Scientific method that I often discuss are different things. The Scientific Method is an approach to learning from experimentation. Scientific Management is an approach to improve labour productivity.
From Wikipedia:
"Scientific management is a theory of management that analyzes and synthesizes workflows. Its main objective is improving economic efficiency, especially labor productivity. It was one of the earliest attempts to apply science to the engineering of processes to management."
Frederick arrived at scientific management through examination at various kinds of manual labour via empirical studies. Again from Wikipedia:
"For example, most bulk materials handling was manual at the time; material handling equipment as we know it today was mostly not developed yet. He looked at shoveling in the unloading of railroad cars full of ore; lifting and carrying in the moving of iron pigs at steel mills; the manual inspection of bearing balls; and others. He discovered many concepts that were not widely accepted at the time. For example, by observing workers, he decided that labor should include rest breaks so that the worker has time to recover from fatigue, either physical (as in shoveling or lifting) or mental (as in the ball inspection case). Workers were allowed to take more rests during work, and productivity increased as a result."
Frederick proposed many changes to how the work was carried out and largely can be credited with creating management.
He focussed on the belief that making people work as hard as they could was not as effective as optimising the way the work was done. This effectively moved how the job should be done into the hands of managers. Knowledge was moved into the hands of the management. The workers were then told what to do, how and when.
From a course by Lumen Learning on the scientific management:
"Scientific management has at its heart four core principles that also apply to organizations today. They include the following:
* Look at each job or task scientifically to determine the "one best way" to perform the job. This is a change from the previous "rule of thumb" method where workers devised their own ways to do the job.
* Hire the right workers for each job, and train them to work at maximum efficiency.
* Monitor worker performance, and provide instruction and training when needed.
* Divide the work between management and labor so that management can plan and train, and workers can execute the task efficiently."
I'll provide a link to the Lumen Learning training course in the show notes.
What Frederick did was what we would now understand to be time and motion studies to improve the flow of an operational process with the best practice being arrived at - and the work is expected to follow that best practice to the letter with any deviation being seen as suboptimal.
In today's world, this will be recognised as command and control management, where the manager knows best and the worker acts in a similar way to a subservient drone.
The Lumen Learning article I referenced earlier talks about McDonald's restaurants, famous for low prices and fast food, for using this style as they focus on efficiency and productivity.
This is deterministic work. We know ahead of time the exact outcome we want. We know ahead of time the exact way that it should be done, what is required and how long it will take.
Wikipedia describes deterministic systems as:
"a system in which no randomness is involved in the development of future states of the system.[1] A deterministic model will thus always produce the same output from a given starting condition or initial state."
With the moving of pig iron, Frederick had a deterministic system in which he could remove all randomness from the operation and have confidence they could determine all aspects of the work ahead of time.
And it is this deterministic nature that puts the management style at odds with the very non-deterministic nature of Software Development or indeed any knowledge work.
In contrast:
Before the work commences with deterministic work, we know the expected outcome - with Software Development, we have a hypothesis of how it will address a business problem, but we don't know the exact outcome
With deterministic work we know exactly how much effort was required - with Software Development, we can make a guess, but we'll always be wrong, the question is by how much
With deterministic work we can provide a prescriptive process for the worker to follow - with Software Development, we provide the environment best suited for the work to succeed
And thus why I say in the pitch that those approaches derived from that command and control approach are not suitable for management of Software Development and why it will actively cause harm and negative effects.
The world of the 20th century, and indeed right up to the current date, are undoubtably a better place for the work of Frederick Winslow Taylor. There are many good things to take from his work. But trying to apply a management style originally developed for better efficiency of moving pig iron to Software Development is not one of them.
Attempting to use the manager knows best approach simply limits the team and de-motivates them from providing their best.
So you may be asking, why isn't Software Development more deterministic?
Why do we have so many unknowns?
Why can't we make it as deterministic as moving pig iron or flipping hamburgers at McDonald's?
And this is something I want to take a deeper dive into next week. In next week's episode, I want to take a look at the Cynefin framework, which I find is a good way of understanding different types of work.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.