A few days ago Derek Huether started a discussion on his Criticalpath blog about “Theory X vs. Theory Y” and asked for feedback who believes in what: Do you prefer command-and-control or do you believe in team empowerment?
It’s an interesting topic, as the question touches the fundamental disagreement in today’s management approaches. I recommend to have a quick look at the article and the comments below it.
So what’s the answer?
When confronted with two such polarizing choices (which both seem justifiable), a typical reaction is something like “yeah, well, it depends, somehow a combination of both, maybe”.
Well, probably correct. But unfortunately that doesn’t really help. Derek also highlighted the issue by asking what people “believe” in. Can that really be a matter of belief? Shouldn’t we have an understanding about management which is substantiated in a way that we know what and why we’re doing?
The most important thing to know about methods is why they worked for somebody else. So let’s look at the backgrounds of X and Y.
X vs. Y
Theory X resembles a lot of the ideas that served Frederick Winslow Taylor as a basis for his approach of Scientific Management, published in 1911 and first used by Ford’s Model T production.
Basically it expresses a fundamental mistrust in people doing work as employees. The assumption: What they produce is not theirs, so they’re only interested in the money they receive and they will try to get away with as little dedication to the job as possible.
For management to stay in control this must result in a strict command-and-control approach: Tell people exactly what and how they should do it, and verify compliance with the given orders.
In contrast, Theory Y reminds more of the idea of man that the agile approaches follow. People and teams act responsibly towards an agreed goal, and they are able and willing to organize themselves. Empowering the team is considered more productive for problem solving and creativity than command-and-control.
When does X work?
As said above, the philosophy of Theory X dates back a hundred years and aimed at industrial manufacturing. What are the characteristics of that?
- There is exact knowledge upfront about what has to happen. E.g. the process for assembling a car is precisely known in advance.
- The human beings in that process fulfil a function – the function stays the same even if people are replaced.
This kind of work – i.e. routine with only few (if any) unknowns – can in principle be executed with command-and-control.
Having said that, I have my doubts that even in these environments a pure command-and-control approach is the most productive choice. While it is necessary to some extend, e.g. Toyota already years ago allowed their workers to stop the production line if they find a problem with the car they currently assemble – the management counts on people’s responsibility and dedication to a quality product.
When does it have to be Theory Y?
Is Theory X and pure command-and-control transferable to the world of projects and software development? Not really – for three reasons:
1. Software development is about solving problems, which is unlike routine work. The “one best way” how to solve a problem can’t be defined and commanded upfront – the knowledge is simply not there (if one knew everything, it wouldn’t be a problem).
2. In contrast to Theory X, the vast majority of people in the project business definitely have a broader motivation. They do not only work for money, they like the intellectual challenge, being creative and they care a lot about the outcome they produce.
3. A team solving a problem is a dynamic system, and an individual’s contribution is beyond a mere function. A person in a team influences both the way how people work together as well as how the solution is found. If you replace a person, the team will afterwards be a different one.
These aspects are dynamic and can hardly be controlled from outside the team. This is why problem solving teams in fact work like a feedback control system: Given the right feedback, teams can and will do a lot of the adjustments that otherwise a commander would need to order – but here teams do it better, because they know and feel more than any commander outside the team ever could.
So does that mean that you can or should abandon teams to their fate and just wait until they come back with their result? No, probably not. Here’s why:
Theory Y is – as the name says – a theory, which means it assumes ideal circumstances. However, the world out there is not perfect, and neither are teams. Things that may not fall into place by themselves are e.g.
- priorities (e.g. time-to-market is key for client, but team considers a refactoring more important)
- team doesn’t make progress as problem is too difficult (for this team or in general)
- team doesn’t arrive at productive team processes (e.g. requirements definition)
- hidden agendas (e.g. trying out a new exciting technology)
- solutions more complex than necessary
- … and more
This is why leadership is important. Leadership needs to help ironing out any inefficiencies a team may run into (both team internal and considering the project context). It doesn’t necessarily need to come from one person in charge of management – depending on the team there may be different people ensuring leadership in their respective areas.
In any case, this kind of management is basically another source of feedback for the team. It differs from command-and-control in the way that it doesn’t dictate internals to the team. A problem solving team needs to grow and stay intact in order to be productive.