← Portfolio · ← Collaboration 2.0
3.1 · Status, outcome and reflection
The plan was half executed. What stopped it was the same thing the diagnosis had already named as the condition that let the circuit form.
What happened
After about a year of work — and a lot of time spent discussing the idea with talented employees, with leaders, and with the head of the unit — a reformation came down from the highest authorities.
A plan like this needs to be backed by the head of the whole division. The person backing it did not hold that ultimate authority. So we could not continue the project.
What is on the record
- The survey ran. It was answered in late 2025, after a twenty-minute explanatory video and before any part of the framework was in use. The reading is in 4.3 · 4. It is a baseline with nothing to hold it against, because the second round never happened.
- The framework was communicated. An introduction letter to leads and management, training videos, and the explanatory video the survey respondents watched. The rollout reached people; 4.3 says how far the idea itself travelled, which is not far.
- The artifacts exist. Templates, the strategy, the responsibility model, the printed token sheets. The inventory is 3.2.
How far it actually got.
- The authoring process was never run end to end. PRDs for a couple of products were pushed to Confluence. But the team leads were not committed, so their members never fully committed to commenting and reviewing on the platform — which was a large part of the core of Collaboration 2.0.
- The responsibility model was never formally adopted. It was discussed in several meetings and then not followed. The team leads found a way around it.
- One thing changed and stayed changed. Confluence itself became interesting to a number of people, regardless of the philosophy behind Collaboration 2.0. Mainly for two things: cutting meeting time, and selective publishing, which served top-down pushes from leads and higher authorities.
Why this is a finding rather than an excuse
There is a version of this claim that is too convenient. Any failed proposal can be re-described as proof that the thing it was fighting is strong.
What keeps this one honest is that the mechanism was written down first. Phase 1 in 4.2 names it as a dependency: nothing else could proceed without trust, freedom, support and coordination from group leadership.
The strategy identified its own single point of failure. Then it failed there. That is a prediction that came true, not a story told afterwards.
The lesson
Yes — this was caused by one of the two roots the analysis had already identified (1.2).
And to be honest, the roots are the thing itself. You can help it adapt. You cannot uproot it.
If you can reform, do it. Otherwise, give up.
What that costs the design
Read strictly, that lesson is harder on this project than a planning error would be.
A planning error would say: I named a dependency and did not secure it. Sponsorship work is fixable. You do more of it next time.
What actually happened says something else. The reform needed permission from the very condition it was built to constrain. A pattern that survives by suppressing what competes with it does not hand out that permission. On that reading the design error was not too little sponsorship work. It was needing sponsorship at all.
That is why 1.2.2 matters more than it looks. The enabling conditions cannot be removed. An intervention that has to ask them for permission is not working around them. It is standing inside them.
The hardest part — communicating it
The hardest thing about this project, for me, has always been communicating it — whether verbally to a top manager, or now, in writing these documents. It is an entangled knot of many related topics: product management, PRD design, sociocultural systems, structural functionalism, and almost eight years of pattern-recognition across recurring organizational issues. Putting all of that together into something coherent was, for me, a genuine puzzle.
I want to be honest about something uncomfortable here. I hate the move where someone tries to elevate their own idea by tearing down others. It is a cheap trick, close to populism, and I do not want to look like I am doing it.
But the honest truth underneath it is this. I believe most managers and teams carry around minds full of colorful diagrams and workflows, each claiming to be the method that will finally fix the organization’s problems. And the question I keep asking myself is how to explain Collaboration 2.0 so that it does not read as one more entry in that pile — another diagram, another repeated idea with a new name. I know I will still need visuals, workflows, the usual apparatus. But the idea itself was never manufactured that way. It came out of what I learned and intuited over years of watching an organization that had every intellectual asset it needed, and still failed to reach its goals.
And I genuinely do not know, right now, whether I have explained that distinction as clearly as it deserves. I believe Collaboration 2.0 can be communicated better than I have managed so far. What I cannot tell is how much of that distinction an audience can pick up — or what level of familiarity with these ideas someone needs before the argument lands and they feel the excitement I feel about it. That is not a doubt I have resolved. It is where I honestly stand.
Would I do it again?
At first glance I am tempted to say no. It cost me close to a year — time I could have spent deepening the technical skills in my own area of expertise. I have had other efforts before that ended in failure, which makes me cautious about repeating the pattern.
But when I weigh what the process gave me, the answer changes.
I had been drawn to complex systems and sociology, and to the space where they intersect — sometimes called sociocultural systems — for a while before this. The project gave me a live environment to test those ideas against, rather than only holding them theoretically.
Beyond that it taught me something more personal, and harder to name precisely. How to read my surroundings and judge whether to try to change them at all. Where and how to start a change. How to communicate an idea so that it lands. And how to tell the difference between a situation I should walk away from and one where speaking up serves the good of the whole group.
So the honest shape of it is that I would go through the same process again, cost included, because of what I learned along the way.
Where a redesign would start
If needing sponsorship is the error, the redesign question is concrete: what does a version of Collaboration 2.0 look like that never has to ask?
Start below the sponsor’s line of sight. Make the first adopters the people with the least to lose. Choose an artifact whose adoption costs no budget.
2.7 is the other half of that answer — what the framework was meant to grow into, which is a system that needs nobody to govern it at all.
⟵ Up: Collaboration 2.0 · Previous: 2.7 · What would have come next · Next: 3.2 · Artifacts →