I wrote last September about adopting the unFix model and how I set up the structure. Eight months in, it feels like the right moment to be honest about what has worked, what has not, and where the genuine tensions are.
What is working Link to heading
Ownership is clearer. The Crew model does what it is supposed to do. In a function-organised structure, “who is accountable for this?” is a question that regularly requires escalation. Under the Crew model it mostly has a structural answer. Crews know what they own, and that changes how conversations happen.
The Capability Crew embedding model works, for the right specialisms. Specialist skills on demand, without the queue. Front-end development is the clearest example: not every Crew has complex front-end requirements at all times, so front-end specialists embed when a Crew needs them and move on when the work is done. The specialists are effectively shared across the organisation, and the Crew retains ownership throughout. This has worked better in practice than I expected when we designed it.
The honest tensions Link to heading
Coordination without a middle layer. The model works well when a Crew’s scope is self-contained. It is harder when multiple Crews depend on each other toward a shared goal, as when building an entirely new platform. The absence of a co-ordinating management layer means that co-ordination either happens informally through regular touchpoints, or it does not happen. In practice, the inter-Crew communication the model relies on does not happen reliably unless something prompts it. We have found a workable pattern for the most critical dependencies, but it required deliberate effort to establish and it is not automatic.
Autonomy within agreed constraints. Crew autonomy in ways of working is genuine. Technical standards are set at the organisation level and are not negotiable. The principle is “autonomy within agreed constraints,” and keeping the boundary between “Crew decision” and “organisation decision” clear is an ongoing task. When in doubt, Crews can escalate to the Governance Crew, but I want that to be the exception.
QA and the facilitation model. A QA Facilitation Crew made sense at the point we adopted unFix: the primary work was building out a new automation framework, and facilitation was the right model for that phase. As automation matures and becomes routine work, the facilitation need diminishes. The unFix model has an alternative that might fit better at this stage: a Technical Forum, which brings QA practitioners across all Value Stream Crews together without the overhead of a formal Crew structure. We have not made that transition yet, but I want to explore how it could improve things.
Design & UX: capability or service? The expectation was the same model as front-end: designers embedding in Crews for the duration of the design work, then moving on. In practice it has functioned more as a service. Work comes in, designers pick it up, but they are not embedded alongside the Crew. Whether that reflects the structure or the nature of the work itself is not fully resolved. The unFix model does not have a crew type that maps cleanly to this way of working. A Platform Crew, a shared service that other Crews consume, is probably the closest fit, and would be worth trialling to see whether the structure follows the reality.
What I would do differently Link to heading
Document the ways-of-working expectations earlier. The structural documentation was done well: Crew types defined, Crew briefs written. What took longer was the practical guidance on how Crews interact: how dependencies are negotiated, what escalation to Governance means in practice, what Captains are and are not responsible for. Some of that had to be worked out through experience rather than being established upfront. Starting that work in parallel with the structural work would have shortened the settling-in period.
Invest in Captain development from day one. Appointing someone as a Captain does not automatically transfer accountability. Captains need to understand what the role means in practice: how to manage the relationship with Governance, how to navigate the boundary between Crew decisions and organisation decisions, and how to lead without authority in the traditional sense. One approach I want to explore is a Captain forum: a regular touchpoint that brings Captains together to share experience and learn from each other. This would also directly address the coordination problem above. Captains talking regularly is one of the mechanisms by which cross-Crew dependencies get surfaced and resolved before they escalate. Establishing that from day one would give new Captains a support structure and build the coordination habit the model depends on.
Think carefully about teaming options at the start. The unFix model distinguishes between Steady Teams, permanent Crews with ongoing ownership, and Mission Teams, which are short-lived and dissolve once their goal is achieved. We set everything up as Steady Teams. For established product lines, that is clearly right. For the new platform build, I am less certain. Early foundational work might move faster with short-lived Mission Teams focused on discrete deliverables, before handing off to the Steady Teams that now own the platform ongoing. It is something I would think through earlier next time.
Eight months in Link to heading
The model is doing what I adopted it to do. The structure is holding. Teams have genuine autonomy within a coherent structure. The Capability Crew embedding approach has proved its worth. The tensions are real, but they are the right tensions: the kind that come from a structure genuinely operating with autonomy rather than defaulting to hierarchy.
We are still learning.