scalable/scale/team topologies/lesson 05 cph / /
lesson 05 / 07 · 16 min · updated ·

applying it to a real org

a fictional company with ten teams. we redesign it. drag-and-drop topology exercise at the end.

lumen

lumen is a fictional saas company of about 90 engineers across eight teams. the product is a collaborative document editor with a sign-up funnel, admin back-office, billing, and an ml-powered auto-summarisation feature. below is the topology — eight teams laid out with their interaction lines already drawn.

your job is to classify each team by type: stream-aligned, platform, enabling, or complicated-subsystem. click a node to read what the team does, pick a type from the side panel, repeat for all eight, then check the topology. the interaction lines are clues — look at who talks to whom, and in what mode.

classify lumen's teams

read each team's role, then pick the type that fits. a correct topology will have a mix: several stream-aligned, a small number of platforms, one or two specialists, and a temporary coach or two.

interactions collaboration x-as-a-service facilitating

what to look for

  1. the majority should be stream-aligned. lumen has four of them: sign-up, editor, billing, admin — each owning a user-visible flow with its own metrics. if you counted fewer than four, you probably misclassified a stream-aligned team as a platform.
  2. platforms are serving many. both platform and search have incoming x-as-a-service arrows from multiple consumers. that's the tell — platforms have portfolios. if nobody's consuming you, you're not a platform.
  3. complicated-subsystems are specialist islands. ml-core publishes a single api (scoring) to one consumer (editor). the rest of the org doesn't reach into it, and the team doesn't spread out. that's the shape.
  4. enabling teams show up on a timer. cloud-coach is connected via facilitating (dashed line) to one team, for one project. the interaction mode is the giveaway. facilitating + time-bound + coaching vocabulary = enabling.

the reverse conway reading

now look at the topology as an architecture diagram, not an org chart. the platform team's services are consumed by four stream-aligned teams — so lumen's production architecture has a platform layer with a well-defined api, consumed by four independent vertical slices. ml-core lives as a distinct service with one consumer. search is a shared infrastructure. cloud-coach leaves no runtime trace — it's pure knowledge transfer.

that architecture was chosen by this team graph, not by the code. if lumen's leadership tried to ship a different architecture — say, merging search into the editor service — they'd be fighting Conway's law. the reverse manoeuvre says: first change the teams. then the code follows.

the test for your own org. draw this picture for your real org. every team, every recurring meeting or dependency, every interaction mode. if the shape surprises you, the architecture is probably surprising you too. if the shape looks wrong, it probably is.

next: the common ways teams misapply the framework — and what each failure mode looks like up close.

scalable labs·cvr 30091604·github·linkedin·hello@scalable.dk