[Off-Topic] Obedience to Authority

Update: 11/20 I updated the videos to the Portuguese-subtitled versions on Vimeo.

Update: 11/10 I added a final section on a recent topic from Fred Brooks.

In my recent talks on organizations, I show a video of the Asch experiment. This experiment demonstrates how people go along with a group, even knowing that the group may be wrong. But for various reasons, they conform. For us agilists, think of a team doing Planning Poker or a Retrospective. When most of the team gives an answer, the minority “tends” to go with the group’s opinion. Of course, some hold their positions more firmly, but it’s not the norm. The norm is for us to conform, and this has to be taken into account. Watch to understand:

Asch Conformity Experiment from Fabio Akita on Vimeo.

More than that, we currently operate in organizations with outdated structures. Hierarchies, positions, bosses, procedures, policies. All of that — as I say in the talks — doesn’t work today. It only limits the organization as a whole. Does it bring short-term results? Certainly — that’s why everyone still uses it. In the long term, it creates a sick organization.

One of the factors concerns authority. In organizations of this type, when you have a “boss,” the effect is: “the responsibility for the tasks executed is not the subordinate’s, but the boss who gives the order.” It’s what we’ve all heard before: “I was just following orders,” or “I just work here.” Even when performing heinous tasks (Nazis torturing Jews, for example), one theory is that the people themselves could even understand that what they were doing was “wrong,” but since the decision of execution came from some authority, we don’t feel the same remorse or think better about alternatives or simply stopping the execution.

The one who demonstrated this was Stanley Milgram in the 60s. The BBC redid the same experiment, and you can watch my subtitled summary:

These are all real dangers that happen in our day-to-day:

• People conform very easily
• People don’t like to look wrong, so they don’t take risks
• People obey authorities, whether bosses or people with higher status in some way

Which is one of the reasons why many agility projects in particular fail. It’s no use simply saying: “the team decides the best path” if there’s still someone with veto power. If the veto is used even once, no one else on the team will take anything seriously. Current organizations limit people, limit their possible potential, limit any chance of motivation, limit individualization — in short, they turn people into robots. And the more an individual conforms to this structure, the more they become amorphous, practically a walking piece of meat.

So the only way out is to eliminate power hierarchies. Watch my introduction to this idea in the talk I gave at Rails Summit 2009 (video credits to @agaelebe, thanks for filming):

Organizations, as classical, closed systems, always tend to stagnate and collapse. It can take 10 years, but that’s what will happen naturally. Complex adaptive systems, on the other hand, tend to continue evolving, learning from small failures, refining their processes naturally. But that requires heterarchies, not hierarchies — spontaneously formed groups, with decentralized control. Hard to swallow? I fully agree — that’s why those currently in positions of authority should be a bit more literate before executing things. By the way, this is another point:

• People today deal with knowledge superficially: they prefer to “do” rather than “waste time” learning.

Dan Pink presented at TED about motivation. First, remembering: no one can motivate people, so don’t try. People motivate themselves or they don’t. The most companies and managers can do is demotivate them. That’s why the main thing is to stop getting in the way. What Dan says is the obvious: companies continue using archaic techniques based more on folklore than on science. The system of rewards and punishments doesn’t work. Understand:

He states that people need 3 things to motivate themselves: Autonomy — the desire to control their own lives; Mastery — the desire to become better at what they do; Purpose — doing something greater than themselves. What he describes, in reality, is nothing more than dynamic, interactive Agents in Complex Adaptive Systems. Agents interact with each other, cooperate and compete, evolve around “Strange Attractors” which are the group’s or company’s purpose or identity.

Agility is a natural evolution of old management processes. Democratic Organizations are the longest and most comprehensive step in an organization.

This article is just an introduction. Reread my off-topic articles from the last few months to understand more aspects of this.

Fred Brooks

I had the great pleasure of watching Fred Brooks at Latinoware this year. I have to say I was a little frustrated by the absent audience, because Brooks’ talk, which should have been full, had very few people, showing that most people don’t even know about him or aren’t interested in the subject, which is quite sad.

Brooks gave a talk about 2 chapters of the book he’s writing. So let me note that he didn’t present the full content, and therefore many things I speculate about may be explained in the other chapters.

The topic was about the importance of “someone” being the Master Guide of a project. He states that projects, especially large ones, need a Chief Architect or something similar to maintain the integrity of the final product. He gave examples like building an airplane by separate teams, where there were people who communicated with them all the time to ensure that the whole would remain integrated and consistent.

I agree with this explanation. It’s satisfactory and, in fact, complex system architectures don’t just “appear” out of nowhere from several people or teams working separately.

But there is an enormous caveat here. Depending on how you interpret this explanation, if you have the position of “Architect” or are certified in “Systems Architecture,” you may feel highly justified by a celebrity like Brooks saying architects are vital to a project. Well, you’re wrong.

An architect is nothing more and nothing less than a leader. This isn’t a position. It’s a condition earned by merit, not by position, certification, order, or anything similar. An example: the Linux kernel. No one assigned Linus Torvalds to the post of “benevolent dictator” of the project — he simply emerged from a need, people accepted his leadership, and if they were very unhappy, they could have just forked it and a new leader would take over.

Real leaders emerge, they aren’t placed. As a project like this grows, other leaders emerge naturally in each part of the project. The people Linus calls his “lieutenants” appear, people like Andrew Morton once was.

This is important: it isn’t a post of authority dictated from top down. It’s a condition acquired from bottom up. More than that, leaders evangelize their points of view, convince people, up to a point can even impose certain positions, but ultimately, when there is abuse of that position, the team around can and should reinforce their points, their values, or at the end of a fight without winners, choose to leave the project — and not conform and continue, as I showed above in the Asch and Milgram experiments.

This works extremely well in the open source world because it’s precisely a distributed environment, with no fixed hierarchies, no fixed positions, where people can move between the various sectors of the project, where there is discussion, where opinions are taken into consideration, where new ideas are tested and experimented. It’s the extreme opposite of how software is traditionally made in a company. A denser description is in the classic The Cathedral and the Bazaar by Eric Raymond.

Someone who considers themselves capable of starting to solve a certain problem begins taking the reins. People around begin to see value in this and can start to collaborate. The initial architecture undergoes revisions, changes, and it evolves. The “leader” of this project, probably the author, continues to ensure that the initial vision continues and that proposed changes — which may be better than their own — are duly incorporated, instead of the retrograde position “I didn’t do it, so I don’t approve.”

Understanding the open source world is the key to understanding agility and democratic organizations. They were born this way because of the environment’s limitations (people spread around the world, volunteers, lack of physical contact, the need to maintain code integrity, etc.). And more, leadership isn’t bossing. A leader doesn’t have the right to just bark orders. A real leader is a servant leader. He collaborates and helps the team, instead of ordering and saying how to do it. He influences, he evangelizes, he tries to expose more points of view, tries to seek consensus. Sometimes they need to make harder decisions, like going against the majority to ensure the project’s integrity. But do that too many times the wrong way and the team should remove them from their position. Emotional Intelligence, in this position, is as or more important than mere IQ.

So, yes, projects need visions of integration. But no, that doesn’t justify people “assigned” autocratically as the “architects.” In the best projects, this position will emerge. If the team isn’t in a condition to let a leader emerge and one has to be assigned, it’s already fundamentally broken. Good luck with that project.