LiquidOrgs – first draft

Liquid Organizations (aka “LiquidOrgs”) is just an idea, for now. LiquidOrgs has three legs, for now. LiquidOrgs try to take agility to the actual definition of the organisation. The three big questions I’d like LiquidOrgs to answer are:

  • Who’s the owner (aka who gets the money)
  • Who makes decisions
  • Who’s in and who’s out

To define the product we got Lean Startup stuff. To develop the product we got agile stuff. I love both of them dearly, but we need more.

The $ leg: Adaptive Ownership

Unlike general social labour, knowledge is impossible to translate into—or measure in—simple abstract units. It is not reducible to a quantity of abstract labour of which it can be said to be the equivalent, the outcome or the product. It covers—and refers to—a wide diversity of heterogeneous capacities, including judgement, intuition, aesthetic sense, level of education and information, ability to learn and to adapt to unforeseen situations, which are capacities themselves brought into play by heterogeneous activities ranging from mathematical calculation to rhetoric and the art of persuasion, from techno-scientific research to the invention of aesthetic norms.
André Gorz – The Immaterial


How much does Y deserve? What is the value of her/its contribution? The question arises time and again, whether Y is a team member and/or business partner. So far we have solved this constant puzzle with two equally inert alternatives:

  • Pseudo-objective measurement (mostly of time spent)
  • Upfront decision by consensus (e.g. “Let’s split 60/40”)

The former suffers from illusion of accuracy, whereas the latter lacks a clear mechanism to adapt, once we learn that 60/40 was not the best way of splitting. Adaptive Ownership is precisely one such mechanism.

An example

Let’s say a bunch of friends get together to develop the next blockbuster game called AngryTurtles:

Alice Graphic Artist
Bob Software Developer
Carol Software Developer
Dave Game Designer/Marketing

1st month

After one month of intense work, a lot of things have been achieved:

  • 3 early paper prototyping sessions with potential gamers
  • First version for the web
  • Rough prototype for iOS and Android, checking technical feasibility
  • First version of a promotional website
  • 30 people have already played the web version and their initial reaction is quite positive
  • The monetization strategy was decided after some user interviews: free version with only small turtles, and you can buy bigger turtles online

Step 1: Sharing out

So now each team member will value the work of her teammates by splitting 100 shares between them. For example:

Alice Bob Carol Dave
Alice 40 30 30
Bob 25 35 40
Carol 20 40 40
Dave 30 35 35

Simply to go over the first row, Alice believes that Bob, perhaps because he did what she thinks was the hardest part of the code, deserves 40 percent of her shares. Carol and Dave both did a good job, but they didn’t shine as much (from Alice’s perspective), so they get 30 shares only. By definition, Alice neither assigns any shares to herself nor save shares for a future round. The current distribution of shares is as follows:

Alice Bob Carol Dave
Shares 25+20+30=75 40+40+35=115 30+35+35=100 30+40+40=110

Step 2: Feedback

Now it’s time to learn, so that everybody can adjust and contribute even more to the general cause. The way in which we promote that the organization learns more about itself is by making sure everyone gives feedback to everyone else. One way of doing this is using the retrospective format. Because this is a somehow distributed team, they have decided to give feedback on a one-to-one basis. The rule is that all the feedback sessions have to take place no later than one week after the sharing out. They then summarise their feedback in another table:

Alice Bob Carol Dave
Alice Better testing More pair programming More involved in tech stuff
Bob Give dev a try! More pair programming Less marketing/More game design
Carol Answer emails!! Half glass full Less bossy
Dave Less perfectionism Less perfectionism Give marketing a try

2nd month

Second month starts, each one makes an effort to work even better, producing even more value than before. They now have some 4k users on the web and have just released the iOS beta. They also have avid followers on Twitter and Facebook and people have started buying bigger turtles, but not that many. There have also been a couple of nasty bugs in the game, most notably users of Internet Explorer saw in horror how their turtles morphed into scorpions when they hit the wrong combination of keys.

Step 1: Sharing out

Once again, each member of the team has to distribute 100 shares among the rest:

