I recently finished reading the magnificent book by Rutger Bregman: Humankind: A Hopeful History. The book presents humankind in a different light from the traditional cynical point of view. By breaking down faulty psychological experiments and historical studies, Bregman offers an intriguing viewpoint: maybe we humans as a species are not egoistical and cruel, bound to evil if not controlled. Maybe we are ultimately altruistic and kind, and it’s the system around us that makes us miserable.
I was touched by the viewpoint of the book, and I also saw the many parallelisms between the theories of the book and the work I’ve done in the field of agile and DevOps. This inspired me to write this blog post where I will connect the dots between Bregman’s book and the DevOps movement.
For the uninitiated, DevOps - dev and ops together - is a philosophy that aims to bring together those that develop software and those who maintain it, and in this way enable healthier way of working and more customer value.
So, let’s get to it, and start with the biggest obstacle for DevOps.
The existence of silos
Organizational silos are an enormous problem in companies. You divide people into “excellence centers” or “cost centers” or whatever you want to call them, and the divide seems to make sense at the time. It’s so easy to group testers to QA, infrastructure people to IT operations, sales people to marketing and so on. All in the name of “efficiency”.
But if you think about the process as a whole, it’s not efficient at all. It’s like building walls between the people that need to regularly work together to deliver something to the customer. So why do we keep doing this? Can Bregman offer us some insight on the topic?
Well, it seems that we pick up groupings very easily. If you randomly given blue or red shirts to a group of toddlers, it does not take long for the kids to start grouping with people with the same shirt color, and even think of them as better than the other group. This effect is even higher when the grouping is verbally encouraged by authorities. Our empathy and our hormones make devs identify with other devs, testers with other testers etc. They also make us dislike the other groups.
Bregman also makes a point of the one factor that makes you less suspicious and less hostile towards different people: more contact. When different demographies are in more contact with each other, they also are much more empathetic towards each other and more willing to help each other.
Thus, if our leaders encourage siloing in certain way, it’s very likely it will become so. DevOps people are also familiar with “Conway’s law”, which dictates that the software you create will always look like the organizational structure you have. This is why silos are likely bad for your holistic architecture too.
So it seems that DevOps transformation is so hard because we need to fight against our natural instincts and learned biases. What we need to do is to find something else to identify with, something that also supports efficient value creation. This something would be the cross-functional, stream-oriented team that shares common goals, celebrates their victories together and learns from their failures together. That way we are able to direct our empathy towards a group that is able to produce outstanding results as a one unit.
These kind of teams utilize the psychology that Bregman explains: people of different background being in more contact with each other and finding something else to identify with than their previous silo.
But how can we then ensure that these teams then become high-performing units? What can motivate us? And what will de-motivate us?
The extrinsic incentives bias
It’s a known fact that “what you measure is what you get”, especially if there are bonuses involved. If you measure produced lines of code, you get a lot of (duplicated) code. If you measure number of commits, you get more (not meaningful) commits, and so on.
My ex-Nokia colleagues tell a tale about former Nokia bonus system: QA teams were given bonuses by the number of bugs found and development teams by the number of bugs fixed. And lo! at the end of a quarter, QA pushed to report even trivial things as bugs, and dev closed as much as those reports as non-issues. Also, you were not encouraged at all to take a quality first approach if you were given bonuses by fixing your own problems later.
This is a prime example of taylorism at work. The work of Frederick Taylor (1856-1915), “Scientific Management”, sounds promising on paper. You scientifically measure and analyze all parts of the system to optimise them. What happens though is that taylorism divides people into silos, forces them to work in a faster and faster pace, effectively killing all innovation, thinking and experimentation. Ultimately, it will also kill the quality of our work. This all happens because Taylor did one crucial mistake: he viewed workers as mere machines.
Humankind explains the psychology behind why taylorism is still living and breathing: “extrinsic incentives bias”, coined by professor Chip Heath. We assume that people around us work only because they get money out of it, even if we ourselves are motivated by something else. This cynical viewpoint encourages companies to see their employees as lazy, greedy and stupid. Then something called golem-effect activates: when we think about our colleagues in this way, we also treat them accordingly. This leads to people slowly beginning to act like it. The prophecy has fulfilled itself.
In reality, our intrinsic motivation is far more powerful than extrinsic. Bestselling author Daniel Pink condenses this into three points: autonomy, mastery and purpose. We are the most motivated when we are in control of what we do, when we can constantly improve and when we see the bigger picture behind the work we do.
DevOps tries to battle the incentive bias with the help of Pink’s theory. Higher motivation does not come with tight control. Instead teams are given increased autonomy over their own work and management does all in their power to support this autonomy. Teams form a vision of their own purpose and start working towards it. Enough time is invested to continuous learning and the daily work consists of experimentation, not strict requirements. This helps keeping everyone invested to the goal by diminishing the effect of the incentive bias.
But why experimentation? How is it better?
Homo ludens and experimentation
Homo ludens - playful human. The term that Bregman uses to describe our intrinsic curiosity and playfulness. Yet these traits are horrendously out of supply in today’s workplaces. We are so immensely bored at the office, that it makes us miserable. Control structures, deadlines, spreadsheets and pre-chewed tasks remove any chance of getting excited about our daily work.
This is part of the reason why DevOps encourages experimentation. It is way more motivating to actually try your hypothesis right away and get immediate feedback, instead of writing endless reports that end up into someone else’s backlog. Constant experimentation makes us think, which in turn fosters our innovation and learning and makes us better in what we do. It’s the opposite of taylorism.
Experimentation is also much more effective. When you get the feedback from your hypothesis immediately, you can also modify your plan to match the new information gained from the experiments. Humans are also extraordinarily good at learning from each other, compared to other primates. This is why continuous learning is so powerful in the workplace: once you learn something, you are also much more likely to share it with someone else.
But what keeps us from experimenting? Why isn’t it a common practice?
The paradox of power in hierarchical organizations
Bregman explains how power corrupts people, and how paradoxical that is. We tend to choose the most kind and the most compassionate people as our leaders, yet it’s still very easy for the power to “go into their head”. Once you gain power, you start to tell yourself stories about why you deserve that power: perhaps you are smarter, more hard-working or simply better than those below you in the hierarchy.
Once you honestly believe you deserve the power more than others, you again start to act like other’s are worse than you and you need to control and micromanage their every action. This kills experimentation. When leaders get corrupted by their power, they become bottlenecks, requiring all reports, plans and actions to be authorized by them. You cannot do rapid experiments with this kind of dysfunctional leadership structure.
What kind of answers do agile and DevOps have for this paradox of power?
Well, you remove the positions of power, as much as possible. Team decisions are encouraged. Flat hierarchies, blameless problem solving and sharing of knowledge promote working together instead of being dictated by someone else. For example in the Scrum-framework, the three roles (Product Owner, Scrum Master and developers) are created equal. All three have to work togethers as one team to accomplish the best results and all three have a piece of responsibility assigned for them.
Bregman also has the same view and explains how participatory (not representative) democracy makes people much more invested in the matters of their own towns. When you have an easy way to participate in decision making, you tend to become less cynical about the decisions taken. This also diminishes corruption and allows people to work together. You also feel much more responsible for doing something, if the people around you are also participating.
So, given all this, what to do?
The perception of people
If there is one key takeaway to pick from Humankind and it’s relationship to DevOps, it’s the perception of people. How you choose to think about them has a profound effect on the reality.
If you treat your employees and colleagues with kindness and see them as self-motivated, talented individuals - as human beings - and act accordingly, you will get results. If leaders give up control, they can instead focus on doing everything in their power to actually enable employees to succeed and work towards shared goals.
And if you think about them as automatons, you will get people who do the least amount of work acceptable, because that’s what you expect from them.
So, I encourage you all to think about the perception of people of you have in your organization. What kind of effect it has on your daily work and the motivation of your colleagues? What can you do to change this perception?
I’m an agile/devops fellow who likes to understand what makes people tick and why we act like we do.
If you are interested about the ideas behind this post, go and grab a copy of Humankind: A Hopeful History and leave a comment on what insights you learned from it.