The Teal Conspiracy (or Utopia might just as well be around the corner)



Buurtzorg (or the potential seed?)

Frederic Laloux might have done a thing or two in order to accelerate management (r)evolution with his book Reinventing Organizations. In my humble opinion his main (and timelessly awesome) contribution has been to cast a smart and focused light on some organizations many of us hadn’t (incredibly!) heard of before reading the book.

The one organization I will mostly refer to in this post is Buurtzorg. Buurtzorg, a neighborhood nursing organization I’m planning on seeing first-hand this October, is (or at least seems to be after reading the book) just oh so amazing. With 8000 professionals and counting, Buurtzorg is nothing short of a self-organization marvel, with over 99 percent of its members belonging to completely autonomous teams of no more than 12 people. These teams, composed entirely of nurses, are entitled (and expected) to decide on everything that concerns their daily work. From finance to so-(awfully)called human resources, everything is in their hands.

Buurtzorg not just works. Buurtorzg has grown in less than 10 years to own more than a 60-percent share of the Dutch market and has proved to be way more productive than their competitors according to several studies. Needless to say, patient and employee satisfaction have flown way past the ceiling.

A tiny little sip of Dr. Marx (or a quick reflection on the traditional consultant and software professional organization)

I haven’t directly read any of Karl Marx’s texts. I don’t subscribe to all of his ideas. I dislike most of the so-called implementations of Marxism so far. Nevertheless, there’s undeniably a sizable number of invaluable ideas in his texts. Surplus might be just as well one of those.

Surplus, as I have managed to understand it, is the money the factory owner (to take a common scenario) keeps after selling an industrial product and paying the worker who built it. If the company CarsRUs produces cars, then the owner of the company (let’s call him Mr. Henry) ends up cashing the difference between the value that customers pay for the cars and the salaries the workers get.

After a weekend of introspection, a given worker at CarsRUs (let’s call him Ernest) could perfectly propose to some of his colleagues (let’s call them Rose and Tony) that they should say thank you very much to Mr. Henry and set up their own, worker-owned, car factory (let’s call it CarsOrg). But wait, a slight detail gets right in the way of their dream. In order to set up a car factory one needs capital, a whole lot of it. Dough, moola, dinero. They don’t have it, so back to the factory my friends.

Generally speaking, in order to produce physical goods one needs a substantial amount of capital. But I don’t want to delve too much into the woes of this part of the world of work, specially considering that I have spent all of my professional life in a different neighborhood. I have so far had two different, closely linked professions as yet. I have spent six years as a software developer, and so far ten as a management consultant (mostly for the software industry). Both jobs can be encompassed in the broad category of knowledge work. I have a feeling that designers, marketing professionals, managers, and a plethora of other non-manual workers could easily be added to this group.

What makes knowledge work so special in the context of this discussion? To put it blunt and sweet, the colossal gap in capital that is needed to build a product (e.g. a software application or marketing plan) or provide a service (e.g. give advice to a CEO on how to run her company). In essence all you need to build a software is you. Yeah, you also need a PC (a fairly old one might suffice in many cases), an internet connection (there’s probably free WiFi thanks to your mayor), and an office (if you live under a roof that should be a magnificent start). Capital needed for knowledge work is marginal. I’ll repeat it just in case. Capital needed for knowledge work is marginal. In order to discuss a more concrete example, now let’s dig deeper into the prima donna of what French call the cognitive capitalism: software development.

State of the (dis)union (or why Mondays might still suck big time in our industry)

Software development is in itself a very complex universe. In order to try and comprehend the incommensurable we usually resort to taxonomies. I’ll be no exception this time. After a handful of springs immersed in that universe, I could sketch the following categories:

  • The product guys: These organizations develop and market software one way or the other. Taxonomy boundaries in the real world are always fuzzy, but you can easily think of Google, Microsoft or Gabriele Cirulli.
  • The IT guys: These guys develop software internally for a company whose main business is not software. Think of a particular department inside of McDonald’s or Walmart. More often than not these guys don’t develop software themselves, but rather outsource most of the job to the next group of guys.
  • The services guys: Software factories, software consultancy, we-develop-whatever-you-ask-for, they sport many names. These guys simply develop software for others. Think of Accenture, Kinetica Solutions and even a good deal of what IBM does for a living these days.

In order to gain even more focus, in this post I’ll specifically deal with the last guys. The ideas could eventually be extrapolated, but today is not the day that’ll happen. Let’s double click and turn to a new taxonomy (we just can’t have enough of them!). We’ll categorize this series of organizations into the following groups:

  • The Mammoth Hierarchical Multinationals Galaxy (aka The Taylors):Vast masses of developers and the like (testers, ops guys, etc) usually billed by the hour. Here you can find the Capgeminis and the Cognizants. The galaxy also includes zillions of differently sized celestial bodies made up by those small- and middle-sized wannabes, who haven’t reached the status of mammoth, but who would love to join the club. Gazillions of cognitive workers plod through working hours for years, sometimes without ever stopping to reflect on how alienated they feel. This is barren land for our seeds.
  • The Smaller Horizontal Companies System (aka The Tealish):I have encountered many small (tiny in comparison) companies that mostly work in a fully self-organized way, from decision-making all the way to profit sharing. From memory I can name Tecso or 10Pines. Here may lay the seeds I’m longing for!
  • The Freelancers Asteroid Belt (aka The Lone Rangers):This astonishingly sparse mass of free roaming brains, who sometimes migrate for a season or two to other continents, lacks any organization whatsoever. They seldom collaborate among themselves. Wasted pollen perhaps?

The asteroid belt is constantly being monitored (and eventually milked) by a parasitic subclass:

  • The Pimping Satellites (aka The Broadway Danny Roses): Big and small, intermediary firms act as opaque profitable proxies between clients (usually big ones) and freelancers. Except for exceptional cases, a systemic plague.

On the need to conspire (or why simply multiplying the Tealish might not be enough)

Small is beautiful, I agree. Big is usually clunky, uninventive, obscenely bureaucratic and heartless. And yet big has its pros. What makes big sometimes attractive? Why do big clients usually choose to work with big providers? Obviously a plethora of contextual reasons come to mind, but in my experience the constant is what I call staff elasticity (i.e. “I ask them for a 100 guys for tomorrow and they respond”). And why do people choose to join the big? Again your mileage may vary, but again I’ve encountered a constant: job stability (i.e. if the contract with this client gets cancelled I’ll still have a job). I call this private unemployment insurance.

Yeah, I know, I’m oversimplifying here, but can you at least buy that there can also be a plus side to being big? Good. So the next question would now be if there is such a thing as big and beautiful? Well, Buurtzorg anyone?

Wait, why do you keep referring to the color teal? (or a nano-summary of Reinventing Organizations)

I have borrowed the term “teal organization” from Laloux’s book. These organizations represent, according to the author, the highest level in terms of consciousness. They stand on three pillars: self-organization, wholeness and evolutionary purpose. Intrigued? Go read the original then!

I have a dream (or let’s get together and work all right)

My dream is simple. I’d be thrilled if a software development Buurtzorg showed up. Completely self-organized, obscenely productive, and with staggering levels of job and customer satisfaction. The both urgent and poignant question should then be why haven’t we built yet.

Why can’t the freelancers of the world just unite? Why can’t all those Tealish small companies merge into some kind of symbiotically bewitching federation? What is really stopping us?

Here be dragons (or a hypothesis on why the dream hasn’t materialized yet)

Call it confirmation bias if you will, but when asking myself this last question, I have ended listing the same three points I had listed some time ago when drafting the idea of LiquidOrgs. In this case I’ll rephrase them from the following perspective: suppose you belong to either the The Tealish or The Lone Rangers, why haven’t you merged/joined with another/a Tealish organization (respectively)? Being (as usual) overly simplistic, I’d say the answer usually stems from at least one of these fears:

  • Will I get a fair say in the way things are done? This is the realm of decision-making. Fears here include the likes of “Those guys at company X are smart, but they love keeping the last word on important issues.”
  • Will I get a fair compensation for my work? This is the realm of money. Fears here include the likes of “I wonder if those guys at company X value my work the way my friends at company Y do.”
  • Will I get to work with the people I respect? This is the realm of team composition. Fears here include the likes of “I generally respect the guys at company X, but I wouldn’t ever work with either A or B. Gosh, I wonder who opened the door to those schmucks in the first place.”

Strictly speaking the money and team composition realms could be included in the decision-making one, but I find they are so ubiquitous, that I decided it made sense to upgrade them to first-class citizens in this humble model.

Crafting a practical utopia (or what could be the first steps?)

In the aforementioned link I have drafted a very basic proposal to address these three fears. I know, they still need to be harnessed in real life. Buurtzorg and so many others have been showing that full-scale self-organization is not just possible, but it also makes so goddamn sense. What is my proposal? A journey of thousand miles always begins with one single step. If our destination is far away then we’d better start walking now. The Tealish might be the seeds. Let us get together, discuss our Tealish ways, learn from each other, dream up ways of collaborating, and hopefully the software Buurtzorg (or its evolved equivalent) will be born in the most beautifully organic possible way. I will start where I live with the people I know. Buenos Aires (Argentina) and the local Ágiles community. I’ll send a meetup request tonight. Let The Teal Conspiracy begin. Or not. Alea jacta est.

Retrospectives series: Big event in a team



Here is a new idea for you, my friend facilitator, to try out in your next retrospectives. The core of format is based in a tool from my ORSC teachers from CRR and Augere, and I added some ideas over it. I have already applied this format a couple of times with success in authentic multidisciplinary teams. A strong commitment and smooth conflict solving were the results of applying it.



This format is ideal to help a group finding problems after a big change, any event with a big impact in the team morale. As a facilitator, you would notice that a team requires this exercise when they are stuck, the group is not being able to step front and realize that their circumstances have changed, and this change requires to redefine the rules of their relationship. A possible outcome of this retrospective is a new team agreements collection, or even a whole set of actions to try out, possibly including big radical changes (kaikaku) to their working processes.



90-120 minutes for a 7 people team member.



This is a format very much oriented to people and their interactions. The main driver is a conversation where they facilitator will launch some question to the team and will guide them to close the old times and start new ones.



No specific materials are needed for this retrospective, except for the ones you decide to use to collect data, ideas or actions.




It is a good start for this retrospective to invite the participants to do a short game:

– Choose one team mate, get together and look at your partner’s eyes. During all the time you need to keep eye contact with your partner. Think, what is your favorite characteristic of this person? Think in silence, and later tell him. Change pairs until everyone met everyone.

This intro, if the members follow the facilitator, helps setting a private link between the team members, this intimacy is a very important part of a high performance team. For this retrospective, where we will be dealing with personal problems, it’s a good start to reinforce personal connections.


Here are the questions that the facilitator should ask:

– What is happening in the team now?

– How is that different from how things used to be?

At this moment, the facilitator should help the team understand (if that’s the case!) that the conflicts they are having are related to the circumstances and conditions changing. It’s the moment to help them realize that it’s a normal situation (again, if that’s the case!) and they need to close a period in their time and start a new one. You can continue throwing questions:

– What needs to be grieved, honored, acknowledged… from the old period?

– What is possible for the team now?

At this moment, the facilitator must decide how to continue. A good option would be helping the team to define their new working agreements, but if the situation is good enough you might even continue with the “heaven and hell” format explained in the last article.


According to the facilitator’s decision.


According to the facilitator’s decision.


Previous articles in the series:

1.- Le tour de France

2.- Heaven and Hell


Retrospectives series: Heaven and Hell



This is the second article of the retrospective series, I hope you enjoy it, find it useful and can apply it with your team soon. Please, leave some feedback when this actually happens!

This retrospective is titled “Heaven and Hell”, soon you will learn why…



This is a good retrospective format for teams who are either about to start a new project or going through the first stages of it. It’s not as powerful in the later stages of a project, but as usual your mileage may vary. Last year, while studying ORSC (Organizational and Relationship Systems Coaching ) I came up with this retrospective format, mixing some concepts from that course and other ideas from my own toolbox.



60-90 minutes should be enough for a 7 people team



In this retrospective format, the facilitator guides the team across the best and worst possible future scenario for the team. You will help the team taking actions to reach their heaven and avoid moving towards their hell.



As a facilitator you are encouraged to help the team jump into the metaphor, so any help through visual and auditive channels will help on this purpose. I have tested drawing images from hell and heaven on a whiteboard, but obviously any graphical, auditive, multimedia or even atrezzo you might come up with will be really useful in that sense. Remember that using different channels makes metaphors more powerful, but learn the limits of your team and the depth of the conflict you are dealing with.




This retrospective format will be more useful if you start the session with an exercise of team recognition, it will create a gratefulness environment which will boost the results in the next stages. For instance, every team member is asked to think about what good things his colleagues have done in the last period. Write each thing in a different sticky note. After some thinking and writing time, have each one of them speaking out the rewards he wrote, and show them in any visible board. This board can be kept around the work are during the next sprint.


Tell the team to think for some minutes in silence on the future they aspire to as a team.

– What would be heaven for that team? What elements should be in place? What should we be doing?

Give them some time to think and write.

– What would be this team’s hell? What should be happening so that we notice that we are “burning alive”?

Again, give them some time to think. Needless to say it might help to ask them to think in terms of opposites with what they had proposed in the previous step. At this point you don’t need to offer them so much time, not only because they will come up with counter-examples of dreams, but also because it is more productive to keep them in a “dreaming” mindset than in a “nightmare” one. The feelings that arise when dreaming are positive and boost ideas and creativity,  unlike the ones coming from nightmares.


Invite everyone to explain their points, and if you used any physical space for describing heaven and hell, have them post the ideas in the right place.

Then have them cluster the situations they initially described, because some of the concepts might be very concrete and others might be very open. As a facilitator, at this moment you want the team to name their dreams together, so you need to help them bringing all their dreams and nightmares to a common ground.


Help them define actions to move to their heaven, and try to guide them as much as possible through the heaven actions. However, lead them to agree in, at least, one action to try to avoid their hell.



Previous articles in the series:

1.- Le tour de France

Retrospectives series: le Tour de France



This is the first of a series of articles we will be posting in our blog about retrospectives formats, tips and advices. We will start with one based in “le tour de France”.

Here is a link to the second of the series.

Le Tour de France

This retrospective is specially created to gather data at the middle of a project or any long period of time, when teams have already reached some of the goals they had and still have to fight for new challenges. It’s also a valid format for a post mortem if you only use the elements related to the past. This retrospective was created and facilitated by myself with the management team at Studio 1.

The activities described in this retrospective can be performed in 60-120 minutes, requiring longer time for large groups. Since it is a retrospective for long periods, you might require up to 120 minutes depending on the group size and the time period.

With this retrospective format, the facilitator will guide the team through a metaphor with a cycling sports team.

Depending on how you decide to set the stage you will have to work more or less. Apart from that, you will need post-its, without any special attention to their colors.


The facilitator creates a stage linking the project that has just been finished with “le Tour de France”. For a retrospective after a project milestone, the facilitator can explain that the situation is similar to the end of an important lap in the cyclist race. The facilitator must use any visual or auditive channel to help the team jump into the metaphore. Screens with videos, sounds, music, atrezzo… anything you can think of. The goal is to help the team jump into that scenario.

After creating the introduction, in order to help the team jumping into their memories, you can ask every participant about their physical state at the end of the lap we have just finished. A quick verbal answer per person should be enough to understand everybody’s mood. With this easy exercise you have prepared them to navigate into the metaphor, although any other thing that helps them start remembering is perfectly fine.

In the first part of the retrospective, the facilitator helps the team to navigate through the last times, asking them the next questions:

– What were the injuries and accidents the team had? These represent the problems we’ve had.
– What were the highest peaks we reached? These represent the challenges we’ve had.
– What were the prizes we have been rewarded? These are the recognitions the team has to do to their members.

There must be a physical space where the team members can put their post-its with the information required by the facilitator. Please, remember the visual and auditive channels!

The second part of the retrospective is focused in the near future. Now, looking at the rest of the race…
– What are the hardest peaks we have to reach? These are the challenges we are going to face.
– What are the supplies we need to win the race? These represent the team’s needs for the near future.
– What are we fighting for? What is that price we will get when we succeed? This is the main driver the facilitator needs to point out when problems arise during the conversation helping the different people to align.

In this stage the facilitator needs to decide where to invest the rest of the time. Ideally the focus should be the future, however the team might need more ventilation or discuss in depth the past. Therefore, you can use any kind of team prioritization ( dot voting? ) to choose what of the many topics raised they want to work on. Any Root Cause Analysis process might be useful when discussing on the injuries/accidents.

The team should take actions to prevent the accidents happening again and decide what supplies they are going to prepare for the rest of the race.

Challenges coaching multidisciplinary teams



It is a great concept this multidisciplinary thing: Create a single team with all the different people required to deliver a service, instead of having different knowledge areas doing their part independently. Make them work at the same pace. Have them focus on the same goal at a given moment. Remove extremely detailed documentation to avoid delays and misunderstandings. Help everyone become a specialist generalist, so at least he can help his team colleagues when bad times come. Break the physical walls, so that they breathe the same air and feel part of the same organism. Tell them to self-organize.
Just break all those barriers that were artificially created with the old school enterprise paradigm. ( BOOM! )
Cool. Every Agile Coach finds this new organizational paradigm is far better ( and more exciting ) than the classic way of working, and we know it brings lots of joy when everyone understands what teamwork means. Most of the pains we used to have with that oldie organization disappear. Yey!!
Oh, wait… What is all that noise? What are these long faces? Why are these guys so mad at each other? Isn’t this new organization supposed to be free of all these old problems?
Some new challenges seem to appear from nowhere when all these different people have to work together. By shaping this multidisciplinary teams we wanted to destroy some of the artificial barriers in our organization, but some of these barriers were created by someone for his/her own protection back in time.
It is obvious that all these different people from different backgrounds also have different interests, different mindsets, different skills sets ( that’s why you want them together, don’t you? ), they approach problems from a different perspective, have different values and live life quite differently. Each different professional tribe embeds an idiosyncrasy to their members, shaping ghetto-like spaces: Sales, Finance, HR, Art, Engineering, IT… Each one is a different culture, with their own practices, symbols, language, leaders… Needless to say, they also share common experiences and myths in their relationship to the rest of tribes.
It is quite difficult to find people from marketing or sales who share personal values with someone from systems engineering or IT support. If the organization didn’t originally follow a strict recruitment process that had in strong consideration the candidate’s personal values, this new multi disciplinary team might even face bigger challenges. Hopefully, at least by chance, their members might share some of those values. But that’s not all of it. We often find organizations choosing candidates based on knowledge, intelligence, education… but what about evaluating their fears, their relationship to other professional tribes or perhaps checking how antisocial they are? Some times we find that extremely smart people, who you usually want around you, are too introvert and find it complicated to interact with other people. Maybe they don’t find it interesting at all! And that is fine, of course. It’s something you can expect from someone who spent lots of his lifetime learning introspectively instead of playing with others. Actually, perhaps other people have caused him pain for this and he has hard feelings. The problem is that in the agile context and without the proper coaching they usually find themselves misunderstood, with other people not being able to accept that they need help on this. Sometimes, they themselves don’t assume they need this help and either resist strongly until the agile transition fails or decide to leave to another company where this agile thing doesn’t bother them. It is sad, losing so much talent because simply nobody helped them in doing something they hadn’t done before.
When a new technology or a new tool comes to the organization, it seems so obvious that everybody who didn’t use it before needs training on it. However it doesn’t seem so obvious that these kind of profiles need help, coaching, support and guidance on these topics. These are the topics we have to overcome in a transition to agile. It’s never just about changing the organizational processes. The main job that needs to be done is way deeper, it’s about bringing together people that eventually have hard feelings to each other.
Communication is now one of the biggest challenges: when trying to be agile people have to dedicate a lot of time to speak, listen and understand each other’s points of view, problems, needs and personal motivations. Not only they will have to align goals but they will also have to help and support each other, which is pretty hard when some team members show no interest for others. Being friends, sharing time and interests outside of the purely work-related is one of the keys to high performance teams. You can’t fake this. You can just create a safe space, bring experts and give time. Friendship needs to be honest, it takes time to generate the safe space required for this to happen and see people recovering from their old wounds. Obviously those deeper feelings were already there before we started with the multi disciplinary teams, but now with all those barriers protecting people gone, the wounds are way more visible and painful.
But while all this happens, companies need to continue with their business, as usual. They need to get things done.
Here is when some organizations realize that they need this new area of expertise, people who can help their teams to work in their relationships. Teams start needing people with the skills and knowledge to work on people relationships, people to water the garden, people who understand human nature and can see over cultural or tribal differences. The more strange the disciplines are to each other in a scrum team, the more complex it is to lead this team. These people have to be organizational leaders, and as leaders in this context need to have a wide range of interests, social skills and knowledge to understand and motivate all the members of the organization.
Each tribe values different things on their leaders, although there is a common ground: honesty, trust, competence, intelligence… Every tribe values these points, but also some specific values arise in each tribe.
Every tribe also has common anti-values for their leaders, like egocentrism, irritability, dictatorship… And again each tribe has some extra rejected values. Now this is when it gets really tricky.
Let’s consider an organization with a unique team, a multidisciplinary team of engineers creating a product, each one with knowledge of a different specific technology, but basically all engineers. It is quite obvious that the kind of leadership they will value should be brought by someone who shares the interests of engineering with them, who is smart because they value intelligence, and with experience in any of their fields of expertise, ideally the most complex one. But also someone who shares their “dark side”: enemies, fears… It’d be great if the leader could help the rest of the team overcome this dark side, but by definition it’s not required to succeed as long as they don’t interact with any other organization.
However, if your multidisciplinary team includes engineers, artists, designers, testers, customer care analysts, business specialists, data scientists… Leadership is now not just about knowledge, but new values arise and even the weight of each value is going to be different. This kind of team requires a cross-tribe leader who values and embodies what each tribe considers important in their leaders. Each tribe has different expectations on their leadership, and this is the most complex aspect of coaching organizations who really bet on multi disciplinary teams. What happens now with enemies and fears? Well, there is not much space here for dark sides. This leader must now understand the nature of those bad feelings, the root cause behind them and help the group overcome them.
The thing gets even trickier when an organization is multi national. This creates a second axis of complexity, because different national cultures also bring along different idiosyncrasies. This also has an impact on how we approach people, how we send messages. Effective leaders avoid ethnocentrism, find shared values across cultures, and embody the common values every culture expects. You can find a starting point to national cultures with Hofstede and his Hofstede’s cultural dimensions, but bear in mind that the dichotomic nature of this dimensions ignore lots of aspects, and you still need to use other approaches with a focus in individuals and their differences instead of Hofstede’s macro-focus.
This is the kind of problems coaches face when they have to work in authentically multidisciplinary teams, or when they have to coach at organizational level, in organizations without wide-ranging multidisciplinary teams. Again, it’s not about size, it’s about how different the team members are. And definitely it’s about what kind of person and what kind of leader you are.