Alice Bob Carol Dave
Alice 30 30 40
Bob 15 45 40
Carol 25 35 40
Dave 40 40 20

We have just “printed” 400 new shares, which do not invalidate the ones distributed in the first round, but are simply additive. So the current distribution of shares today is as follows:

Alice Bob Carol Dave
Shares 75+80=155 115+105=220 100+95=195 90+120=210

If a big games company were to come with a fat wallet and decided to buy the company for 1M$, the money would be split like this:

Alice Bob Carol Dave
$ 193750 275000 243750 262500


What happens if Erin joins at a later stage?

In short, nothing too special. The only change in the system is that the organization will start “printing” 500 shares per round instead of 400. This means that inflation/devaluation of shares will grow at a slightly higher rate than before. This should be compensated by the fact that now the company is more valuable because Erin has joined. Time will tell which factor will outweigh the other.

What happens if Carol decides to leave?

Again, nothing too special, besides the fact that there will be 100 less shares per round. She obviously keeps all her shares and could even receive some shares at a later stage, if someone else would like to praise some work she had done in the past (e.g. having an idea that materialized after some time).

But why do we keep issuing the same amount of shares over time? Isn’t value supposed to grow with time?

Hopefully value will grow with time, but it can also decrease in ways no one can predict (nor understand in my opinion). Because value is so immaterial, I believe we’re better off keeping the system simple and adjustable, always considering that fairness can always be reached in the mid term. Always remember that distribution will be readjusted every month, no matter what.

Isn’t it too exhausting to do this every month?

Maybe. As mentioned before, this is just an idea that some are about to try out. Groups could perfectly decide to change the frequency of the sharing out.

Is this scalable?

I believe that the concept can easily scale recursively. For instance, suppose that AngryTurtles is just one team in a bigger organization. Say there’s also a group developing an app that gamifies tax collection duties called TaxeeDriver, and another one that is building a social network for bikers called Tirez. For the sake of simplicity, let’s assume that each group has 4 members. Sharing out is done in two steps:

  1. Each individual shares out 100 among the other 2 teams as a whole. We then average sharing, and determine, out of 100, how many shares gets each team as a whole.
  2. Each team then applies the usual sharing out algorithm, but only sharing whatever was left to the team as a whole, according to step 1.

What if I don’t know what others in my group do?

Then this system is showing you (early on) that you have a big problem. I believe a tool has done a great job if it exposes a weakness in your current situation when it becomes hard to apply as is. The nice thing about sharing out every month is that it triggers the need to become a bit more curious and perform an action so many people hate and avoid: ask.

What if some people in the group don’t understand/value my work?

Then this system is showing you (early on) that you have a big problem. I’d rather you found that out after working together for a month, than learning in two years’ time, when a VC offers to buy the company and you have, for the first time, the uncomfortable talk with your partners about the value of the work of each other. Even worse, you could learn about this situation at the coffee machine. Truth is useful, but not necessarily nice. Hiding is always safer in the short term.

The decision leg: Consent+Liquid Democracy

For this leg I plan to use a combination of off-the-shelf methods. The idea is to resort to two different methods, depending on the size of the group.

I’m no expert in the subject, but so far I like explaining consent as “weak consensus.” Basically, we have an open conversation on the pros and cons of every possible decision, and we go ahead with one given option unless there’s a paramount objection by any of the members of the group.

Liquid democracy (inter-group)

At a bigger scale (such as policymaking that concern a series of groups), consent can be too expensive. Liquid democracy (as implemented in the LiquidFeedback software), consists of a delegative democracy, in which delegation is dynamic (I change who I delegate my vote to at any moment in time), granular (I can delegate my voting for only a subset of issues), and “deep” (A delegates vote to B, who can delegate both votes to C).

The membership leg: Cliques Are Beautiful

