BT

Facilitating the spread of knowledge and innovation in professional software development

Contribute

Topics

Choose your language

InfoQ Homepage Articles How to Decide in Self-Managed Projects - a Lean Approach to Governance

How to Decide in Self-Managed Projects - a Lean Approach to Governance

Bookmarks

Key Takeaways

  • Starting a new project requires having clarity on the basic decision-making processes and governance of the project. 
  • Instead of hierarchical or unstructured processes, a lean, flexible and robust set of governance decisions is encouraged; self-managed projects can set themselves up to organize their work. Self-governed projects go one step further and have authority to set their own purpose. 
  • To decide who decides, the first steps have to be clear as the project starts: the aim, the default decision-making method (e.g. consent), and a defined membership for the project. 
  • Members of the project can define the basic infrastructure for the project to support accountability: a lead role, meeting facilitator role and agree on basic meeting agreements to make sure meetings are balanced and intentional; note-taking, a parking log for future agenda items to connect meetings with each other. 
  • Once this basic system is established, the project members can mold the structure as needed by adding sub-teams and roles. 

Introduction: what’s the problem? 

When starting a new project, it’s often all honeymoon and best intentions. Everyone throws themselves into it. Starting new things is engaging and fun, and building a simple product together can be easy with just work and very little structure. 

But if it’s too little structure, then, all of a sudden, lack of alignment begins to creep up. “The others on the team didn’t want to slow down. They wanted to do things, to not have another project get eaten up by endless meetings,” the people who wanted to work more on alignment claimed. 

Yet, that lack of coordination wears people out as well. Mike builds something incompatible with what Celia built. Parvin wants to set project values first. And the leadership outside the team is worried about mission creep and cost. 

If the people in the project can make decisions themselves, we can call it self-managed. By “self-managed” (or self-organized), I mean that the project members can make decisions about the content of the work, and also who does what and by when. Self-managed groups have the advantage that those who do the work are closer to the decisions: decisions are better grounded in operations, and there is more buy-in and deeper insight from those who are going to carry out the tasks into how the tasks fit into the bigger picture. 

One step further would be to have a self-governed project. In a self-governed project, even the highest decisions and the overall direction (purpose) and goals can be modified or set together by the people in the project, giving the project members maximum buy-in, contribution and say, as no other institution or individual rules the project. 

Two ways to organize - and a third option

Whether self-managed or self-governed as a project, the power still needs to be distributed internally. If the project is open to decide how things are done, how do we decide? There are typically two ways to go about new projects.

  • Top-down approach: priorities and key decisions are made by the project lead.
    Advantages: clear and efficient.
    Disadvantages: as with many top-down structures, it’s easy to lack input from the team members, and engagement in the project often diminishes. 
  • Horizontal approach: everyone somehow decides together. 
    Advantages: inclusive (at first sight), engaging (for many).
    Disadvantages: often unstructured and inefficient.

Even worse, some styles oscillate between the two styles by sending mixed messages such as “Do it your way… but your way should be what I want to see”. Or the project is left alone for a while, only to get then overruled or “rescued.” 

The questions that come up time and again for every project are always the same:

  • Who decides in our project? For example, who sets the timeline, or is it set together?  Who has the last word on the budget? Who decides what tools we’ll use? 

If we don’t know who decides - or how to decide who decides - these follow-up questions become almost impossible to answer: 

  • What are we building together? 
  • Who is part of the project? 
  • How should we divide up the work? 

These questions are going to be answered no matter whether we decide them explicitly or not. If no process is followed, these decisions will simply fall into place. Without intentionality, we often fall into unhealthy patterns - for example, some might assume that their ideas are worth hearing but not others’. Or some might dominate meetings, while others stay quiet - and relevant information never gets shared. And once set, it becomes harder and harder to change the rules of the game in our project because unacknowledged practices are more challenging to address and change. 

The third option: an intentional process

The way out of this lies in governance. While some have an aversion to governance and structure - associating governance with bureaucracy and constraints - lean governance is very natural. Every group decision requires governance, whether we see it or not. A group of friends making plans to see a movie uses decision-making. How do we decide what movie to see? Whose voices are heard? Who makes the final call? If you’ve ever felt left out in such a situation - or sent way too many text messages to figure out which show to go to - you know that these processes aren’t always easy. What you don’t notice - because it feels smooth - or what you do notice - because it’s tedious - is governance. 

The trick is to use lean governance, intentionally and in our favor. The goal of governance in a new project is to provide just enough structure to operate well. Just enough team structure to have a clear division of labor. Just enough meeting structure to use our time well. Not more but also not less. That level of “just enough,” of course, depends on the phase of the project. For example, some in the project might want to establish a lot of roles in great detail that we might not even need, or design very detailed spreadsheets to support workflows we haven’t tried out a single time yet - that’s how structure can get overbuilt and become stifling for the project. Better to work incrementally, by starting with little structure and refine over time. I admit, it’s not easy at all to gauge it, but it’s a clarifying question to ask ourselves: what are the first things one absolutely needs to decide in the beginning? And what can wait? The litmus test here are operations: do we have enough clarity to act for a while? If not, create clarity (I see that a lot in self-managed teams where roles are underspecified and people don’t carry out tasks because they are not sure what exactly they are asked to do). 

