I recently posted this question on Twitter:
My friend Daniel answered:
I didn’t see that one coming. Okay…
I’ve been working as an Agile Coach, Scrum Master, consultant and trainer for large organizations like banks, insurances, automotive companies, medical device manufacturers and software development houses. I’ve seen the same dysfunctional patterns repeat over and over again. So I surely have an opinion on that. Is my analysis laser-sharp? Well, you decide.
The machine metaphor
We need to go way back in history to understand what happens in organizations today. Up to the first part of the 19th century, development of products was mainly done by craftsmen. Products were tailor made for the customers. Markets were mostly local.
The game changed with the industrialization. A different problem needed to be solved. Instead of tailoring a product for the individual customer, the question became: How do we produce the same product in large numbers? How do we ensure an acceptable quality, efficient and at low cost? How do we conquer new markets, once a market gets saturated?
The most important technical innovation that made a solution possible was the assembly line. Companies could now hire uneducated workers at low cost. All they needed to do was teach the workers how to play their part. Every employee working at the line was supposed to repeat the same kind of actions over and over again.
In a way, those employees acted like parts of a machine. And like parts of a machine, they were considered replaceable.
But there needed to be someone overseeing production. Someone with more knowledge. Who could make the right decisions when something went wrong. That's how 20th century management was born.
The job of the managers was to control that the machine was working in order. Issue a command if necessary. And control the output. The managers were the users of the machine.
The machine metaphor as an explanation of how the world works had been around in science and philosophy long before.
But now, it also started shaping how people thought about product development. And it has been ever since.
The machine metaphor is ubiquitous. We can hear it in
everyday speech: “things are humming,” “well-oiled,” “on
autopilot,” “firing on all cylinders,” “re-engineering,” and
“I’m just a cog in the wheel.” Viewing an organization as a
machine shapes our perceptions, expectations, and actions
profoundly.
Organizations as Machines, Organizations as Conversations
I will highlight three typical dysfunctions that result from it next.
Dysfunction #1: Command & Control
The idea that it makes sense for a manager to control the work and assign tasks to workers relies on the following assumptions:
- The manager has an overview of the situation
- The manager has more knowledge than the worker doing the job, concerning the task
- The task can be assigned to a single individual
These assumptions were fulfilled in industrial production. They may still be useful in restaurant kitchens. But they can hardly be applied to knowledge work.
For innovative products, software development requires a whole group of creative people to exchange ideas. This is the best way to solve unknown problems that exceed the capabilities of a single individual that humanity knows.
Dysfunction #2: Optimizing utilization
At the assembly line, optimizing utilization of individual workers led to an optimization of the overall throughput of the system. Likewise, in many organizations today, employees work on multiple tasks or even projects at the same time. Yet the hope that a utilization close to 100% will lead to maximum productivity is often in vain.
Counterintuitively, the linear relationship between utilization and productivity doesn't hold up in environments with high variability in the arrival rate and size of work items. Note that this isn't my personal opinion. You can prove it mathematically, using queuing theory.
It is not the case that everything goes fast and smooth on the highway until just before 100 percent capacity of cars on the road. Rather, things slow down and gridlock happens well before capacity is reached.
[...]
With the misunderstanding “delay only starts when the highway is 100 percent full, ” there is a misguided focus on trying to improve cycle time by increasing resource utilization—getting the people in product development to be more busy, usually by more multitasking. This is the local-optimization thinking mistake.
[...]
As utilization goes up in a system with lots of variability, average cycle time gets worse, not better.
Large Scale Scrum on Queuing Theory
Dysfunction #3: Single function silos
Knowledge silos can't be avoided in large scale organizations. Due to the many possible communication relationships, each employee only communicates with a limited number of his colleagues. Software architecture styles like microservices even promote the reduction of dependencies between teams as a key benefit.
Yet there is a problem with how organizations set up these silos. Assembly line workers repeated the same activities over and over again. Departments in organizations follow that model: they have a single function. The QA department, the IT department, the Business Analysts etc.
Do one thing, and do it well. What has worked for the UNIX philosophy became a problem for departments that needed to cooperate to make any progress with the product they built together.
The consequences are:
- delays when exchanging information
- local optimization based on department specific goals
- individual bonus systems that stand in the way of overall progress
Conclusion
I have highlighted three dysfunctions of large scale organizations. There are many more. But even after 18 years in the industry, I still believe there's a lot we can do about it. And we need to have patience. There's a lot of unlearning and learning that needs to happen.
Let us build a better, more inclusive and sustainable future together. Inside and outside of tech.
And one final remark: are you happy now, Daniel ;-) ?
Top comments (1)
very interesting; from my pov the title of c) sounds very promising, too. ;)