Agilar as Belbin Team Roles Accredited professionals



Last February 2015, José Ramón Díaz and myself finished our Belbin Roles Accreditation Course. We had already used this technique, helping other accredited professionals to run the exercises with some of the teams we were coaching. After all this period, we can say that we find it a very useful and powerful tool to coach teams and help organizations.

As usual, a tool is just a tool, and the most important is how we use it. A tool can not decide for us, we must use it to lead to interesting conversations with our teams and perhaps finding improvements, but with the Belbin approach we get a systematic approach and very well standardized tools.

The Belbin theory explains the 9 different team roles that a team needs to cover in order to succeed. The belbin team roles study behaviors, not personality. By identifying members to the different roles we help leveraging the strengths of each role and managing the weaknesses the best way possible for the team. As I said before, it is so important to flourish interesting conversations after the report is sent to the team members, because misunderstanding a report can harm. However understanding properly the report and helping for improvement can definitely help a team in their way to become high performant. Obviously, a team that doesn’t want to be challenged is not a good target for this or any other similar tool. Only those who want to do self reflection and grow will find these kind of tools useful.

It´s important to realise that Belbin roles are not neither tags nor classification for people. It´s just an approach to interesting conversations and better understanding among people. Belbin reports might very well be oriented to an old school of thinking, even with reports for your boss. But we can transcend that, and create a tipping point in self-organised teams (where is the boss in Scrum?)

I am not going to bother you, our beloved and respected reader, with the theory of the Belbin team roles because you can find the official documentation in their site ( in Spanish or in English ) . However, there is a piece of advice we can offer: The content of the report simply rocks, and guided by great coaches this can be a kick-ass tool to help people grow.

If you are a Scrum Master or Agile Coach, I strongly suggest you dedicate some time to learn about the Belbin Roles. Furthermore, I strongly suggest you run this exercise to yourself. It can be so unveiling to discover that you need to modify some of the behaviors that are important for your job position, or even understanding what strengths and weaknesses others see in you to challenge yourself as a professional.

It was very useful for ourselves, I saw myself completely reflected in my report!

10 ideas to facilitate company retrospectives



Last week I had to facilitate a retrospective with 90 people from the same company. I have to say that it was very challenging to be just one facilitator. I could count on the help of great guys to prepare it, and 2 people inside the organization supported me during the event.

 The result was a success based on the results of the session and the feedback I got from the attendants, which made me decide to write this post and share some of the ideas I consider was important to obtain that result.

The next list of ideas is a mix of my thoughts before the retrospective and the feedback gathered from the attendants in the following days after the event.

1.- Open Space, but provide an action plan.

The main part of the day was formatted in an Open Space format. The open space format is perfect to have lots of interesting conversations and lots of ideas arising, but for its nature, one of the weaknesses is that no actions are taken there, but in the best case just a decision that requires further execution. Obviously this really depends on many things, but in a 90 people organization ( embedded in a 1500 people bigger organization ) some things require more people than just the ones who decided to start changing things.

So we went for a limited open space, but keeping the last time slot for action: During that time, every person should choose his favorite action proposed during the day and in group should start working in the next steps to achieve that action: dependencies, required people, time restrictions…

As a result, we left the event not only with an action, but also with an action plan. So the feeling of “nothing will be moved” was decreased.

2.- Create a Timekeeper team.

As facilitator, one or your responsibilities is to hold the time. In these events, people usually get passionate about the topics, even the session facilitator which is usually the most focused on the topic he proposed. It’s your responsibility to ensure that all the sessions proposed in the market can have their time, and we leave the event on time. You cannot expect a group of 90 people to give you 15 extra minutes under the excuse of being such a special day. People have other commitments.

For this reason, at the beginning of the day, bring to the stage all those people who need to leave on time. Make them look at each other, give them the goal to hold the time. Now they are a team, they are the timekeepers. The rest of the attendants, they should give this team the responsibility and therefore assume that when one of them reminds him about the time, it’s for the good of all those people there.

3.- Hold the space. Use every channel to help people navigating the right emotional fields at any time.

Use music, videos, papers, foods… Anything you think it’s important and useful to help people move from one emotion to another through all the day. For example, you might want them to end up the day with energy, so why not lots of sugar and happy music to finish the event? What about the beginning? If you need them to start remembering, thinking on what was the last year for them, Wouldn’t it be great to have some calm and safe environment with private conversations about myself, or recognitions, over a calm music base with a beach sunset on the screen?

4.- Be inspiring. The whole event.

A company retrospective is not only about improving processes, but also about offering strong energy for the next year. You usually find teams who have experienced a hard year, and lots of complex discussions will take place that day. Navigating to a different reality level helps people solve conflicts. Have them remember good times they lived together, or dream future successes. Have them feel again the same positive emotions they experienced together when they met, or when they succeeded together in the past. These are key secrets to help teams switch from a fighting to a building context, which definitely takes them to the required mood to solve problems.

5.- Honor and mirror the attendants. Continuously.

Everyone who is really giving their best this day, and most likely it’s a high percentage of the attendants, are deep in their conversations, and lots of emotions arise. As a coach, you can mirror what you are seeing, but never show interpretations on the signs you see. For example, you might see some of the attendance are smiling, others exhaling, others might decide to sit down on the floor. As a coach, reflecting those behaviors and asking what is behind them makes the whole group aware of what is going on. Don’t ever run the risk to express what you believe is behind the signs, because you might be wrong and could generate noise in the group.

