How we decide at it-agile

February 13, 2014 at 9:05 pm 3 comments


Context

At it-agile each employee (with some minor exceptions due to probation period) is a shareholder with the same shares. These sum up to more than 60% of the company. The result is a special power cycle: The CEOs have formal power over the employees (and may lay off people). On the other hand the employees may instruct the CEOs or even replace them with somebody else. This setting forced us to search for appropriate decision mechanisms. On our quest we tried several approaches. An obvious one is democratic decision. Funny enough this worked fine for a while but it turned out that it didn’t scale for us when we exceeded an employee number of 15 to 20 (now we are 30 something). This blog post describes the current way we decide at it-agile.

Current State

When it comes to decisions, I think we value some principles:

  • The decision mechanism should be appropriate (especially regarding impact for other employees and reversibility) for the decision at hand.
  • Consensus is nice but often not necessary (it is often too costly to create consensus with 30 people) but it is important to have a high commitment of the employees on the decision.
  • Decisions should be reversible (there are very few exceptions where it is not feasible or possible to ensure reversibility).
  • Therefore wrong decisions aren’t that bad. We may learn that the decision was wrong or suboptimal and then create a better decision soon.
  • Decision making should be decentralized.
  • Relevant perspectives should be respected when making a decision.

Currently we use these decision mechanisms:

  • When a decision impacts only you, you may decide yourself directly. (For example we have very few very simple guidelines (“simple rules”) for travel expenses and you are empowered to decide for yourself according to these guidelines – and you publish the travel expenses for your colleagues).
  • When a decision impacts only your team, you may decide with your team. Here you should use the decision mechanism that is established within your team (often teams use Konsent).
  • When a decision impacts other colleagues we try Konsent (with thumb voting). When we are not able to make a decision within 10 minutes we choose a “decider” who has to consult his colleagues and then decides (consultative individual decision, in german it is called “konsultativer Einzelentscheid”). For choosing a decider we ask for proposals and rationale. If there are several proposals for the same decision we choose in Konsent. It turned out that choosing the decider that way is fast and effective for us.

Consultative Individual Decisions

The consultative individual decision making process has these steps:

  1. Identify a needed decision and choose an appropriate decider with Konsent.
  2. The decider consults an appropriate set of people (within and/or outside his team/company).
  3. The decider decides based on the perspectives he gathered.
  4. The decision is published within the company (at it-agile the decider publishes whom he consulted, which perspectives were relevant and what his decision is).
  5. All other colleagues accept the decision and practice forgiveness.
  6. We all together learn from this decision making process and improve for the next decision.

At the moment we identify necessary decisions and appropriate deciders during our monthly Company Sprint switchovers. When it becomes clear that a decision is needed and we are not able to decide as a group (of 30 people) within a few minutes we select a decider. The decider then has a timebox until the next Sprint turnover to decide. We add a task to the Company Task Board so that we remember to review the decision.

How we got here

In our nine years history we tried nearly every decision-making mechanism we could find. In the beginning a lot of the decisions were made by the CEO. Since we wanted to be a participative company we tried to move more and more decisions to the employees. That worked fine in the beginning. People started to decide for themselves. Bigger issues were discussed and decisions were made with majority decisions at our company tuning days.

When we grew beyond 20-25 people the discussions and decisions at the tuning days became more and more dull and slow. We invested a lot of time and energy and often didn’t come to consensus. We tried majority decisions. Still we had a lot of time-consuming discussions and when the decision had only a narrow majority we slipped into a bad mood. The narrow majority didn’t want to force something onto a big minority. And when we had a narrow majority decision the large minority questioned the decision shortly after the decision again and again.

We knew how to apply Konsent (see http://en.wikipedia.org/wiki/Consent) for a smaller number of people (team size). But we haven’t found out until now how to run it efficiently with 30 people.

We had a decision crisis for months and since we didn’t know any other alternative we switched back to central CEO decisions for important aspects. That allowed us to make decisions again but still wasn’t what we were aiming for: a participative company.

And then we had a workshop with Niels Pfläging where he explained the Beta Codex model. We recognized that we followed the Beta Codex principles without knowing it but that our central decision model didn’t fit into the picture. After discussing the problem with Niels he proposed Consultative Individual Decisions. At first the concept sounded a bit weird. Would we empower an arbitrary employee to decide about an investment of 100.000 EUR? But since we already had a history of doing weird things (like introducing teams without having a clue how that concept could be applied in a coaching context like ours) we decided to give it a try.

We designed an experiment with 4 decisions: three of the decisions were proposed by the CEOs and one was added by the employees during the Sprint switchover where we started the experiment. We formulated our thesis (“consultative individual decisions” increase the number of options heard before deciding and increase the commitment on decisions) and set a timebox (due to Christmas and New Year we set it to two months).

After the two months we reviewed the decisions at the company Sprint turnover. Three decisions were made. One decision wasn’t made. We had learned that the decision was too big and the time was too early. We then decided to delay the decision for 2 months (when we would know more about the topic). And we learned that it is valid if a decider makes a decision that doesn’t match exactly his mission.

Our evaluation showed that the overwhelming majority of people thought that consultative individual decisions lead to an increased number of options heard and higher commitment. Some people thought the quality was as before and nobody thought it was worse than before. Consequently we added consultative individual decisions to our repertoire of decision-making mechanisms. And we applied it immediately:

We had a CEO decision that we would only hire employees living in Hamburg (to increase personal contact between employees). During the retrospective of the Company Sprint switchover that decision was questioned by a working group. The group proposed another approach. We checked if we could get Konsent for that proposal. Within a few minutes it turned out that we couldn’t. Therefore made it a consultative individual decision and chose a decider.

Acknowledgements

Thanks to my colleagues Ilja Preuß, Christian Dähn and Manuel Küblböck for their feedback and input for this article.

Entry filed under: it-agile-blog-planet. Tags: .

Agilität, Skalierung und Kundenbegeisterung Agile Skalierung: eine Kollage

3 Comments Add your own

  • 1. Paul Herwarth von Bittenfeld  |  February 15, 2014 at 2:31 pm

    Thanks for sharing, Stefan. We had a similar situation last year out of a personal conflict between two colleagues where we were not able to decide with Konsent. We tried it with a small committee of three people, where one committee member was chosen by each colleague involved in the conflict and one member was chosen by our ScrumMaster team. That helped us to come to a decision in a situation where there was no obvious solution.

  • 2. Yves Hanoulle (@yvesHanoulle)  |  February 25, 2014 at 4:19 pm

    In TheCoreProtocols, they also say tha decider does not work with groups bigger then 7 people.
    There the advice is to split up in a group that cares about the problem. And if more then 7 people care about an issue, even have two groups independently decide on the problem and then combine their decisions.

  • 3. stefanroock  |  February 26, 2014 at 12:32 pm

    I think the group size depends on the type of decision. We had a decider for the decision if we want to increase all wages this year and how big the increase should be. The decision affected every single employee (more than 30) and most employees had a opinion about it. And that was no problem.
    Other decisions may require creative solutions and then smaller groups may be more appropriate.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



Follow

Get every new post delivered to your Inbox.

Join 185 other followers

%d bloggers like this: