← Back to list

Working at Scale (Teams of Teams)

by Arfan Rashid & Martin Duffy

Arfan Rashid · 2026-03-02 10:44 · 0 claps · 1.8 min read
#software-development #scaled-agile #delivery-management #agile-project-management #programme-management
Open on Medium ↗
Wiki topics: BIZ · Business Strategy 📋 · Product Management

Working at Scale (Teams of Teams)

by Arfan Rashid & Martin Duffy

What Changes When Everything Gets Bigger

Building a digital product is one thing, building it at (national) scale is entirely different!

When users number into the millions, teams are cross discipline & locations, (legacy) systems need to continue to support new enhancements in Live environments & evolve without breaking, the challenges stop being technical and forces you to rethink how you build, how you collaborate, and how you make decisions!

Scale Is a Mindset

The first thing that scales is complexity and complexity grows non‑linearly;

  • more users requires greater validation of ideas & intended product experiences,
  • more teams usually means a greater number of dependencies, and
  • more product enhancements usually means bigger & sometimes harder tradeoffs

Working at scale means moving to what keeps working over time, not just what works now.

Architecture; Design for Change

Systems need to be flexible.;

  • Looser coupling & modular structures
  • Clearer contracts & ownership between teams
  • Optimisation where it makes sense, not just for the sake of it

The goal isn’t to gold plate but to be resilient. This reduces blast radius, accelerates delivery, and protects the experience in Live.

Teams; Conway’s Law is Real

Larger (digital) products are usually shaped by the teams that build them and its easy to fall into the trap of the organisation structure which then dictates & becomes the system structure. When teams mirror legacy organisational boundaries, the system inherits those bottlenecks.

To avoid this:

  • Organise teams around outcomes & not services/components
  • Minimise handovers and remove dependencies
  • Empower teams to ship independently of each other
  • Swarm on shared goals & priorities

Delivery; Speed comes from Consistency

Consistency (not uniformity) helps reduce cognitive load. When everyone understands how work gets done, teams can focus on what matters.

  • Make sure everything is highly visible (priorities, ideas, experiments, work, stats etc)
  • Everyone understands the what, why & the how
  • Theres a clear way of working thats highly transparent and includes all of the steps in your product flow

Governance;

Effective governance at scale is:

  • Lightweight
  • Transparent
  • Embedded in day-to-day workflows
  • Shared tooling for visibility
  • Predictable, lightweight decision forums

Remove the layers of process or extra asks. Good governance is when teams barely notice it; because they make good ways of working the default.

Measure what Matters;

Don’t just focus on the final metric, mature teams also track & understand:

Balancing these three prevents local optimisation (e.g., speed at the cost of quality or burnout).

Culture Is the Real Driver;

Teams thrive when they have the following traits:

  • Psychological safety
  • Continuous learning
  • Clear ownership and accountability

Culture at scale doesn’t happen by accident — it needs real rituals, behaviours, and leadership reinforcement.

Conclusion

Remember digital development is ultimately a team sport!

Its about collaborating together to build systems & relationships (as humans) that evolve together.


메타데이터
post_id
5cb634ac8dfd
slug
working-at-scale-teams-of-teams-5cb634ac8dfd
url
https://medium.com/@arfanrashid73/working-at-scale-teams-of-teams-5cb634ac8dfd
canonical_url
https://medium.com/@arfanrashid73/working-at-scale-teams-of-teams-5cb634ac8dfd
author_url
https://medium.com/@arfanrashid73
status
ok
fetched_at
2026-08-02 20:14:45