On the other hand, it is really good encouraging people to continue giving their best, energize them and support their passion. Give a clear vision on the agenda for the rest of the day, and let them know how the timing is going. That way everyone can control the energy he puts in every moment.

6.- This is a self-criticism day. Don’t jump to discuss before everyone understands it.

When teams start a big retrospective they tend to come with lots of ideas to change in others: my manager, another team, another department… But they forget that it all starts on themselves. Nothing will really change if they don’t understand they all need to make an internal change, and give their best to make impact on the next year. Again, use all the channels possible.

7.- Get ready to leave your agenda if the team needs it.

During the event, interesting things might happen and you might want to break your agenda partially to work deeper in any topic. Don’t be afraid to do it if you see a big impact on it, everyone will understand the value of solving the most critical issues and will be thankful.

8.- Some sessions might require expert facilitators.

It is an open space, so you won’t limit how many people decide to join and discuss on a topic. The hottest topics might be really crowded, and without the help of an expert facilitator, the session might be time wasted, with nothing agreed. After the initial ideas market, if you have asked the attendance to say what sessions they are interested, you can help the facilitators to prepare the hottest topics, giving them ideas on how to organize the session or simply asking them to facilitate the session yourself.

9.- Don’t be too pushy with your voice, use visuals instead of sounds.

Use visual resources instead of your voice, they are as effective as the second but they do not interrupt conversations.

10.- Some topics might require longer time to discuss.

Because we want to leave the day with actions, if during the market you see any topic that might be super hot, or the facilitators mention it, don’t feel bad to propose a longer time slot for that topic. However, if you allow this, many other facilitators might want to extend their sessions, so take care and ensure they understand when it is allowed to do it. If during the sessions you realize nothing is going to come out, and it is not due to lack of facilitation but because the topic is more complex, ask the whole organization what they want to do.

I hope these 10 tips are useful for you when you have to facilitate the next event. Please, don’t hesitate to write back with any feedback or more ideas.

Adelanto #3 de “Por un scrum popular” – Mi introducción al libro



Entre los tantos miedos que pueblan mi vida, el miedo al trabajo mecánico es sin duda uno de los que me acompaña hace ya décadas. Tal vez producto de mi ansiedad y neofilia, camino por el mundo buscando novedad, cambio y sorpresa. Cuando Tobias me preguntó si quería traducir The people’s scrum al castellano, dudé y, lo admito, sufrí por un rato. En términos de mi camino en el mundo de la agilidad, me crié de la mano de Tobias y sus ideas. Durante varios años maduré conceptos (y por suerte descarté otros tantos) luego de revisarlos con él, escuchando, siempre sorprendido, sus ideas sobre el mundo. Ahora me tocaba devolver tanta generosidad, tantos años de consejos, realizando una tarea (¡el horror!) mecánica. Por suerte acepté. El favor me lo hice, sin duda, a mi mismo. Traducir este libro fue volver a mis fuentes. Una excursión trepidante a la mente de mi mentor, llena de energía, ideas y, por suerte, contradicciones.
Ahora, yo si fuera usted, lector inquieto, me estaría preguntando en este momento cómo demonios puede convertirse un trabajo aparentemente mecánico en una excursión trepidante. Exploremos, pues. Tobias, tal vez a sabiendas de mi pánico a la repetición, me aclaró que deseaba que yo sea coautor de esta versión ¿Intrigante, no? ¿Qué vendría a ser el coautor de una traducción? Ni él ni yo lo sabíamos, pero Hillary, nuestra editora, aceptó la caminata por terreno neblinoso y arrancamos a caminar. Propuse en seguida no pensar en esto como una traducción, sino como una “variación lingüística”. Me encantan los términos grandilocuentes.


Como buen pastor de estos bueyes, creo firmemente que la acción precede al pensamiento. Hago, luego aprendo. O sea, empecé a traducir, sin rodeos, a fin de romper la inercia. Arrancar, cuando uno se encuentra en la más completa quietud, es todo. Hacía años que no escribía algo más que un mail. De repente, pomodoro a pomodoro, sentía ese dolorcito único en la mente, placentero, prometedor, propio de quien sale a correr al parque tras años de sofá y TV.
Traduje todos los ensayos con mucha menos necesidad de improvisar de la que me imaginaba originalmente. Eso sí, tenía muchas, muchas ganas de opinar. Me moría de ganas. Tobias opina cuando escribe y la opinión, si es interesante, casi siempre genera opinión. Fue así como se me ocurrió la idea del anexo tendencioso. Anexo implica una ligazón, una dependencia absoluta con un algo. Ese algo sería el ensayo. Luego, algo es tendencioso cuando se manifiesta con parcialidad hacia una cierta tendencia o idea. Quise volcar, sin un análisis demasiado sesudo ni pretendida neutralidad, lo que me venía a la mente después de leer a Tobias. Fue en ese momento cuando pensé, relajando por fin los músculos de la cara como antes de sonreír, que tenía un libro entre manos.

Allegro popolare

