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

Why?

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

FAQ

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.

Consent (intra-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.