How to Structure Teams for Business Demands

The approach works backward from the desired result: which system can achieve the goal, and which teams can develop it? The inverse Conway maneuver connects communication patterns with architecture. Team Topologies helps define team types and interactions, while change management supports the transition. Before this work, the author identifies a preliminary step: address immediate operational problems.

The first example is a 2016 web-application migration. With months remaining, important features, analytics, and server-side rendering were incomplete, while manual testing delayed releases. A project team selected essential scope, separate infrastructure, and frequent releases. Temporary implementations were later rewritten, and the SEO issue was deliberately deferred beyond launch. This was an explicit trade-off for a time-bound objective.

After migration, the work shifted to remaining pages, server-driven interfaces, internal experimentation tools, and indexing improvements. Responsibility was divided among frontend, content services, and an A/B testing platform. APIs defined their interaction, and Kanban organized the work. The goal became predictable delivery and a clear direction for each technical product rather than a temporary coordination effort.

Further scaling separated shared tooling from product work. Platform teams developed reusable components and interface infrastructure; product teams built capabilities for their business areas. The web architecture gradually adopted microfrontends. The example connects autonomy with concrete code and ownership boundaries: renaming teams without common capabilities and clear integrations does not solve the underlying problem.

In mobile banking, the super-app required different businesses to develop independently. The shared team split, while platform groups addressed modularity, reliability, performance, and build infrastructure. This transformation took several years. The next step aligned people around business flows across mobile, APIs, and other systems to reduce waiting between technical layers.

Moving people into end-to-end teams came with mandatory rules for developing, releasing, and operating the application, with automated checks intended to enforce them. Platform owners tracked engineering productivity, product quality, and team outcomes to understand their contribution. A later large reorganization is mentioned but reserved for another account. The article therefore provides concrete examples and a reasoning approach, rather than a complete universal organizational model.