Team Topology Designer: team topologies designer tool

Team Topology Designer guide: team topologies designer tool for 10 to 100 engineers

In a 60 engineer org, one extra dependency can cost you weeks. You see it in blocked PRs, Slack pings, and the classic “waiting on platform.” Team Topologies has been around since 2019, and the second edition landed in September 2025 with a tighter focus on value flow and cognitive load at scale. The point for CTOs is pretty simple. Team structure is a delivery system, not an org chart.

This guide walks through how to use the Team Topology Designer as a team topologies designer tool. It helps you model stream aligned, platform, enabling, and complicated subsystem teams. More importantly, it forces the conversations most orgs avoid: interaction modes, boundaries, and Conway’s Law.

What the Team Topology Designer is, and what it models

The Team Topology Designer is a visual tool for designing team structures using the Team Topologies framework. It models four team types and the interaction modes between them. It also makes the “team of teams” view visible, which starts to matter once you’re past 10 teams and nobody can keep the dependency graph in their head.

The tool centers on a few building blocks:

Stream aligned teams: own a flow of work that maps to customer value.
Platform teams: build internal services that reduce stream team cognitive load.
Enabling teams: coach and unblock stream teams as they adopt new skills.
Complicated subsystem teams: own deep specialist components that would overload stream teams.
Interaction modes: collaboration, X as a Service, and facilitating.

CTOs use this model to scale product and platform orgs without choking value flow. It’s also a solid way to approach cloud adoption and platform as a product work without drowning in coordination costs, as described by the Team Topologies authors and community at teamtopologies.com.

A useful working definition for this guide:

A team topology is the smallest set of team types and interaction modes that keeps value moving, while keeping cognitive load inside team limits.

That framing matters because most orgs stop at “four boxes on a slide.” The tool pushes you into the operating model: who owns what, how teams engage, and where the friction will show up.

How to apply Team Topologies in practice with a stream aligned team planner

Most Series A and B orgs I talk to hit the same wall. They hire fast, then they spin up a platform team too early, then decision making centralizes, and delivery slows to a crawl. A stream aligned team planner keeps you honest by starting from value streams, not functions.

Step 1: Map value streams before you draw teams

A value stream is the flow from idea to customer value. In a B2B SaaS company, streams often look like:

Onboarding to first value: signup, provisioning, first integration.
Core workflow: the daily job the user pays for.
Billing and entitlements: plans, invoices, usage, renewals.
Trust and compliance: audit logs, data retention, access controls.

A stream doesn’t need to match a microservice. It needs to match a business outcome and a backlog that can stand on its own.

AgileLab’s handbook makes a point that’s easy to agree with in theory and hard to do in practice: a stream aligned team should cover the full spectrum of delivery, including operability and monitoring, not just feature work. That ownership is the whole point, not a “nice to have.” See AgileLab’s Team Topologies handbook.

Step 2: Design stream aligned teams as the default

For 10 to 100 engineers, most teams should be stream aligned. That’s not ideology. It’s coordination cost control.

A practical target:

5 to 9 people per stream team.
One primary service area per team, with clear on call scope.
One product owner or PM per 1 to 2 teams, not per squad.

If a stream team needs three other teams to ship, it’s not stream aligned. It’s a component team with a nicer name.

This is where Conway’s Law shows up in real life. Split teams by function and the architecture splits by function. Split teams by streams and you usually get domains and APIs. That’s the point of Conway’s Law team design.

Step 3: Add platform teams only when you can name the “tax”

Platform teams exist to reduce cognitive load for stream teams. Martin Fowler calls out the key trait: a platform should be usable in a mostly self service way, with the platform acting as a service to stream teams. See Martin Fowler on Team Topologies.

Here’s the bar I like: don’t start a platform team until you can describe the tax in numbers. Examples that show up in 30 to 80 engineer orgs:

Every stream team spends 1 to 2 engineers on CI pipelines and deploy scripts.
On call pages route to the wrong team 20% of the time.
Lead time for changes jumps from 1 day to 7 days after a cloud migration.

The Team Topologies newsletter on cognitive load gives a blunt example. If 400 engineers lose one hour per day, at a €160K full load cost, the waste can hit €8 million per year. Even at 60 engineers, the math is still ugly. See Mastering Team Effectiveness: Managing Cognitive Load.

Step 4: Use enabling teams as time boxed force multipliers

Enabling teams work best as a temporary group with a clear exit. They coach, pair, and remove blockers. They don’t become a permanent “center of excellence” that owns standards and reviews.