The process described in this article builds on the self-management system sociocracy, a combination of decentralized, nested decision-making and consent as a basis for decisions. The advantage of sociocracy is that it’s highly flexible and robust at the same time. That means we can use precisely the tools we need at the moment. We’re not stuck with a heavy, overbuilt system, and we’re also not lost in a laissez-faire approach. Instead, the process outlined in this article introduces the tools from sociocracy in a linear, logical order that builds over time just as a new project needs them.

Having seen dozens and dozens of groups in this stage, helping to set up their governance systems with sociocracy, here is what you need to know. 

Must-haves from the get-go

These are the decisions you need to decide before you do anything else. 

  • Aim: what’s the overall goal of the project? What are we signing up to do together? Typically, the project purpose or goal might be set from the outside; in this case, just having clarity on what is being asked is enough. Yet, in a self-governed project, the people in the project have a say in the project goal. Either way, it has to be clear and understood. 
    To be clear, it has to be specific. For example, “changing the world” is not specific. We all want to change the world but we all put our time into different things. The more specific that original aim is, the more likely it will be that people can do things together, which is what every project should be about. Bring a proposed aim to the first meeting, so you don’t have to waste time word-smithing together. 
  • Decision-making method: how do we make decisions? 
    Our choice of the decision-making method is key. Do we vote? Do we talk until we all agree (consensus)? Do we talk until half of us have had enough and leave? Do we talk until there’s no objection? 
    The tricky thing about decision-making methods is that it’s fundamental and axiomatic. Imagine you don’t have an agreed-upon decision-making method and want to adopt one. To agree on your decision-making method, what decision-making method will you use? Will you vote or aim for consensus? This is a chicken-egg problem many get trapped in. It remains an unsolvable issue of legitimacy - who decides how we decide? - but it’s much easier to address if we make that very decision first. 
  • Who is part of the project - for now? The point here is not to exclude people but to know who the founding members are. That way, we have a basis for decision-making to invite others into the group as desired. 

On each of these choices, it helps tremendously to propose something as a starting point. Then do a round of reactions and then make a decision. To use an example for the last point, groups often struggle to make decisions on project membership. Groups can easily spend 20 minutes in a meandering discussion. To catalyse the discussion, work with a proposal instead: let’s say you have a sense that the members you have right now are the right people to get started on the project with. Then just propose to keep the membership as is right now. Do one round of reactions where everyone expresses their thoughts, then ask if there’s any way the project will be harmed if the membership stays as is for now.  That kind of decision-making is called consent, and it’s the default decision-making method in sociocracy. Consent is easy to do because you only need to make sure together that your decision doesn’t create harm. That way, not everyone needs to love it, but a warning voice from a trusted team member won’t get lost in the process. Once consent is in place, you can use it for all group decisions. To speed things up, you can define operational roles, find someone to fill the role and therefore empower role holders by collective consent to make a defined range of decisions on their own.

Once the group has established consent, every decision is easy. Consent simply means: a decision moves forward if there’s no reason to stop it. Make a suggestion, allow for questions, do one round of reactions and potential amendments and then ask for consent. Don’t go down rabbit holes or engage in endless discussions about preferences. Move forward with something good enough and then improve and fine-tune over time. 

Back to our example of deciding about the membership, people might have differing opinions on the question, which they can express in the reactions. But then, as we move to consent, only objections can hold back the decision to approve the proposal to keep membership as is. That way, we don’t discuss it endlessly but the path becomes clear: if there’s no harm (= consent), we move on. If someone does object, they explain their objection. For example, they might say that currently no one in the project has enough experience on the financial side of running the project. To integrate the information the objection brings, we crowdsource ideas. Shall we get outside help on that topic as needed? Should we ask an extra person with those skills to join our team? Once everyone has added their ideas, make a new proposal (e.g. “We will keep membership as is and ask XX for support on the financial planning”) and check for consent again. Consent is pragmatic because we focus on the project goals, not our personal preferences. But the process is considerate because everyone is heard. 

Must-haves early on

From a governance point of view, it’s pretty clear what a project needs to run effectively, no matter what the project is even about. We need someone who “herds the cats” and pays attention to the project overall. In sociocracy, that’s the leader. The leader doesn’t dominate or boss people around. It’s about servant leadership in support of the project and its members, not autocracy. Having a facilitator is useful to make better use of our time in meetings, keep them short, focused, and make sure the voices in the room are heard. Then, in order to have transparency within our project or organization, good meeting notes are key, which means we need a secretary. 

