How you organise teams and ask them to work is not an incidental management choice — it is a product you design, ship and iterate. Yet most organisations treat ways of working as folklore: handed down at leadership offsites, copied from a podcast, then left to drift. That is why teams fight over priorities, quality slips, and improvement feels like hope rather than a plan.
Why ways of working must be treated like a product
Products are built deliberately: they have a purpose, metrics, a roadmap and a feedback loop. Ways of working deserve the same treatment. When you design a team topology, interaction patterns or operating norms you are making trade-offs that change how quickly you learn, how effectively teams deliver outcomes and how resilient your organisation becomes.
Designing ways of working means being explicit about the problem you are trying to solve (speed, safety, innovation), defining hypotheses, measuring outcomes and iterating. Treating them as products forces accountability: owners, experiments, telemetry and a commitment to continuous improvement.
Five product principles every organisation should apply to how teams work
We apply these principles to software products all the time. Apply them to ways of working and you get clarity — and speed.
- Tackle one bottleneck at a time. Resist the urge to ‘fix everything’. Identify the constraint that most limits flow and focus your change efforts there.
- Limit Work In Progress (WIP). Teams that start fewer things finish more. Limiting WIP reduces context switching and accelerates feedback.
- Balance features with quality and debt. A portfolio that ignores technical debt or quality will slowly collapse under its own weight. Explicitly allocate capacity for both.
- Automate feedback to ship faster. Short, automated feedback loops — from CI/CD to production monitoring — turn assumptions into facts quickly and safely.
- Invest 20–30% of capacity in improvement. Deliberate investment in tooling, standards and capability-building compounds faster than one-off change projects.
How to measure whether your ways of working are working
Measurement is the sharp edge of product thinking. Choose a small set of outcome metrics and leading indicators that map to the behaviour you want to see. Useful signals include:
- Flow metrics: lead time, cycle time, and WIP levels.
- Quality metrics: escaped defects, mean time to restore (MTTR).
- Improvement metrics: percentage of capacity spent on technical debt, automation or internal platform work.
- Learning metrics: frequency of experiments, hypothesis validation rate.
These are not fancy KPIs; they are the same telemetry that high-performing engineering organisations rely on. Google Cloud’s DORA/State of DevOps work demonstrates how engineering practices map directly to business outcomes — and that measurement matters.
Real-world example: squads, the Spotify model, and where organisations go wrong
The Spotify model (squads, tribes, chapters) became a global favourite because it emphasised autonomy and alignment. But many organisations copy the structure and miss the product thinking behind it. They end up with autonomous teams doing the wrong things, duplicated effort and fragile handovers.
The lesson isn’t to adopt a template — it is to adopt the intent: deliberately design team boundaries to minimise cognitive load, create clear APIs between teams, and measure whether those boundaries improve flow. For that, Team Topologies offers practical guidance on team types and interaction modes that align structure with organisational constraints.
Four practical steps to get started this week
- Assign an owner. Choose a senior leader to own your organisation’s ‘ways of working product’ and make them accountable for outcomes.
- Run a short experiment. Pick one bottleneck, design a hypothesis, set success criteria and run a time-boxed experiment.
- Measure and publish. Expose a small dashboard of flow and quality metrics so everyone can see progress and trade-offs.
- Protect improvement capacity. Mandate 20–30% capacity for improvement work; evaluate it like any other backlog item.
How this looks in practice
Imagine a product group with chronic slow releases. Diagnosis shows high WIP across squads and manual regression tests. The experiment: cap WIP per squad, introduce a lightweight branch strategy, and automate critical end-to-end tests. Measure cycle time, deployment frequency and escaped defects. If the hypothesis holds, roll the changes across the area; if not, iterate. This is product thinking applied to how teams work.
Towards a more directive approach
Many leaders are reluctant to be directive about ways of working. They fear stifling autonomy. But direction and autonomy are complementary when the direction is clear and informed by data. Set the operating constraints, provide the tooling and guardrails, then let teams choose within those boundaries.
Organisational design is not neutral. Every topology biases behaviour. If you want speed, reliability and sustainable innovation you must decide what behaviours you incentivise — and build the systems that make those behaviours easy to demonstrate. Treating ways of working as a product is not bureaucratic; it is pragmatic. Start small, measure, and invest deliberately. I’ll be starting this week — will you?
Reference
This article was inspired by a discussion on mental models in software development: “Software Development Sucks — Mental Models” (InfoQ podcast).
Leave a Reply