Structure and What It Permits

Overview

Part 4 opens with the most mechanical of the organisational facts, because it is the one you can read off a chart and reason about immediately.

The claim: structure determines which architectures are cheap and which are expensive. Not which are good — a design does not become wrong because the organisation makes it costly. But a design whose cost the organisation imposes is a design that needs a sponsor for that cost, and knowing which you have proposed is the difference between a plan and a wish.

Four shapes

Functional. Teams organised by discipline — backend, frontend, data, operations, quality. Any feature crosses several teams, so delivery is a coordination exercise by construction. Permits: deep specialism, consistent standards within a discipline, efficient use of scarce skills. Blocks: anything requiring one team to own an outcome end to end. Your role becomes: a coordination broker, because you are one of the few people whose view spans the teams a change touches.

Product-aligned. Teams own a product or a slice of customer value, end to end. Permits: fast independent delivery, clear ownership, short feedback loops. Blocks: consistency. Three teams solve the same problem three ways, and nobody is wrong. Your role becomes: preventing divergence that will be expensive to reconcile later — and choosing which divergence to tolerate.

Matrix. Dual reporting: a discipline line and a product line. Permits: in theory, both specialism and product focus. Blocks: clear decision rights. Everything has two owners, which often means none. Your role becomes: navigating ambiguity about who decides — and the most valuable thing you can produce is a written statement of who decided what, because that is the scarce artifact.

Platform. One group builds internal capability that other teams consume. Permits: leverage. One good decision serves everyone. Blocks: a platform group drifts from what its users need, and adoption is voluntary, which makes it political rather than technical. Your role becomes: making the platform worth adopting, and noticing when it is being routed around.

The same design, two different prices

graph LR
  R1["A change that needs<br/>one owner end to end"] --> F1["Backend team"]
  R1 --> F2["Frontend team"]
  R1 --> F3["Data team"]
  R1 --> F4["Operations"]
  F1 --> C1["Four negotiations,<br/>one release train"]
  F2 --> C1
  F3 --> C1
  F4 --> C1

  classDef req fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef team fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef cost fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class R1 req
  class F1,F2,F3,F4 team
  class C1 cost

The same change, where one team owns the outcome:

graph LR
  R2["A change that needs<br/>one owner end to end"] --> P1["Stream-aligned team"]
  P1 --> C2["One decision,<br/>one release"]

  classDef req fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef team fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef cheap fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  class R2 req
  class P1 team
  class C2 cheap

The identical requirement priced by two structures. Nothing about the design changed — the terracotta box is a cost the organisation imposes, and somebody has to be willing to pay it.

The practical move

Read the structure, then do one of two things, deliberately:

Propose the design the structure makes cheap. Boundaries that match team boundaries get built. This is not capitulation — it is the same reasoning as Module 3’s capacity-aware sequencing, applied to coordination rather than to headcount.

Or propose the expensive one and name the price. If a design genuinely requires a boundary the organisation does not have, say so explicitly: this needs one team to own both halves, which means either a team change or a standing cross-team agreement, and here is who would have to sponsor it. An unnamed coordination cost does not disappear; it reappears as a design that slips quarter after quarter for reasons nobody can articulate.

The chart is not the structure

Most real organisations are hybrids — a product-aligned front end over a functional platform, or a matrix in name and functional in practice. Treat the published chart as a hypothesis.

One question cuts through it: who can say yes to a change that touches three teams?

If the answer is one named person, you have a functional structure with a strong centre, whatever it is called. If the answer is “the three team leads, together”, it is product-aligned with negotiated interfaces. If the answer is a committee, it is a matrix. If nobody can, you have found the thing your job exists to fix.

The cost of reading this wrong is concrete: you spend weeks building consensus with people who were never the decision, while the person who was waits to be asked.

What the migration reveals

The published facts: roughly 140 engineers, all reporting through Tomas Beck. A Rails monolith from 2016 that still runs most of the business, with Ivan Petrov as its owner. About twenty newer Go services. Two years into a strangler-fig migration with about 35% of traffic moved. Support sits separately, under Maya Ortiz with Grace Adeyemi leading the team.

What that implies. A migration producing twenty services suggests teams organised around the slices they are extracting — stream-aligned in practice, whatever the chart says. But the monolith has a single owner with eight years of tenure, which is a functional centre of gravity: anything touching the monolith’s internals goes through one person.

So: product-aligned at the edges, functional at the core, with the core being the part that still runs most of the business.

What that prices. The AI support platform touches three things: the documentation corpus, the monolith’s API for jobs and credits, and the support tooling Grace’s team uses. Three boundaries, three different owners, and one of them is the de facto gatekeeper for the system of record.

That is an expensive design in this structure — and it retroactively validates the Module 3 decision. Two new services alongside the Go estate, reaching the monolith through an interface rather than its database, was chosen for blast-radius reasons. It is also the cheapest shape available here, because it minimises the number of times anyone has to negotiate with the monolith’s owner.

The question to ask in week one: who can say yes to a change touching the monolith’s API, the Go estate and the support tooling? If the answer is Tomas, the structure has a strong centre and he is the conversation. If the answer is “Tomas plus Ivan in practice”, then Ivan’s informal veto is structural rather than personal — which is the subject of topic five.

Feeds the workbook

This is the first half of your organisational analysis. State the structure you observe, the evidence for it, and — the part most analyses omit — which of your Module 3–7 design decisions that structure makes cheap, and which expensive.

Check your understanding

1. Apply the three-team question to an organisation you know. What did the answer reveal that the chart did not?
2. Take one decision from your Modules 3–7 design. Is it cheap or expensive in the structure you have read, and who pays?
3. A design needs a boundary the organisation lacks. Write the sentence you would use to name the price.

---

→ Structure prices designs. There is a mechanism behind that, and it is also a lever. — Conway’s Law as a tool