Even the decision of who fills what role can be made by consent using the sociocratic selection process. Just recently, I was selected as the lead for a restructuring project out of the four people in the project, based on my experiences and the nominations by the other project members. In a different context, I was nominated as the leader of a circle at a moment that was a surprise to me. I had joined the meeting knowing there would be a selection, but not expecting to become leader. I was nominated by others (but I myself nominated other people). When the proposal was to give me the role, I was torn. Was I able to fill the role with attention and integrity? It was the transparent feedback and reasons that people had mentioned when they nominated me which convinced me. I could see that, given the moment in time for the team as well as my strengths and skills, it made perfect sense to have me be the leader. Since I was worried about the time commitment, I objected and asked to shorten the term to six months to try out whether I could handle it. Everyone consented and the decision was made!

For a successful project, there are a few more boxes to check:

  • How do we communicate with each other? Let’s not have loose emails and long reply-all threads flying around. Make a plan. Whether Google groups, Slack, or any other tool are your answers, the point is to be on the same page and avoid chaos. Keep it simple and lean, and add complexity only if it’s needed for operations.
  • How do you track topics you need to address? Make a “parking log” (backlog in sociocracy jargon) and ensure you don’t lose items. If a project member cares about a topic, it induces trust if you track it well and undermines trust if you don’t. That one is a really easy tool to adopt. We often simply have a living list of future topics in our notes that we add to or subtract. Of course, Trello or similar tools work as well. Find the tool that works best for you. 
  • Do you need/want additional members in the group? Whatever your answer is, decide it together and avoid surprises or friction. Again, keep it simple - you can keep the team small and ask outsiders for advice on certain topics. 

Tools for connection and review

Collaboration is for people, and people are more than their work. The better we know each other, the better we can create working relationships and working conditions that make it engaging and pleasant to work together. Sometimes friction in teams discharges over allegedly content questions (e.g. “Should we use software tool A or B?”), but really the true underlying conflict is whether we feel respected. Knowing each other reduces those frictions and increases psychological safety which will positively impact our collaboration and quality of our work.  Instead of working with strangers and doing group-building exercises once every six months, spend a few minutes here and there to get to know each other or build connections and review moments into your processes.

  • Rounds - the practice of speaking one by one - in parts of your meetings help us listen to each contribution better and to get more of a sense of the people on our team. Also, it feels really good to be heard without interruptions. 
  • Do a round of check-ins at the beginning, and do a round of meeting evaluations at the end. How are you doing coming in here? How are you doing as you leave? Did this work for everyone? 
  • Review your decisions from time to time in a quick go-around: how is this working for you? What could be improved to make it work better? 
  • In new groups, invest 15 minutes and let everyone share their story and hear what interested them in the project. This only takes a few minutes, but it’s a good investment. The better you understand each others’ motivations and skills, the better you can work with their energy in the project. 

Scale

The processes described here work best for a one-group project. But group projects can scale by “budding out” into sub-teams and can grow beyond one core group. You can define those sub-teams in your main team and define one or two people who serve on the main group and the sub-team to keep them well-aligned. 

When is it time to form sub-groups? That’s easy to answer. As soon as you talk about a topic in the main group, only some of the group members are involved in the topic. Why talk about a topic in a group of eight if it only affects the work of three of us? It’s much more efficient to “bud out”! With that approach, it’s much more likely that you will not overbuild structure. 

With nested, linked sociocratic circles and roles, we can build a system where every discussion is directly related to the work of each person in the room. A sub-group can grow when there’s energy and “fold” where a sub-project is completed - giving us a structure that fits like a glove every step of the way. Who makes decisions together directly impacts the quality and ease of decision-making. If the people who are making a decision together are the people who actually know about the project first-hand and will carry those decisions out together, it will be much easier to find common ground. If people are not actually involved and just have opinions, decisions can be slowed down. So the better the match between those who are directly involved and the decisions they need to make together, the smoother decision-making will be. 

Learning more

Starting a project isn’t hard - most of the steps are always the same once you see the governance patterns. A solid but flexible set of tools and practices like sociocracy is a great starting point to have clear but lean processes that can grow as we grow.  Then you can lean back, leave the drama and endless discussions behind, and focus on the project’s work - enjoy the ride!

The key governance ingredients of a successful project as described in this article are taken from the book Who Decides Who Decides. How to start a group so everyone can have a voice - a book that lays out each process in more detail. Additionally, it linearizes the decisions to make into the first three meetings of any group. The book also includes an outlook on how to grow and “bud out.” You can see the meeting templates for all three meetings on the Who Decides Who Decides page. Its accompanying resource page provides demo videos of the processes it  describes. 

About the Author

Ted Rau is a trainer, consultant and author. He grew up in suburban Germany and studied linguistics, literature and history in Tübingen before earning his PhD in linguistics there in 2010. He moved to the USA and fulfilled a long-held desire to live in an intentional community. He studied self-management and now works full time teaching/consulting, writing, and as executive director of the non-profit movement support organization Sociocracy For All.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT