← Portfolio · ← Collaboration 2.0
2.2 · The approach — Collaboration 2.0
Collaboration 2.0 — a transparent, shared and online collaboration framework for reaching resolutions.
Here I prefer to stick with my storytelling tone, because I believe stories communicate the sense of an experience, and the lessons learnt in the moment, better than structured academic notes do. At least in many cases that is true.
Here is the big difference from the failures where a manager adopts a workflow or a management process because it is cool, because it is trendy, or because some other big company is using it. I believe that when you have really felt the challenge a managerial process addresses, and you have already been thinking about a solution that covers at least half of it, you actually learn the process when it is introduced to you. Scrum is a good example, and one of the lower-risk ones.
I am somehow claiming that I was inventing both of these independently, which may make me look arrogant. But when I found them, I immediately noticed aspects and features I had never thought about, and a better polished, better structured form of my own ideas. Which shows I am more humble than you might think.
Sub-sections: 2.2.1 The blueprint · 2.2.2 What the framework produces
2.2.1 · The blueprint
Looking carefully at the graph, I realized there are three conditions — three variables — that let one node reach another along an edge: transparency, communication, and market and target strategy. You can also think of these as qualitative features of the company’s operating system, or as the system’s hidden states.
Transparency. Without it, the main playing field for anyone seeking power and control over decisions and people is strategic positioning, rather than proving their seniority on the subject and adding real value to the projects. And technical teams cannot build a shared understanding with each other, or with other divisions. They are never on the same page.
Communication. The company’s projects were never built on innovation, iterative business logic or effectuation. So it deliberately avoided loose rules for communication, to keep order while it built the same product it had become a hero for building. But the hierarchy that became the norm and the code of the organization is now the main tool people use to kill transparency. That bureaucracy is also far slower than a sustainable development environment needs. If you are a programmer you know that our community has always been building repositories, hubs and CI/CD tooling to speed up and automate the workflow. So this barrier cannot be described as a factor that makes development slower. It stops development.
Market and target strategy. The company is new to this kind of business and this kind of project. On top of that, the lack of communication and transparency stops anyone from thinking we need a consensus — a shared understanding of the products, of the quality and the metrics we want, and of what comes first. And because responsibility was loose and no decision had a clear owner, the product and the decisions made about it were never declared clearly anywhere.
So I concluded that the solution had to target the building blocks of the communication blockade and the transparency blockade.
What the design was not allowed to do
There was one big obstacle. I could not propose anything that clearly and immediately violated the conventions and norms of the organization. An anarchistic solution would fail, because influential individuals would feel their interests were about to be threatened, and would challenge the adoption of the framework before it had a chance to work. On the other hand, the design philosophy of this framework is not to deliver the goods and the promises as soon as it is built. It is to evolve the patterns and the constructive culture inside the society that has to use it.
So we communicated the change this way: we are not going to violate the previous principles. We are just moving things online, which will make many of the communications you already have to do cleaner and easier for you. We were honest with them in saying it that way.
The blueprint itself
Putting it all together, the solution had to be a framework that is:
- online — anyone, at any time, can quickly check it, comment on it, or add to it;
- transparent — unless a specific item is explained to contain private information, such as technology details that are the company’s own asset, everything else sits in a public place that every stakeholder and subject-matter expert can reach;
- shared with everyone — everyone can reach every material, unless it is explicitly explained that the material is private and that a particular person or team has no need to know it.
To be honest, this would worry individuals who know they lack knowledge, while it raises hope in people who know they have the qualities to guide decisions and build useful things, and who were trapped by the bureaucracy. In that sense you might think of Collaboration 2.0 as a step toward democratizing contribution and decisions.
2.2.2 · What the framework produces
These next three are not the design principles. The principles are the blueprint above. What follows is what the blueprint produces once it is running — and the reason these particular properties are the ones that appear is the causal graph in 1.1.5. The prospect being offered is that if these three hold, the symptoms in section 1 are reconciled one at a time.
Always and immediate. Anyone can look at a live document, judge it, or add to it, at any moment. Not at a scheduled review. Not through a chain of people. The failure this reaches is the one where the only place to raise a technical objection is a meeting you are not invited to. In the survey, two in ten said there was no mechanism for putting an idea forward at all (4.3).
Everyone. In both directions. Everyone can say something, and everyone can hear what is said. Speaking without hearing is a suggestion box. Hearing without speaking is a newsletter. The framework needs both, from everyone, whatever their rank or years served — and it names junior staff explicitly, where what they know is relevant.
Trackable. Three things leave a trace that lasts:
- who looked, and who contributed,
- what state the work is in, and what came of it,
- who is responsible, and who gets the credit.
The third one does the real work. If you can trace a contribution, you can trace the credit for it. And if credit can be traced, the reason to contribute survives the political weather described by the culture-and-norms cluster (1.1.5).
That is how a change to a workflow is meant to move something cultural.
One more thing it produces. When such a platform exists, even newcomers can see the discussion and the process behind a decision. That gives them an intuition for the bigger picture of what they are doing. It also means that if they have a technical point, they can add it to the argument — where in the traditional process their chance of being invited to the meeting was not high. The rail that lets people demonstrate their qualities is what unlocks the blocked motivation of the most capable individuals. I like to call those people the wasted intellectual assets.
Where it can be gamed, and where it bites back. Any system that records what you do gives you a reason to do the recordable thing: comment a lot to look busy, write documents to cover yourself, attach your name to other people’s work. Part of my answer is that the record cuts both ways. Poor writing and shallow comments reveal what a person does not know, in front of everyone.
The real drawback is different, and it is a cost rather than a defence. Not everyone is used to writing down their thoughts, their knowledge and their arguments. Some people are not comfortable reading at length either. A framework that runs on written contribution asks something of people that the previous way of working never asked.
⟵ Up: Collaboration 2.0 · Previous: 2.1 · A new lens — the organization as a complex system · Next: 2.3 · What gets discussed — the PRD →