Skip to content
back to the presentation
concise summary2023CTO

How to Form Team Structure for Business Demands

This review follows the author's written account of the YaTalks 2023 talk: how to rebuild a division's structure when the business goal changes. Alexander Polomodov answers from eight years at a large fintech, folding Conway's law, the inverse Conway manoeuvre, Team Topologies and change management into a single algorithm, then testing that algorithm against web and mobile banking cases.

YaTalks 2023 · Yandex6 min read

The summary is compiled from the material description in the catalogue and verified slides. Linked below: the full transcript and the recording.

The main thread of the material
01

Five steps, plus a step zero

The opening move is working backwards, also called backcasting: start from the end goal and reason back to today. That yields a five-step algorithm — name the long-term goal of the division, judge which systems architecture serves it best, apply the inverse Conway manoeuvre to derive team structure from that architecture, shape the result with Team Topologies patterns, and run the transition through change management.

Ahead of all that sits step zero: find what is on fire and fix it. While a division lives in firefighting mode, designing a target structure is wasted effort. The intellectual base is Melvin Conway's 1968 paper on how committees invent, plus the Team Topologies book with its four team types — stream-aligned, platform, enabling and complicated subsystem — and its three interaction modes: collaboration, facilitating and x-as-a-service.

02

Migrating a large fintech, then turning product

The first case is the 2016 migration of web applications to a new site. Work on the new solution had already run for over a year, the wider team was 50-plus people, the author's own front-end team had three, and three months were left before the switch. Four problems were open: server-side rendering did not work, there was no web analytics for the SPA, form mechanics were unfinished, and releases took about three weeks because regression testing was manual.

The answer was a project approach: short iterations, separate infrastructure, a dedicated development branch, and two releases a week instead of a three-week cycle. The main forms and pages moved across on time with almost no loss. By mid-2017 the work turned product-shaped — server-driven UI, an in-house A/B testing system, better indexing — so the front-end, content-services and A/B platform teams had their responsibilities separated through APIs, with the flow organised as Kanban and visualised.

03

Mobile banking and the shift to streams

From 2019 the same algorithm was applied to the mobile bank, which started as one shared team of nearly 50 people covering every product at once. Conway's law, the inverse manoeuvre and Team Topologies were used to split it into autonomous teams along product verticals plus platform teams focused on modularisation, reliability, performance and CI/CD. Release frequency improved several times over, though the author insists this was multi-year change management rather than a one-off reshuffle.

In 2022 the key products moved from stack-organised teams to end-to-end stream-aligned ones, aiming to cut time to market, lower cognitive complexity and improve the architecture. New teams were given mandatory rules: team attributes, development and deployment processes, operating rules, and automated team health checks. Metrics ran along three axes — developer performance, product quality and team throughput — with Meta's paper on continuous deployment of mobile software at Facebook serving as the reference point.

Takeaways

What to take away

  1. 01Team structure follows from the long-term goal and the target architecture: the inverse Conway manoeuvre is how you design an organisation to fit the system you want.
  2. 02Step zero outranks step one — while something is on fire, it is too early to build a target structure.
  3. 03One shared team of nearly 50 people covering all products was the bottleneck; splitting into product verticals plus platform teams sped up releases several times over.
  4. 04Moving to stream-aligned teams demands fixed rules for development, deployment and operations, backed by automated health checks and metrics.

Sources

Share