Solo faltaba una cosa: el título. Traté de explicarle tanto a Tobias como a Hillary las distintas acepciones que podía tener el people del título original. “Gente”, “pueblo” o “popular” pueden resonar muy distinto en cada individuo. A “El scrum de la gente”, tal vez traicionado por mi origen argentino, lo descarté rápidamente, harto del abuso mediático que suele hacerse de ese sustantivo. “El scrum del pueblo” ya estaba un poco mejor. Tobias disfrutaba de la connotación protopolítica del término, pero yo no veía la relación directa entre ambos conceptos. “Popular” es una palabra mucho más polisémica que las otras y eso me encantaba. Disfruto de los términos que se desdoblan en interpretaciones que a su vez encuentran sus respectivos caminos.
“Popular” puede perfectamente interpretarse como algo relativo al pueblo, así que el primer paso lo dábamos con el pie derecho. La idea de pueblo no estaba mal, pero le faltaba potencia. Entonces llega un nuevo significado: “propio de las clases sociales menos favorecidas”. Ya empezábamos a dar en el clavo. Conociendo a Tobias como lo conozco, su obsesión es la capa más baja del tejido corporativo. Lo que en Argentina llamaríamos “el laburante” (sí, lo pensé, “el scrum del laburante”, pero la idea es cruzar fronteras con estas ideas) constituye el objeto de sus propuestas. El trabajador raso es, desde mi punto de vista, una clase en sí misma ¿Desfavorecida? De eso se trata el libro al fin y al cabo.
La historia de las acepciones no termina ahí. Habrán notado ya como, a lo largo de todo el libro, nos referimos al framework en cuestión como “scrum“, claramente con minúscula ¿Ya les dije que me gustaba lo grandilocuente, no? La primera vez que leí el término escrito de este modo pensé, sin titubeos, que Tobias es nuestro humilde Prometeo. Listo, scrum es nuestro, Tobias lo robó. Lo único que necesité hacer fue avivar un poco el fuego.
Es cierto que “popular” tiene una última acepción que parecería tirar todo lo anterior por la borda. El scrum que buscamos no es aquel que persigue obtener popularidad, ser el más elegido, ganar la carrera. Pero nada se descarta, todo se aprovecha. Este significado nos da pie para darle una nueva vuelta al término y poder afirmar, abrazando plenamente las contradicciones y complejidades propias de las ideas que valen la pena, que el verdadero scrum popular será, al menos en un principio, eminentemente impopular.


No estoy seguro sobre qué tipo de lector se encontrará con estas líneas. No sé si será el experto o el recién llegado. No sé si será el escéptico o el defensor a ultranza. No sé si será oprimido u opresor. Lo único que espero es que al terminar de digerir este texto, ese lector imaginario pueda cerrar los ojos y sentir, con una tímida sonrisa, que el próximo lunes las cosas tendrán que cambiar, pase lo que pase.

Opresión corporativa (Adelanto #2 de “Por un scrum popular”)



Opresión corporativa

Opresión: Carga impuesta de manera injustificable sobre algún individuo o grupo, que se lleva a cabo luego de interferir con su poder, intereses u oportunidades. La opresión puede ser intencionada o resultado involuntario de una cierta disposición social; puede ser reconocida como tal, o puede resultar inadvertida por aquellos que están siendo oprimidos.
The Oxford Dictionary of Philosophy

Solemos visualizar la opresión sólo cuando es explícita, por ejemplo en aquellas situaciones en la que se utiliza como arma para sojuzgar a los derrotados o para apaciguar cualquier tipo de agitación o deseo de revuelta entre las clases más bajas; pero la opresión existe de muchas maneras distintas y no solo afecta a los más pobres y marginados. Podemos descubrir varios niveles de opresión en las grandes organizaciones hoy en día, ejercida con gran brutalidad, discreción y delicadeza sobre profesionales de clase media, que disfrutan de excelente paga y beneficios envidiables.

Tomemos como ejemplo la cultura del cubículo, tan arraigada en nuestras mentes como la manera correcta en la que se trabaja en el mundo del software, incluso luego de más de 10 años de agilidad. Aislar a alguien en un cubículo es un acto controlador, que tiene como objetivo lograr obediencia y encuadramiento. Las cárceles en el mundo entero apelan al concepto del confinamiento en soledad como forma de castigo—hasta se podría hablar de un castigo que limita con lo cruel e inusual: así de antinatural nos resulta a las personas estar alejadas de nuestros pares. No hay que desafiar los límites de la imaginación para encontrar las similitudes entre el cubículo corporativo y la celda unipersonal. Sin el apoyo de sus pares, un individuo es mucho más vulnerable a la sugestión y estará más dispuesto a acatar cualquier instrucción ¿Será esa la intención explícita cuando se arma una granja de cubículos? Seguramente no, pero el resultado sigue siendo el mismo.

La opresión va mucho más allá de la distribución física en las oficinas. Día a día se suceden crueles juegos de poder, casi siempre con gran fervor por parte de aquellos que habitan las más altas cúpulas, pero con un entusiasmo que declina rápidamente cuando nos acercamos a las bases de la organización. La opresión aquí es deliberada en algunos casos, pero suele ser el “resultado involuntario de una cierta disposición social”, que se manifiesta en la tan mentada frase “así son las cosas acá”.

Este tipo de opresión suele ocultarse tras las buenas formas corporativas, tapada por lo que se conoce como normas socialmente aceptadas. Su cara más pérfida se deja ver si quitamos la máscara que representan expresiones como “diversión”, “trabajo en equipo” o “espíritu comunitario”. Entre las víctimas esta opresión se deja ver en forma de un acatamiento sigiloso, un enorme miedo a cometer errores y una sensación generalizada de que es mejor no tomar una decisión que tomar una que sea juzgada como incorrecta. Es preferible posponer que actuar. El resultado de una cultura organizacional opresiva es la inercia, la parálisis total. El problema es que si a esta opresión no se la llama por su nombre no hay forma de poder entenderla y tratarla. Una organización sojuzgada por la opresión no podrá jamás ser verdaderamente ágil, por más ornamentos novedosos y supuestamente eficientes que utilicemos como fachada.

Por sobre la opresión existente al nivel de organización es posible vislumbrar una cultura del miedo entre compañías, una cultura de cumplimiento de “estándares” (p.ej. ISO 9001 o CMMi). He presenciado en dos ocasiones el enorme e innecesario esfuerzo que debían hacer aquellos que debían modificar su comportamiento habitual para poder cumplir con las nuevas reglas y en ambos casos tuve delante de mis ojos una imagen patética: trabajadores temerosos, aterrados por la sola idea de cometer una equivocación, aparentemente exhaustos, pero interiormente muertos de miedo. Tal vez otros han pasado por una experiencia distinta, pero no exagero, esa fue mi vivencia.

¿Pero quién es en definitiva responsable del statu quo? ¿Los opresores? ¿La sociedad? Sería fácil asignar responsabilidades y seguir con nuestra vida. La realidad, desde mi punto de vista, es que el oprimido es el verdadero culpable. En una sociedad democrática tenemos la posibilidad de elegir. Si estamos oprimidos (¡Y vaya que lo estamos!) es porque elegimos vivir así.

No podrá jamás existir ningún sistema generalizado de opresión…sin el consentimiento del oprimido.
Florynce Kennedy

La solución obvia parecería tener dos simples pasos: a) reconocer el problema b) actuar distinto. Lamentablemente la realidad es un poco más complicada. Con demasiada frecuencia los oprimidos no desean el cambio; simplemente quieren quedarse donde están. Esta es la desagradable realidad con la que debemos convivir. Todos hemos visto individuos que ascienden a un mando medio y cambian su conducta de forma consecuente, encajando perfectamente con el sistema y emulando a sus superiores. Todos hemos visto equipos que terminaron cayéndose a pedazos como consecuencia de luchas intestinas. De hecho una parte clave de cualquier buen curso para convertirse en scrum master debería enfocarse en lidiar con situaciones como esa. Los sistemas de premios y castigos en la mayoría de las corporaciones que desarrollan software están basados en la superioridad individual. Claro está, para que alguien sea superior otros deben convertirse en inferiores.

El filósofo y teórico de la educación brasilero Paulo Freire comenta de este modo sobre el síndrome de las peleas internas entre nativos oprimidos en países colonizados: “Dado que el opresor existe aún dentro de sus camaradas oprimidos, cuando los atacan están indirectamente atacando también a sus opresores”.

Freire continúa explicando que “por otro lado existe, en cierto momento de la experiencia existencial de los oprimidos, una atracción irresistible por el opresor, por sus patrones de vida. Participar de estos patrones constituye una aspiración incontenible. En su enajenación quieren, a toda costa, parecerse al opresor, imitarlo, seguirlo”.

Si los enormes y monolíticos entes como la IEEE y el PMI son los opresores del mundo del software, se desprende de las observaciones de Freire que los diminutos innovadores en proceso, los que alguna vez atacaron ferozmente el estilo de management representado por esos entes, querrán en breve emularlos para, en esencia, convertirse en ellos. Los eventos de la Scrum Alliance, por ejemplo, están pasando de ser encuentros íntimos entre personas apasionadas a convertirse en eventos con sponsors corporativos y famosos oradores, en esencia volviéndose idénticas a cualquier otra conferencia tradicional del mundo del software. El PMI, defensores del tan criticado proceso de desarrollo en cascada, se acaba de convertir en alguien que puede darnos consejo y apoyo (Ver el ensayo anterior “Cabalgando dinosaurios). Esto no es progreso, sino regresión, o en el mejor de los casos circularidad. El espíritu revolucionario tan aparente en los comienzos del movimiento se ha desintegrado casi por completo, mientras marchamos al ritmo del incesante e hipnótico tambor corporativo.

¿Dónde encaja scrum en un paisaje de obediencia, cumplimiento y emulación corporativa? Muy probablemente será absorbido por esa cultura, diluido y comoditizado. Será agradable a la vista y al uso, de eso no hay dudas. Y en un par de décadas una nueva generación de trabajadores entre descontentos y desamparados darán inicio a la revolución una vez más.

Todos deseamos el cambio, pero la evidencia indica que no sabemos cómo conseguirlo de modo que sea profundo y, sobre todo, duradero. Tal vez reconociendo lo auténtica y omnipresente que es la opresión en medio de la cual vivimos hoy en día, enfrentando el hecho de que existe, admitiendo su presencia, logremos sacarnos de encima las cadenas a las que nos sujetan nuestras actitudes más arraigadas, para comenzar, al fin, a pensar y comportarnos de nuevas y mejores maneras. Tal vez así podamos reinventar el mundo. O, por ahora, al menos el mundo del software.

16 de marzo de 2009

Anexo tendencioso: Elegía para un revolucionario seducido

Todo, absolutamente todo debe cuestionarse. Ese y no otro es el espíritu del movimiento. Preguntar, sistemática y concienzudamente por qué, para qué. El poder, la propiedad, las certezas, el modelo de negocio, esa manía de exprimir al cliente, la indiferencia hacia el usuario, el papel de los accionistas, el sistema de premios, quién decide sobre los sueldos, quién conoce los sueldos, cómo nos comunicamos, qué priorizamos, cómo priorizamos, dónde nos sentamos, si hay paredes, si se paga el café, si deben existir las oficinas, si tienen sentido los horarios, si vale la pena que compartamos un espacio físico todos los días, cuándo se trabaja, cuánto se trabaja, con quién se trabaja, quién hace qué, a qué y a quién le tememos, qué deberíamos aprender, de quién deberíamos aprender. En definitiva, entender el sentido de los lunes o perecer arrastrándonos a ciegas por el árido sendero de la inercia.

Agente de cambio, abejorro en la pared, scrum master, cualquiera sea tu nombre, pregunta hasta el cansancio, cuestiona o conviértete en parte del paisaje. Te veo preocupado en instalar herramientas y enviar convocatorias de reuniones. No gritaste a los cuatro vientos que el rey está desnudo. El sistema cruje contigo dentro. La llama se apaga. La próxima vez será.

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.