In terms of income, the members of the cooperative shouldn’t worry about an unproductive newcomer. If the individual is not adding value, he/she simply won’t receive any share. Nevertheless, a new member will have equal voting rights, which makes the question of membership/belonging non trivial.
In order to decide who’s in and who’s out, I say we give the following recursive pseudo-algorithm a try:

  1. Everyone (in the world? LinkedIn? Twitter?) must answer the following question: “Who would you rather work with in a team next Monday?”
  2. We search for “weak cliques” in the (social) graph. Dense areas are, simply, new cooperatives.

This graph should be updated constantly. This mean that anyone can remove their bond to other person at any time, which should receive some kind of warning if he is about to “fall out of the clique.”

General FAQ

Does this work?

I honestly don’t know, but I’m dying to give it a try. More on that in an upcoming post. In the meantime, join the conversation here.

Do you envision any particular area of business where these ideas could work?

In general, I believe that any complex endeavour being tackled by at least 3 people could benefit from a system like this one. In particular, I believe that software development companies that would like to work on products but do only projects/consulting, could get together, add up their slack time, and form a LiquidOrg that builds great products. Sort of like open source, but for profit. Sort of like crowdfunding, but instead of money people put work.

LiquidOrgs – first draft

10 thoughts on “LiquidOrgs – first draft

  1. You should share your idea with @EmprendingUBA, I´m sure that a lot of entrepreneurs will get a try, it sounds quite laborious but much more fair than the way it´s done today.

    1. Hi Bel, I just tweeted asking @EmprendingUBA for their feedback. The idea of doing this monthly is giving people/parties the opportunity to quickly adjust. The whole group could decided to do the sharing out exercise with longer intervals, but then the cost of failing gets higher.

  2. Hi Alan, thanks for hinting me at this piece! Those are interesting thoughts, and I like the starting point of saying that we have Lean Startup and Agile for certain org problems, but that we need something more. My reflections on the “Three Legs”: The first doesn´t really seem to be about “Agile Ownership”, but more about “Agile Pay”. You probably look for fairness and appropriatedness in pay. Which is good. But the method you suggest here clashes a bit with one fundamental principle of pay systems that Alfie Kohn aptly formulated: “Pay people well, pay them fairly, and then do everything to get the money out of their minds.” Meaning: Let´s not over-engineer pay. Let´s not make it the focus, because it isn´t.
    You will find a little more about this in my paper here: I hope this could be part of a framework for all agile orgs!
    On the other legs (Decision-making, Teams), I am sure you will find a bit more about in my book Organize for Complexity. Looking forward to your feedback on the book!

    1. Hi Niels! Why do you say that this is about “pay” rather than “ownership”? The challenge, from my perspective, is actually to gradually get rid of wages and start real sharing (just like you mention in your paper!). In this particular example, Alice, Bob, Carol & Dave are building a startup, so this numbers mean shares (aka ownership). I’m intrigued!

  3. I believe that an interesting variation to the $ leg could be for each team member to present her top 10 value additions in that month (tangible AND intangible, it shouldn’t be allowed to present 10 tangible value additions.), and other team members should distribute 100 points among what they perceive as the top 5, which can’t be to the 5 tangible exclusively.
    Regarding the Consent leg, there is a nice – wicked issue- dialogue mapping tool by Jeff Conklin from, which aims to achieve consensus. The challenge is to automatize this process on a mobile collaboration platform.
    Lastly, the self organized process you propose for who should get fall out of the coop, with early alert messages, sounds OK.

    1. Hi Fabian. It sounds like an interesting tool for a pre-sharing moment. Gotta start experimenting with all these idea soon!

  4. Más que interesante Alan. Nosotros estamos implementando (early phase) algo similar para premios, y esto nos viene super bien para pilotear en el desarrollo de plugins, dado que deseo que los equipos sean “dueños” de los resultados de lo que éstos generen.

    Me interesaría conversar un rato personalmente contigo.


  5. Alan,
    This is very good, I watched the video. In the last end of year review I was frustrated about a process defined a priori with certain criterias for all team. I thought there should be a way that teams can decide what and how to evaluate them according to contribution to the team objectives and that they can be aligned with the company goals of evaluation. I would like ot think options on of how to use it for bonus and performance evaluation in teams.

Leave a Reply

Scroll to top
%d bloggers like this: