I am part of a distributed team: Happy Melly One. We have ten people in our team and we are distributed over five different time zones. We work with freelancers. Most of us also have other projects that they work on. We are responsible for Management 3.0 and Happy Melly. Like every organization, we need to experiment, make decisions and adapt when necessary.
Some decisions are easy to make. If necessary, you inform the people concerned and you are done. When I need to order new items for the web shop, I just order the new supplies. When I decide to merge some files into a new folder on our team share, I just do it. Life can be easy, sometimes…
There are experiments that we would like to run that affect many people, customers, commitments, etc. Experiments that you would like to discuss first with as many people as possible in the team. If possible, you want to talk about it with all team members. Remember I said life is easy? Well, discussing these kinds of experiments in our team is not so easy. Reasons are the time zones, other projects, other obligations, and sometimes team members are also enjoying holidays.
How to solve this?
First, let’s take a quick and brief look at holacracy:
A holacracy is a governance structure characterized by a distribution of power among self-organizing groups, rather than the top-down authority in the typical hierarchical corporate culture model.
One of the meetings described in Holacracy is the Governance meeting. In a governance meeting, a circle can change the roles of the circle, it can change policies of the circle and/or elect people to the elected core roles of the circle. More information about governance meetings can be found here.
I looked at the structure of the governance meeting and realized it could help us in making decisions. Time to run an experiment in our team. So, I created a Google Docs template, called the proposal document template. I know, sometimes it is hard to be original.
Let me explain our process, inspired by the governance meeting structure.
As soon as someone would like to make a decision, propose something, run an experiment, they will create a new proposal document.
The first section is the proposal. What are they proposing? What would someone like to change and why? For example, someone would like to change the logo of Happy Melly One to a huge purple square. In the proposal, they can then describe the what and the why. They can explain why a huge purple square is better than our current logo.
The person concerned will then share the document on Slack. If necessary, they can tag people to make sure they will be triggered to look into it. People can read the proposal and ask questions to the proposer. Questions that will clarify the proposal.
The proposer will make sure everyone will either ask a question or that they say “no further questions” (or something similar). If the proposer does not chase people for this info, there is probably no urgent need for the proposal, and it will just fade away. For example, why choose a huge purple square instead of an enormous yellow square? Or how did you get this idea in your head? I love the current logo, if you change the logo then I am out of the team.
As soon as all people have asked questions or made remarks, the proposer can answer the questions. In the section Amend & Clarify the proposer can provide the information or even change the proposal if necessary. In this example, the proposer could change the proposal to a huge yellow square, or they can explain that it is proven that the color purple attracts more people according to research. Or they can just leave the proposal as it is.
Again, all team members should then provide input. This is the final step. Does anyone have objections to this proposal? The answer can only be yes or no. If no, a reason would be nice but it is not necessary. If there is someone who objects, the proposal is not accepted. In this case, I am sure the proposal for a new logo will be rejected, so the proposer should come up with a new proposal or discuss it in a meeting.
One thing is very important. You are only allowed to object if you think the proposal will hurt the organization. In this example, if you just don’t like purple, bad luck. Run the experiment, learn and adapt.
In the last weeks, we made two big decisions based on two such proposals. Thanks to the small process, all team members were able to provide input. What is more important, we were able to make the decisions in a week where it otherwise would have cost us weeks to get everyone in a meeting. Another advantage, we are keeping track of our decisions, our decision-making process and most important: we document the why.
Excuse me? Oh, so you are a level 4: Certified Holacracy Master Coach and you are telling me that this is totally not as it should be according to Holacracy? OK, well no problem. I was inspired by the governance meeting and we adapted it to our team. We made it work for our team.
Feel free to create your own proposal document template and use this idea in your (distributed) team. I would love to hear your experiences!
If you want to learn more about how to make fast decisions on remote teams, also listen to this podcast from Lisette Sutherland.
3 thoughts on "Distributed Teams: Hell-to-Make Decisions!"
Thnx, excellent and practical idea 🙂
This is actually consent decision-making from sociocracy / Holacracy done asynchronously… I’ve tried something similar: facilitated consent decision-making by virtual team using comments in Google doc with proposal. It worked just fine.
>There are experiments that we would like to run that affect many people, customers, commitments, etc. Experiments that you would like to discuss first with as many people as possible in the team.
Why? If someone thinks doing something is worthwhile why shouldn’t they just do it? Do you really need to “discuss first with as many people as possible”? They sounds inefficient. Why not just discuss with a few key people who’s opinions you really respect?
I’d take a different approach. The person responsible for the task decides how to do it but should seek advice when needed and always take the suggestions seriously[
This idea of trying to get a lot of people involved in making a decision is a “Tightly-Coupled Monolith” teamwork model. It’s defined by:
– Senior management reviews nearly all tactics e.g., CEO reviews all refunds, advertising, blog posts
– Lots of multi-departmental buy-in meetings
– Keeping other internal groups happy has equal precedence with pleasing customers
– Mavericks get exhausted trying to innovate
– Highly-coordinated through centralization, but very slow, and the slowness i increases with size
I recommend a “Highly-Aligned, Loosely Coupled” model instead:
– Strategy goals are clear, specific, broadly understood
– Team interactions focused on strategy and goals, rather than tactics.
– Requires large investment in management time to be transparent and articulate and perceptive
– Minimal cross-functional meetings except to get aligned on goals and strategy
– Trust between groups on tactics without previewing/approving each one – so groups can move fast
– Leaders reaching out proactively for ad-hoc coordination and perspective as appropriate
– Occasional postmortems on tactics necessary to increase alignment
Hi Max, thanks for your feedback. In my case the team is around 10 people, and there are some experiments I would like to discuss when it is really a big impact. Maybe just my style of leadership. It would be different when I was talking about a huge organization, agree it could be inefficient in that case. However, for me it is also about getting feedback about my idea.