Scaling a Team Tenfold
How to stay sane as a frontend team lead on the ↗tinkoff.ru acquisition team
Slide contents
1. Scaling a Team Tenfold
How to stay sane as a frontend team lead on the tinkoff.ru acquisition team
2. Speaker
Alexander Polomodov, Frontend team lead, customer acquisition, Tinkoff.ru
What this talk is about
Five steps that reshaped the frontend architecture, the team structure, and the team lead's duties.
Focus — Frontend of the tinkoff.ru unauthenticated zone
Scale — Team 4 → 40, team leads 1 → ~10
Frontend of the tinkoff.ru unauthenticated zone
Team 4 → 40, team leads 1 → ~10
3. —. Tinkoff.ru acquisition
What we owned and what the business wanted
4. One frontend for all of tinkoff.ru
Unauthenticated zone and internet bank
Stakeholders — all business units
Path from click to application
Growing stream of requests
5. The business wants it all at once
At scale, cheaply — Clients in volume, at a price
Usable UI/UX — A modern path from click to application
Scalable processes — Campaigns and tests without releases
6. Manage content without releases
Build product pages
A/B tests and personalization
Launch campaigns fast
Measure the effect
7. Team and architecture grow together
8. 00. Where it all began
A monolith with shared releases — one team for everything
9. One lead does everything
10. 01. First improvements
A buffer in front of stakeholders, and our own releases
11. The lead loses focus
Stakeholder communication
Code and deploys
Too many contexts
12. Our own releases, our own branch
13. A project manager appears
14. 02. Scaling as-is
Split the app and the team by product
15. The team hits a ceiling
More developers and QA
Growing task volume
One lead as the bottleneck
16. Splitting the app into business parts
17. Two streams: banking and insurance
18. Grow inside, hire outside
Inside the company
performance review of developers
potential tech and team leads
Outside the company
candidate requirements
a dedicated hiring track
19. Senior → tech or team?
20. 03. Optimizing the effort
Shared parts into packages, org work to release managers
21. Duplicating shared work
More teams now
Each builds its own
Same forms rebuilt again
22. Shared parts into packages
23. Release managers take work off the leads
24. Growth quietly degrades everything
What we started measuring so quality wouldn't slip as we grew
Volume — Functionality per release
Speed — Average time to release
Quality — Escaped defects
25. 04. Delegating ownership
Separate repositories and clear ownership boundaries
26. Monorepo blurs ownership
Side effects from others' edits
Hard to try new things
Nobody owns the shared code
27. Separate repos + shared tooling
28. A core team and an architect
29. Tools are products too
How it should work
shared understanding of goals
agreed architecture vision
right decomposition
The risks
work detached from business
funded with leftovers
botched decomposition
30. 05. The step that isn't here yet
Teams keep growing — the architecture has to catch up again
31. The lead's duties move upward
32. The team grew tenfold
33. The lead's role grows up
34. How a lead stays sane
Clearly understand business goals
Know the team's lifecycle stage
Know your duties at that stage
Honestly decide: do you want it
…or keep writing code
35. Questions
Tinkoff.ru
Thank you! Questions — scan the QR, or email alexander.polomodov@gmail.com
Alexander Polomodov, Frontend team lead, customer acquisition, Tinkoff.ru
Ask a question