A good enabling team charter looks like:

Goal: move three stream teams to production SLOs in 8 weeks.
Mode: facilitating and short collaboration bursts.
Exit: disband or rotate members back into stream teams.

This lines up with Team Topologies community advice: adoption spreads faster when peers share stories, not when an outside expert lectures. The 2025 panel notes that colleagues sharing benefits and caveats drives real change, and that platform adoption is often harder than stream adoption. See Five years of Team Topologies panel AMA 2025.

Step 5: Reserve complicated subsystem teams for true specialists

Complicated subsystem teams are expensive. They create a dependency by design. They only pay off when the subsystem needs deep expertise that would overload every stream team.

IT Revolution describes the intent clearly: this team type reduces cognitive load by avoiding a specialist embedded in every stream team. See IT Revolution on the four team types.

In Series B SaaS, common candidates include:

Search ranking and relevance.
Real time fraud detection.
Video encoding pipelines.
A custom database engine or storage layer.

If the subsystem is “complicated” only because it has no tests and no docs, fix that first.

Platform team design that does not become a ticket queue

A lot of CTOs ask for a platform team because they want standardization. That’s the wrong starting point. Start with reducing cognitive load for stream teams, and treat the platform like a product.

The Team Topologies site and community talk about platform as a product and platform engineering strategy as a core use case of the model. See Team Topologies: organizing for fast flow of value.

The Thinnest Viable Platform test

A useful test from practitioners is the “thinnest viable platform.” The idea is simple: build the smallest platform that removes the biggest repeated burden. The Ship It write up warns that internal platforms often bloat and slow teams down. See Ship It on Team Topologies patterns.

A thinnest viable platform for a 40 engineer SaaS company often includes:

Golden path deploy: one pipeline template, one deploy command.
Observability baseline: logs, metrics, traces, and alert routing.
Service scaffolding: repo template, CI defaults, security checks.

It doesn’t include a full internal developer portal, a custom PaaS, and a rewrite of IAM.

Platform groupings, not a monolith

The September 2025 Team Topologies newsletter describes a shift away from viewing orgs as machines and toward internal ecosystems. It also points to “platforms as groupings of teams rather than monolithic structures,” with examples like Adidas and Norway’s NAV. See Team Topologies newsletter on the second edition.

For 10 to 100 engineers, that often means:

A platform team that owns deploy and runtime.
A security enabling slice embedded into platform work, not a separate gate.
A data platform slice only when three or more stream teams need it.

The tool helps by making platform scope visible. If the platform box touches every stream team with collaboration lines, it’s not a platform. It’s a dependency magnet.

A simple platform scorecard

Use this scorecard in the Team Topology Designer review. It’s link worthy because it forces a yes or no answer.

Platform question	Good answer	Bad answer
Can a stream team use it without a meeting?	Yes, docs and self service	No, file a ticket
Does it reduce stream team on call load?	Pages drop by 20% in 60 days	Pages stay flat
Is the roadmap driven by stream teams?	Quarterly intake with usage data	Platform decides in isolation
Is the interface stable?	Versioned APIs and templates	“Ask us on Slack”

Atlassian describes platform teams as builders of internal services used by many products, with documentation and support expected as part of the job. See Atlassian’s Team Topologies guide.

Team interaction modes: the part most orgs skip

Most orgs adopt the four team types and stop. That leaves the hardest part untouched. Interaction modes define the cost of coordination.

The three modes are:

Collaboration: high bandwidth work for a short time.
X as a Service: clear boundaries and low touch consumption.
Facilitating: coaching and unblocking, then stepping away.

The 2025 panel warns that many people focus on static structures because it’s simpler. That misses the real value, since teams and needs change. See AMA 2025 panel.

A decision matrix for interaction modes

Use this matrix during design reviews.

Situation	Best mode	Time limit
New domain split, unclear boundaries	Collaboration	2 to 6 weeks
Platform capability is stable and repeatable	X as a Service	Ongoing
Stream team needs to adopt a new practice	Facilitating	2 to 8 weeks
High risk migration across many services	Collaboration, then X as a Service	4 to 12 weeks

A simple rule keeps teams honest: collaboration is a spike, not a lifestyle.

What “good” looks like at 60 engineers

A concrete scenario:

Six stream aligned teams own onboarding, core workflow, billing, admin, integrations, and trust.
One platform team owns deploy, runtime, and observability.
One enabling team runs a 6 week push on incident response and SLOs.
One complicated subsystem team owns search relevance.

Interaction modes:

Platform to streams runs as X as a Service for deploy and logging.
Enabling to streams runs as facilitating with pairing sessions.
Search team collaborates with the core workflow team for 4 weeks, then exposes APIs.

This keeps the default path low touch and keeps the expensive modes time boxed.

Conway’s Law team design: align architecture and org before it hurts

Conway’s Law isn’t trivia. It’s a budget line. If the org chart forces handoffs, the architecture will mirror those handoffs.

A practical way to use the Team Topology Designer is to run a “reverse Conway” workshop:

Start with the desired architecture boundaries.
Map each boundary to a team that can own build and run.
Mark every cross boundary dependency.
Change team scope until the dependency count drops.

A useful metric for early stage orgs:

Each stream team should have no more than 2 critical dependencies for a normal release.

If a stream team needs five dependencies, the team isn’t a stream team. It’s a coordinator.

This is also where internal tools help. Pair the topology work with our Command Center to track incidents, risks, and migrations tied to each team boundary. Use it as the “system of record” for org and architecture decisions. See our guide to tech portfolio and risk tracking in Command Center (/command-center).

And document the boundaries. Use our ArchiMate Modeler to capture domains, interfaces, and ownership in a way new hires can read in 30 minutes. See architecture documentation that stays current (/tools/archimate).

Enterprise implications for Series A and B CTOs

Team design feels “soft” right up until it blows up a delivery date. Here’s how it tends to land on a CTO’s desk.

Hiring plan becomes an architecture plan. A 12 month hiring plan that adds 30 engineers forces new team boundaries. If the topology is unclear, new hires land in the wrong place and coupling gets worse.
Platform work turns into a product decision. Platform teams that act like shared services become a ticket queue. Platform teams that act like a product group build self service paths that reduce load. Fowler’s point about self service is the dividing line. See Fowler on platform self service.
Incident response improves when ownership is clean. Clear stream ownership reduces “not our service” loops. It also makes on call rotations sane. Tie this to our incident postmortem guide and template (/tools/incident-postmortem).
Legacy modernization stops being a rewrite. Modernization works when teams can change one slice without waiting on ten others. CI&T frames Team Topologies as a useful strategy for modernization programs. See CI&T on Team Topologies for legacy modernization.

CTO recommendations for using the Team Topology Designer

Immediate actions

Run a 90 minute topology workshop. Bring product, engineering, and platform leads. Start from value streams, then draw stream teams.
Label every interaction line with a mode. If a line has no mode, it turns into Slack chaos.
Pick one platform “thin slice”. Choose a capability that removes repeated work across three teams. Ship it in 30 days.
Set a dependency budget per stream team. Track critical dependencies for a normal release. Keep it at two or less.

Policy framework

Team API policy. Each team publishes a one page “team API”: mission, owned services, on call scope, and how to engage.
Platform intake policy. Platform roadmap includes usage data, support load, and top stream team pain. No roadmap by opinion.
Enabling team exit policy. Every enabling engagement has an end date and a success metric.

Architecture principles

Stream teams own run. Stream teams build, deploy, and operate their slice. Platform reduces load, it does not take ownership.
Prefer X as a Service. Collaboration stays time boxed. If it lasts months, the boundary is wrong.
Complicated subsystem is rare. Use it for deep specialist work only. Don’t hide messy code behind the label.

For measurement, pair this work with our Engineering Metrics Dashboard to track lead time, deploy frequency, and MTTR by stream team. See DORA metrics that drive org decisions (/tools/engineering-metrics-dashboard).

And for vendor choices, use our Build vs Buy Matrix when a platform team wants to build internal tooling. It keeps the discussion grounded in cost, risk, and time. See build vs buy decisions for internal platforms (/tools/build-vs-buy-matrix).

Bigger picture: team design is a change system, not a reorg

Team Topologies keeps gaining adoption because it treats org design as a living system. The 2025 panel calls out a common trap: people adopt static team structures and miss the evolving part. Teams need to change as products, regulations, and markets change.

The second edition newsletter also pushes the idea of knowledge diffusion and internal communities, not central control. That matters for Series B orgs that start to feel “enterprise gravity.” You need guardrails, and you also need teams that can act without waiting.

So here’s the question I’d use to close a design review. If the company doubled engineers in 12 months, would the team map still make value flow faster, or would it turn into a dependency chart?

Use the tool: Team Topology Designer

Team Topology Designer guide: a practical Team Topologies designer tool for 10 to 100 engineers