How to Form Team Structure for Business Demands
Five transformations from a project to end-to-end teams
Slide contents
1. How to Form Team Structure for Business Demands
Five transformations from a project to end-to-end teams
2. Team Structure Should Follow the Next Business Challenge
Start from the desired future
Make the target architecture explicit
Shape team boundaries around it
Treat the transition as work of its own
Stabilize what is burning before redesigning the system
3. 00. Tools and Algorithm
From the desired future to a managed transition
4. Start from the Future and Work Backwards
5. Each Tool Answers a Different Kind of Uncertainty
6. Stabilize First, Then Design the Target Structure
7. 01. Project: Complete the Migration
When the deadline and cost of delay outweigh the perfect design
8. Four Failures Turned the Migration into a Fire
9. A Separate Path Bought Speed with Explicit Debt
10. Meeting the Deadline Restored the Product's Right to Evolve
Core forms and pages moved on time
Acquisition efficiency was largely preserved
The team learned to resolve acute problems
The resulting product was ready to scale
In a crisis, project mode can be more useful than a permanent org chart
11. 02. Product: Make Development Deliberate
Explicit ownership, APIs, and Kanban
12. Architecture Revealed the Future Team Boundaries
13. Contracts Connect Teams; Pull Connects the Work
14. Visible Work Turned the Flow into a Manageable System
Teams understand their areas of ownership
Work is visible to teams and customers
Throughput became predictable
The process gained a path for improvement
The product teams were ready to scale
15. 03. Scale: Separate Product and Platform
Feature-team autonomy without duplicating shared solutions
16. Team Type and Interaction Mode Solve Different Problems
17. The Platform Centralizes Repetition, Not Product Development
18. A Shared Layer Accelerates Dozens of Autonomous Decisions
Product teams ship features
The platform team develops shared tools
Standards arrive through contracts
Microfrontends preserve delivery independence
Scale requires a platform, not a shared queue
19. 04. Platformization: Mobile Bank as a Superapp
Autonomous business domains and platform teams in one application
20. Mobile Banking Became a Platform for Parallel Businesses
21. One Interface Hides a Portfolio of Different Businesses
22. Business Teams Build Value; Platform Teams Build Shared Qualities
23. Virtual Domain Boundaries Came Before Physical Separation
24. Release Dates and Engineering Culture Supported Autonomy
25. Each Business Gained a Mobile Team and Its Own Pace
Business verticals gained their own teams and backlogs
Platforms strengthened modularity, SRE, performance, and CI/CD
Release frequency increased several times
Teams own process improvement themselves
Autonomy works when shared qualities have owners
26. 05. Value Stream: Cross the Technology Layers
Reduce time to market, cognitive load, and handoff cost
27. A Stream-Aligned Team Cuts Vertically Through the Layers
28. Leadership and Specialists Span the Entire Stack
29. The Team Boundary Changes Design, Process, and Architecture
30. Mandatory Contracts and Automated Checks Hold Autonomy Together
31. Metrics Connect Platform Changes to Team Outcomes
32. A New Structure Is Needed Only for a New System Challenge
33. An Org Chart Is a Temporary Hypothesis About Delivering Value
Do not change structure without a new system challenge
Derive boundaries from the target architecture
Choose team type and interaction mode separately
Automate shared rules and measure outcomes
Goal and architecture first; teams and transition second
34. What the Model Builds On
Author PDF for YaTalks 2023 · 172 pages
Backcasting · Kanban · Conway's Law · inverse Conway maneuver
Team Topologies · four team types and three interaction modes
Five evolution cases from Tinkoff.ru and the mobile Superapp
35. Thank you!
Knizhny kub
Continue the discussion: t.me/book_cube
Alexander Polomodov, Technical Director, Tinkoff
@book_cube