How to Structure Teams for Business Demands

The opening claim is that structure follows business strategy and sets the pace of delivery. A bad structure turns into a set of bottlenecks; a good one grants autonomy. The first frame is three maturity horizons: Run for operating what exists, Change for improving the current business, and Disrupt for creating new products. Each horizon needs its own team types and processes, and a service company weights organisational design differently from a product company.

The second frame is Conway's law: a system copies the communication structure of the organisation that builds it. Hence the inverse manoeuvre, where the org chart is designed to fit the architecture you want. Microservices demand autonomous teams, a monolith usually mirrors centralisation, and changing architecture without touching structure is doomed. Then comes Team Topologies by Skelton and Pais: stream-aligned, platform, enabling and complicated-subsystem teams, plus three interaction modes — collaboration, x-as-a-service and facilitating.

The real limit on a team's scope is its cognitive load, because team memory is finite. The talk splits that load three ways: intrinsic, the difficulty of the task itself; extraneous, the friction of tooling and environment; and germane, the effort of learning and making sense. Too broad a remit fractures focus and raises defect counts, which is why a good platform exists mainly to strip extraneous load off product teams.

A stream-aligned team is staffed with a product manager owning priorities and roadmap, back-end, front-end and mobile developers, QA or SDET for quality and automated tests, an analyst for requirements and metrics, and a designer in product teams. Size is usually five to nine people, close to Amazon's two-pizza rule. The platform is framed as an internal product with its own product manager, roadmap, SLAs on services, self-service through docs, templates and a CLI, and adoption and satisfaction as its metrics.

The large fintech case is presented as a sequence: start from a resource pool and a stream of feature tickets, then feature teams, then platform teams, then a split along business domains. The outcome was stronger team autonomy and a multi-fold speed-up in delivery, carried by stable product streams and platform support. Structure is then checked with two sets of metrics: objective DORA figures such as lead time and MTTR, and subjective SPACE and DevEx signals covering flow, feedback and cognitive load, with eNPS as a leading attrition indicator.

A separate list covers harmful structures: matrix setups with several reporting lines, resource pools instead of stable teams, shared services without SLAs, splitting by technology rather than by domain, and oversized teams beyond twelve people, where communication gets expensive and ownership diffuses. The talk keeps models and practice apart: Team Topologies, Conway's law, cognitive load theory and the DORA, SPACE and DevEx research are external sources, while the structural examples come from one company's experience.