From Holacracy to Team Topologies: Designing Tech Teams for Real Autonomy

You know that feeling when leadership announces "we're giving teams more autonomy" and your first thought is "oh no, this could get messy"? I've been through enough org restructures to know that autonomy without boundaries often creates more problems than it solves.

A few years back, we transitioned from matrix project teams to product mode with stream-aligned teams. The velocity gains were real, but so were the unintended consequences - more defects, duplicated effort, and teams stepping on each other's toes. What I learned (sometimes the hard way) is that effective autonomy isn't about removing constraints; it's about designing the right ones.

This post shares what I've observed works when borrowing selectively from Holacracy, the Spotify model, and Team Topologies. Your context will be different, but maybe these patterns and guardrails can save you some of the trial-and-error we went through.

What I've Learned Autonomy Actually Means#

After watching several well-intentioned autonomy initiatives, I've noticed successful ones tend to get these fundamentals right:

• Decision rights: What can the team decide independently vs. where should they seek input or approval? (This clarity prevents the awkward "I thought you were handling that" conversations)
• 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. Less talking, more building
• Outcomes over tasks: Teams commit to outcomes and SLOs, not ticket velocity. What gets delivered matters more than how busy everyone looks

Without these boundaries, what organizations call "autonomy" often becomes teams optimizing locally while the overall system suffers. I've seen it happen more times than I'd like to admit.

The Models We Borrowed From (and How)#

Holacracy (the parts that made sense)#

• What worked for us: Role charters (purpose, accountabilities, domains) and short "tactical" meetings to surface tensions quickly. The clarity was refreshing
• What we skipped: The full governance ceremonies and constitution. It felt too heavy for teams trying to ship features regularly
• Watch-outs: Roles can multiply like rabbits, and before you know it, nobody knows who does what. We learned to maintain a living role catalog and ruthlessly sunset unused roles monthly

Spotify Model (mostly the vocabulary)#

• What resonated: Squads (cross-functional teams) and guilds (communities of practice). Chapters worked only when we had genuine shared craft standards that needed coordination
• What we avoided: Copying their org chart wholesale. Even Spotify emphasizes their "model" was a point-in-time snapshot, not a universal blueprint
• Watch-outs: Chapter leads can accidentally become shadow managers if you're not careful. We kept performance management clearly with the squad lead to avoid confusion

Team Topologies (this became our foundation)#

• What clicked: The four team types and three interaction modes gave us a shared vocabulary:
  • Stream-aligned, Platform, Enabling, Complicated-Subsystem
  • Collaboration, X-as-a-Service, and Facilitating
• Why it resonated: It acknowledges Conway's Law instead of fighting it, and makes dependencies visible rather than hoping they'll resolve themselves. The "inverse Conway maneuver" - reshaping architecture to match desired team boundaries - was particularly powerful
• Watch-outs: Platform teams need to act like product teams with SLAs and a well-maintained "paved road," not ticket-taking services or gatekeepers. This shift in mindset took some adjustment

The Guardrails That Actually Worked#

Autonomy without boundaries tends to create beautiful chaos. Here's what we found helps:

• Ownership map: Every domain, service, and capability has exactly one owning team. Joint custody rarely works well in practice
• 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. Future-you will thank past-you for writing these down
• 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. Reduces "I thought you were handling that" moments
• Metrics that matter: DORA metrics (lead time, deployment frequency, MTTR, change fail rate), team health surveys, and internal NPS for platform services. What gets measured tends to get attention

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.

Anti-Patterns I've Watched Teams Fall Into#

I've seen these patterns derail otherwise well-intentioned autonomy efforts:

• Autonomy theater: Teams "own" their backlog but can't actually deploy, hire, or influence their roadmap. It feels like ownership without the meaningful parts
• Platform police: Hard approval gates instead of well-maintained paved roads. Creative engineers will find ways around gates, usually making things more fragile in the process
• Shadow management: Chapters or guilds accidentally reintroduce hierarchy and slow down decisions they were meant to enable
• Matrix creep: Dual reporting structures create unclear decision rights. Single-threaded leaders per value stream tend to work better, even if it feels less "fair"
• Tooling over outcomes: Introducing new ceremonies and tools without actually changing decision rights or boundaries. The overhead increases but the problems remain

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 That Helps (but doesn't replace design)#

• 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.

When Autonomy Might Not Be The Answer#

Sometimes more structure, not less, is what teams need:

• Early product/market fit uncertainty: Tighter alignment and fewer teams often work better when you're still figuring out what to build
• Safety or regulatory-critical domains: More consent processes and audit trails are necessary, even if they slow things down
• Very small organizations (<15 engineers): Don't manufacture complexity. Strong defaults and clear ownership often suffice without formal team topologies

What I'd Do Differently Next Time#

Looking back on this journey, a few things stand out:

• Start with value streams and boundaries, not ceremonies: The structure matters more than the process
• Use Team Topologies as your foundation: Borrow selectively from Holacracy and Spotify, but don't try to implement everything
• Invest in platform-as-product early: Enabling teams and well-maintained platform services pay dividends, but they take time to mature
• Write things down: Charters, SLOs, ADRs, and interaction modes. Tribal knowledge doesn't scale
• Measure outcomes first: Adjust organizational structure based on what the metrics tell you, not what feels right

Your mileage will vary depending on your organization's culture, size, and technical maturity. What matters most is being intentional about the trade-offs and honest about what's working.