How we take decisions without managers and teamleads

We don’t have any middle management at sipgate. There is still a boss – bosses even, plural – and we look to them for strategy and long term planning, but they are not involved in day to day decisions. In our ~12 product teams no one is the boss of anyone else. This often prompts the question “So, how do you take decisions around here? Who decides things?”

That’s an excellent question that I had absolutely no answer for, the first time I got it. I had never thought about it, because decisions just … get taken. But how? And by whom?

Once I started thinking about it, I realized that the answer is not straightforward, because it’s always different groups of people that take any given decision. The guiding principle is:

We want decisions to be taken by the people who have the most information to make a good decision.
Sometimes that is a single person. More often it’s a pair or a team. Decisions that are more far-reaching but affect mostly one job role can be taken by this role’s community, e.g. all developers or all UX designers.

What happens when people can’t agree?

Our teams have many degrees of autonomy to take decisions about “their” product. Most decisions are taken together. When the team can’t agree the decision falls back onto the most appropriate role: The Product Owner has last say on product feature, time budget etc. Developers have last say on technical implementation etc.

A smart team and Product Owner take care not to force too many issues, because that always leads to trouble down the road. Resentful people are not doing their best work. Fortunately, we can usually agree at least on a general direction

What about company-wide decisions?

In most cases, the group that can take the best decision overlaps with the group of people that will be affected by the decision. The smaller the overlap, the more you need to consult with the people that will be affected.

A popular way to decide something with the input of many people is to discuss it in an Open Friday session. Let’s look at a decision from about 2 years ago:

At sipgate teams can go out on team events to foster team spirit. A typical team event is an activity (escape room, cooking class, minigolf, …) + restaurant + booze. Up to a certain amount, this is on the company’s dime.

Now, our colleagues in accounting had noticed a worrying trend and pitched the following session: “Last year, we’ve had 1 team building event in the whole year. Now it’s April and we’ve already received 5 team building events. We suspect some of these to be regular ol’ team events but we can’t and don’t want to decide which is which. We’d like to talk about how to handle this.

Wait a minute! “Team building event”? How is that different from a “team event”? Turns out, a team event is is your own private fun, whereas a team building event counts as company time, i.e. you can go home earlier if your team building day is longer than usual.

Anyway, at the time of the session, about 12 people from all over the company met and a short Q&A and some discussion we came up with a list of criteria so that every team can decide whether they are planning a team event or a team building event.

[A team building event is for teams that are in trouble. They typically last a day. You probably aren’t looking forward to them (see “team in trouble”). A team event is typically in the evening and you are happy to invest your own time because your team is awesome!]

Took less than 1 hour and those criteria still stand.

You made a money-related decision just like that?

Well, in this discussion a new colleague wanted to “delegate” the decision to a higher level: “Management has to decide that! That is not something that we can decide!”.

Not true. I could vividly imagine what would happen if we really bothered a higher level with that. The higher level would have been C-level, since there’s only 2 levels, C-level and everyone else. They would have looked at us like we’re crazy people and told us to decide for ourselves. They don’t want to think about minor operational stuff like that.

The same applies to at least 90% of issues that I’ve heard the “someone higher up has to decide that” bit by newbies. We absolutely can take many of these decisions and we do. We usually have more information and are also the ones affected.

It’s part of acclimatizing at sipgate to stop relying on higher ups. You can take your own decisions. You also have to. With great power comes great resonsibility.

What are the drawbacks of this distributed decision-making?

Problems arise, whenever it’s unclear who are the best people to take a decision. Depending on  personality some drop issues, others talk to a looot of people to try to reach a decision.

Another is that we are used to great autonomy. When team decisions are overridden by C-level it’s usually not taken well.

You might think that “You have to discuss, so this approach takes longer” is also an issue. I don’t think it  slows you down for two reasons:

  • A lot of decisions affect only 1 or 2 people and you can take those without asking anyone. You need a software tool for 50 bucks that will save you 1h per month? Buy it! The time to run this by anyone else is more expensive than the tool
  • Execution is faster, because we all agreed on what we want to do, instead of dragging our heals on executing something we had no say in and think is a stupid idea by someone ignorant

Would I trade this for a traditional top-down decision making process?

Hell, no! I admit, there were times (~2011) when I longed for someone to swoop in and just take a decision so that we’re done discussing. Now, I’m very happy that the powers that be deliberately created a decision vacuum until we had all learned to take widely supported decisions together.

Overall, I think this appoach makes us faster and results in much better decisions.

Addendum: I’ve just realized that this can only work because we’ve got a strong sense of “how we do things around here”.

PS: Like what you're reading? Join the Finding Marbles newsletter to get new blog posts in your inbox!

Share this article:

Leave a Reply

Your email address will not be published. Required fields are marked *