This article was co-authored by Pieter van der Meché and Jutta Eckstein.
Many agile teams suffer from the mismatch of agile and organizational leadership with the latter being reflected by the organizational hierarchy. Based on self-organization and iterative processes, the teams run into trouble with the top-down steering of their environment. Consequently, very often agile proponents believe that a supportive agile organization should be structured without hierarchies. This is the reason why several companies in the agile field experiment with different organizational structures. Yet this is not an option for all organizations.
Especially large corporations that exist for many years will not be easily turned into a hierarchy-free organization. Maybe there are only a few agile teams or projects, and maybe there is only one department affected by the agile transition. And although over time an agile transition will affect other areas, like finance or sales, it is not very likely that corporations like GE or Siemens will as a whole adhere to agility if it implies they should get rid of their hierarchies. Although there are already several great examples for agile organizations, those neither have a long-lasting history like GE nor are they of a comparable size. This leaves—at least at first sight—the following options:
- Ignore the large corporations or implement agile in such an environment only at the team, project, or program level. Because only an agile organization allows the nowadays requested flexibility and innovative power, just wait till all of these large corporations have died off.
- Found your own organization, or rather work only for small organizations without hierarchies.
- Reconsider the idea that an agile organization has to be one without hierarchies.
For a pragmatic approach we will concentrate on the latter. In this article we are suggesting to use sociocracy as a solution that leaves the hierarchies in place yet still allows acting in an agile way.
Leadership in Hierarchies
Managers in general and particularly middle managers in hierarchies often suffer from being sandwiched: On the one hand, they want (and have) to ensure that the decisions made in their rank are implemented and accepted on the subsequent levels. On the other hand, they want (and have) to be a spokesperson for the level they’re responsible for. This leads to the following consequences:
- The manager has to ensure information and decisions flow both top-down and bottom-up. This isn’t problematic as long as these messages don’t contradict each other.
- Typically the respective manager decides (unconsciously) how to balance these two sides—so either ensuring the top-down or the bottom-up flow. Thus, either the manager acts more in a command-and-control style (typical for top-down) or more in a participatory style, where the latter has often the consequences that the boss of that manager overrules. In an agile setting this can often be experienced if the product owner isn’t empowered, yet does make decisions (as it is expected), and then somebody else up the hierarchy outvotes that decision.
The situation gets worse—actually both for the manager and the team—if the team is supposed to self-organize. Obviously it’s hard, impossible, or at least frustrating to self-organize in a command-and-control setting (because there isn’t much freedom for the team to decide upon), and as well in a situation where the team (including its participative leader) is often overruled.
Thus in summary, leadership in hierarchies often faces two major problems:
- There is the “always wrong” position, being forced to choose between a top-down or bottom-up decision-making approach that will make the manager be perceived as either too harsh of too soft.
- Their decisions are overruled at the next higher level, and/or the people they lead do not buy into the decisions.
These problems are independent of an agile transition, yet they become transparent and are seriously in the way if teams are working in an agile manner.
Shared Decision Making and Double-Linking
The key for enabling hierarchies for agile development is sociocracy—especially the two principles of shared decision-making and double-linking. (See also Using Sociocracy for Decision Making and Learning in Agile.)
Double-linking allows for a better alignment between the bottom-up and top-down decision-making. In “regular” hierarchies there is a person (often called manager) assigned who ensures that information flows top-down. This also means that the manager has to take care that decisions made at the next higher management level get executed in the department or team he or she leads. In an agile team this could be the product owner (Depending on the context, this might as well be a project manager or some other kind of manager.) who will steer the team and who is responsible for the budget of that team, for example. The product owner will have to ensure that what is decided at the team level is synchronized with the decisions taken at the next higher level.
For the information flowing bottom-up the team elects a representative. This can be anyone appointed from the team. (It could be the scrum master, but doesn’t have to be.) What makes sociocracy different is the following: This representative is not only a regular team member in his own team, but also a regular member (with all decision-making authority) of the group one level above.
So this is why it is called double-linking—at the level above are always two persons on behalf of a team below, the manager and the representative. Or in other words, from every level of the hierarchy there is a person who is appointed to the next level down (as a kind of manager) and a person to the next level above (as a representative).
This solves the sandwich dilemma leaders often find themselves in. Distinguishing the function of top-down information from bottom-up and double-linking the two is actually a structured implementation of good ol’ XP’s request for differentiating business from technical considerations (people-wise), and to quote from the first edition of Extreme Programming Explained: “Neither business considerations nor technical considerations should be paramount.”
For sociocratic shared decision-making, it is required that everyone takes a position. This is different from other ways of making decisions, where sometimes the decisions are made without being asked or only a cast of votes is required (and the votes in minority are ignored altogether). If a team decides sociocratically, everyone has to share his or her opinion verbally even if it were only by stating to be in favor of that decision. I, Jutta, can speak from my own experience that it makes a big difference if you just silently agree with something—e.g., by not saying anything against the topic at hand, by raising your hand in support, or by giving a thumbs up—or if you have to say aloud that you support this decision. As soon as a person says so, the person takes the responsibility for that decision and is no longer a follower only. Consequently, because every team member has to state his or her position, every individual on the team takes the responsibility for that decision.
Thus, no matter which hierarchy level we are talking about, shared decision-making supports the buy-in from everyone. Because everyone influences the joint decision by taking a position and by agreeing based on consent: no paramount and reasoned objection. Don’t confuse decisions based on consensus with those on consent. For the former the typical question is if everyone is in favor of the decision, whereas for the latter if everyone “is able and willing to execute the decision,” which indicates being okay with the decision without necessarily implying being in favor of it. In case I can’t live with a decision, I will have to explain my reason. Different to what is experienced in traditional decision-making, the consequence is not that the rest of the team tries to convince me, but rather works jointly on solving the issue I raised. Thus, as soon as a paramount objection has been brought up it belongs to the whole group—and the whole group uses this information in order to come up with a better decision. Thus, due to the participation of everyone it is also ensured that nothing substantial is overlooked because all relevant arguments of all parties involved are considered. Therefore, an effective decision is made, in contrast to autocratic decision-making or decisions made by a majority where not everyone involved will get heard.
Every objection is a sign that something has been overlooked earlier, and the objection provides now the possibility to correct this. And yes, this asks for a different attitude in decision-making. This attitude is actually comparable to the one a retrospective asks for. According to Norm Kerth’s prime directive, in a retrospective it is believed that everyone did the best job he or she could. In shared decision-making it is a pre-condition that everyone adheres to the common goal, for example to deliver a certain service or product. This goal is also explicitly decided upon by the team, using the consent principle. So in both cases it is believed that everyone always acts in the interest of the common goal at hand—be it that of the project, the system, the team, the company, etc.—and that nobody objects or works against the rest of the team just for the fun of it or for incomprehensible reasons. This could also mean that sometimes objections will lead to changes of the common goal. Or cooperation stops because of a lack for a common goal.
Moreover, for really tough decisions it helps to put a timestamp on the decision and get back to it after the time is up.
Other ways to make decisions, like majority vote, rolling a die, or leaving it to the leadership, still remain possible if the group decides to do so with consent. So the consent principle does not replace other decision-making principles in use but governs them. In general, consent is used to make the overall agreements like goals, budget, timelines, or working methods. Their execution is then delegated to one or more team members that can make their own decisions regarding the execution of the policy.
The double link in practice
The difference between working with a double link or not became very clear in a company that had to decide on the same issue within two years. The first time this was done with a single link, the second time after implementation of sociocracy with a double link.
Traditional: dualism and distrust
The management of a fast-growing placement agency decided, regarding the financial situation of the company, to compensate employees for inflation with 1% that year. This was a compromise between the government’s advice of 0% and the union’s advice of 3%. Employees were upset that management did not act on the unions’ suggestion. During the weeks that followed many complained and uttered their frustration and suspicion that management enriched itself at their cost. The managing director saw this as yet another symptom of the existing “us versus them” culture within the company. This passive aggressiveness made the managing director insecure.
Sociocratic: connected and creative
The Top Circle of the agency decided on a compensation for inflation of 0%. This happened with the consent of the representatives of the next lower General Circle after being informed on the current financial situation of the company. This was actually less than the 1% that management had proposed. Understanding the harsh financial situation of the company, the representatives had a paramount objection to handing out money when this might possibly lead to a deficit in the following year.
The decision was announced a week later in the General Circle. The representatives explained why they consented to the decision knowing the tight financial situation. Some General Circle members wanted more information on the financial situation, especially the remuneration of management. When it turned out that their salary wasn’t outrageous and management also wasn’t compensated for inflation, employees accepted the decision. After the decision had been communicated down the hierarchy, no complaints were heard; on the contrary, there was a shared understanding for the need to get the company in a better shape.
Shared decision-making in practice
The power of shared decision-making is illustrated in the following example. Deciding by consent helped this group in the health sector to overcome prejudices and try an experiment that led to a collaboration:
A partnership of obstetricians and seven midwife practices, which are using sociocracy as their governance model, had to decide whether they accepted the hospital in their region as a partner. Therefore, they gathered with their General Circle containing the double links of each of the current partners and the board of the partnership. If they accepted the hospital as a member, it would join their General Circle and make policy decisions with the other partners by consent.
After one round of picture forming, explaining the request of the hospital, several rounds of opinion forming followed. The first of these showed that some of the midwife practices feared that the hospital would dominate the partnership because of its size and financial power. They suspected the hospital of wanting to take control of the clients, driving the midwife practices out of business, and imposing all kinds of regulations upon them. This was fueled by a recent incident in which the hospital had placed several billboards in the region to attract pregnant women to come for care to the hospital. After a severe talk between representatives of the midwives and the hospital board, the case was settled and apologies had been made.
There were also midwife practices that favored the membership of the hospital because this could prevent these kinds of uncoordinated activities. The same held true for the obstetricians who expected that the consent principle would warrant the equivalence in decision-making and make it impossible for the hospital to overrule other members. Furthermore, it could help to make the hospital to become more transparent, particularly on how they calculate the cost of their services that they provide to the partners.
After the second round of opinion forming it became clear that the midwife practices that feared the dominance of the hospital doubted the hospital’s good intentions. It seemed difficult to overcome their paramount objections. Tension in the group rose, which pushed circle members to think about more creative solutions than simply agreeing or disagreeing to the membership. During the exchange of opinions in the third round, suddenly a proposal emerged to invite the hospital for a discussion with a group of representatives of the existing partners. This group consisted also of midwives with strong doubts about the (good) intentions of the hospital. The group was assigned to find out whether the hospital accepted the vision, mission, and aim of the partnership, and the sociocratic way of decision-making.
It was decided that if this group was positive about the hospital after the discussion, the hospital would be allowed to join for a trial period of half a year. After this period a final decision about the membership would be made. This proposal was consented. In one of the following weeks the group met with hospital board members. The hospital accepted their conditions and was allowed (provisional) membership of the circle.
Effect on Agile Roles
Using a sociocratic structure for embedding agile teams will have some effect on the agile roles. The decision can be made for other roles or people, yet in most cases it will be the product owner and the scrum master ensuring the double-linking. Typically it is the product owner who will steer the team on what it is working on, so the person in the role of the product owner will be assigned top-down by the hierarchical level above. Subsequently, the product owner will participate in the steering meetings of the next higher level. (This is above the team level.) Both the assignment and the necessary presence is already happening in most organizations that apply agile development. Yet using a sociocratic structure will require more differences for the scrum master:
- If the scrum master should represent the team, then in a sociocratic structure, the scrum master will be elected by the team he or she is representing. So the scrum master will be neither assigned (e.g. top-down) nor will he/she volunteer for the role. In this election, every member of the team will provide a suggestion and rationale of a person for that role. Then the team will decide jointly (based on consent) who will take that role.
- Additionally to the product owner, the scrum master will participate in the steering meetings of the next higher level. In these meetings the scrum master is equivalent in decision-making (based on the consent principle) to every other member of that level.
As mentioned before, it will be most likely that the product owner and scrum master will ensure the double-linking. However, the team can as well decide on any team member as a representative. It doesn’t have to be the scrum master, just anyone who is trusted by the team to represent it best at the next higher hierarchy level.
Conclusion and Outlook
The two principles presented could be used as well to connect different scrum teams when scaling up. For example, if your product consists of several product areas and many teams work on each of these areas, then these two principles allow to interconnect the teams and product areas without a complicated framework, and/or without putting the agile principles and values at stake.
Both double-linking and deciding based on consent secure the equivalence in decision-making between agile teams and the organization. This way traditional linear hierarchies can become cyclical hierarchies: (formally) integrating top-down and bottom-up decision-making. By double-linking organizational levels through leadership and representative(s), who together set the policy at their respective organizational levels, a hierarchy also supports agility. When this policy-setting in the cyclical hierarchy is combined with a delegation of the execution of policy to individual organizational members, it will increase its agility even more.
- Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley
- John Buck, We the People: Consenting to a Deeper Democracy, Sociocracy.info
- Gerard Endenburg, Sociocracy, the organization of decision-making, Sociocratisch Centrum
- Norm Kerth, Project Retrospectives: A Handbook for Team Reviews, Dorset House
- The Sociocracy Group (Homepage of Sociocracy)
This article was originally published at InfoQ.
Jutta Eckstein will be presenting a free webinar with ITMPI on November 2! Sign up here: Sociocracy: Leveraging Agility in Your Organization