Skip to content
~/sph.sh

Holacracy vs Team Topologies: Team Autonomy Models Compared

Practical structures and guardrails that raise team autonomy without chaos, drawing on Holacracy, the Spotify model, and Team Topologies.

Ayhan Sipahi Ayhan Sipahi

Leadership announcements about “giving teams more autonomy” tend to land with mixed reactions: autonomy without boundaries often creates more problems than it solves.

The common pattern is familiar. Moving from matrix project teams to product mode with stream-aligned teams produces velocity gains, along with unintended consequences: more defects, duplicated effort, teams stepping on each other’s toes.

Team Topologies is the workable default here. Use its team types and interaction modes as the frame, then borrow role charters from Holacracy and community-of-practice vocabulary from the Spotify model. Context varies, but that combination lowers the trial-and-error cost of reorganizing.

Autonomy Defined#

Successful autonomy initiatives tend to get these fundamentals right:

  • Decision rights: What can the team decide independently, and where should they seek input or approval?
  • Clear domain ownership: One team owns a problem space end-to-end: roadmap, code, infrastructure, on-call, and cost. Joint ownership often means no ownership
  • Thin, trusted interfaces: Teams interact through versioned APIs, events, and contracts rather than coordination meetings.
  • Outcomes over tasks: Teams commit to outcomes and SLOs.

The Models and How to Use Them#

Holacracy (selective parts)#

  • What works: Role charters (purpose, accountabilities, domains) and short “tactical” meetings to surface tensions quickly. The clarity is valuable.
  • What to skip: The full governance ceremonies and constitution. Too heavy for teams trying to ship features regularly.
  • Watch-outs: Roles can multiply quickly. Maintain a living role catalog and sunset unused roles monthly.

Spotify Model (mostly the vocabulary)#

Squads (cross-functional teams) and guilds (communities of practice) resonate widely; chapters only earn their keep when a genuine shared craft standard needs coordinating. Copying the org chart wholesale misreads the source: Spotify has described the “model” as a snapshot of their own org at one point in time.

Watch-out: Chapter leads can slide into shadow management. Keep performance management with the squad lead.

Team Topologies (the foundation)#

The four team types and three interaction modes provide a shared vocabulary: Stream-aligned, Platform, Enabling, and Complicated-Subsystem teams; Collaboration, X-as-a-Service, and Facilitating interactions. It works because it acknowledges Conway’s Law instead of fighting it and makes dependencies visible; the “inverse Conway maneuver” (reshaping architecture to match desired team boundaries) is particularly powerful.

Platform teams need to act like product teams, with SLAs and a well-maintained “paved road,” since ticket queues and approval gates undo most of the benefit.

Effective Guardrails#

  • Ownership map: Every domain, service, and capability has exactly one owning team.
  • SLOs and error budgets: Teams own their service reliability; leadership’s job is protecting those error budgets from being consumed by premature optimization
  • Change taxonomy: Reversible changes need advice from affected teams; irreversible ones require explicit consent. Jeff Bezos’s “one-way vs two-way door” concept applied to org design
  • Decision records (ADRs): Lightweight, searchable decisions linked from PRs
  • Paved road: Opinionated defaults for CI, deployment, observability, and auth. Platform teams publish maturity levels and deprecation schedules so teams know what they’re getting
  • Interaction contracts: Each cross-team dependency explicitly states the intended interaction mode and expectations
  • Metrics that matter: DORA metrics (lead time, deployment frequency, MTTR, change fail rate), team health surveys, and internal NPS for platform services

Migration Playbook (12-24 Weeks)#

  1. Map value streams and declare 3-5 candidate stream-aligned teams. Name the outcomes they own.
  2. Draw your current dependency graph. Highlight hot spots (waiting, rework, unclear ownership).
  3. Define interaction modes for each dependency. Kill “coordination by meeting”.
  4. Stand up an enabling team for 8-12 weeks to coach squads on testing, observability, and trunk-based development.
  5. Platform as product: Publish a paved-road RFC with golden paths for CI/CD, logging, auth, and experimentation.
  6. Service boundaries: Align repos and runtime ownership to teams. Co-locate code with on-call and budget.
  7. Cadence: Weekly tactical (per squad), bi-weekly guild syncs, monthly architecture forum, quarterly business review.
  8. Measure: Baseline DORA + incidents + time-to-merge. Re-measure at 6, 12, and 24 weeks.

Where Autonomy Breaks Down#

These patterns derail otherwise well-intentioned autonomy efforts:

  • Autonomy theater: Teams “own” their backlog but can’t actually deploy, hire, or influence their roadmap.
  • Platform police: Hard approval gates instead of a well-maintained paved road; engineers usually find a way around them anyway.
  • Shadow management: Chapters or guilds reintroduce hierarchy and slow down the decisions they were meant to speed up.
  • Matrix creep: Dual reporting structures create unclear decision rights; a single-threaded leader per value stream tends to work better.
  • Tooling over outcomes: New ceremonies and tools appear without any real change to decision rights or boundaries.

Working Templates#

Team Charter (copy/paste)#

  • Purpose: Why does this team exist? Who is the customer?
  • Outcomes (12 months): 3-5 measurable outcomes with leading indicators.
  • Scope & boundaries: What’s in/out? Which services and domains?
  • Decision rights: What can we decide alone? What needs advice/consent?
  • Interfaces: APIs/events we own; SLAs/SLOs.
  • Operating model: Cadence, on-call, incident response, release process.
  • Metrics: DORA, SLOs, customer sat, cost guardrails (e.g., $/1000 requests).

Interaction Mode Checklist#

  • Collaboration: Time-boxed? Clear exit criteria? Named single-threaded owner?
  • X-as-a-Service: SLOs published? Runbook? Backlog intake and status visible?
  • Facilitating: Coaching goals defined? Skills transfer plan? Sunset date?

Lightweight Decision Flow#

  • Small, reversible: Team decides; post ADR.
  • Cross-team, reversible: Seek advice from impacted owners; proceed unless reasoned objection.
  • Irreversible or high blast radius: Consent needed from owning leaders; document risk and rollback.

Tooling Considerations#

  • ADR repo with templates and search.
  • Scorecards for paved-road adoption per team.
  • Golden path starters for services, with built-in observability and auth.
  • Org dependency map in the wiki; reviewed quarterly.

Autonomy Limitations#

Some situations call for more structure. While product/market fit is still uncertain, tighter alignment and fewer teams usually beat distributed ownership; the target keeps moving, and every extra boundary is another thing to renegotiate. Safety-critical and regulated domains need consent processes and audit trails even at the cost of speed. In very small organizations (under 15 engineers), strong defaults and clear ownership are usually enough on their own, and formal team topologies mostly add ceremony.

Where to Start#

Map value streams and ownership first, publish the paved road second, and reshape the structure only once DORA and incident data say something.

References#

Related posts

AI Made Code Cheap and Review Expensive

AI-assisted coding made generation cheap and verification heavy. Why CTOs should pace adoption to review capacity, and what to measure beyond velocity.

leadership · engineering-management · ai-adoption-strategy +3

Engineering Team Documentation: Working Agreements, Definition of Done, and On-Call Docs

The team documents a mature engineering team owns: onboarding, working agreements, Definition of Done, on-call, knowledge transfer, and what makes each one good.

engineering-culture · hiring · documentation +4

Scrum vs Kanban vs Scrumban for AI-Assisted Teams

AI absorbs more of the implementation, so the framework name matters less than four feedback loops. A decision lens for tuning flow, cadence, WIP, and review.

leadership · agile · team-management +3

Communication Is the Gate to Your Next Engineering Level

Technically solid but stuck at one level? What engineering communication means as concrete artefacts, why ladders gate the next step on it, and where to start.

career · leadership · documentation +4

Slow Down to Speed Up

Rushing feels fast but creates rework, bugs, and firefighting. Why pausing for refactoring, tests, and CI upkeep is an investment in speed, not lost speed.

technical-debt · testing · ci-cd +2