Android at Scale
summary
Panelists compare concrete patterns and mistakes for scaling Android: teams grow from 7→20 and 10→90 to 200+ engineers; use cross‑functional feature teams backed by a platform/competency team that owns crash KPIs, app vitals and reusable components; run a two‑week release train with rotating release engineers to share crash ownership; onboard with code labs and pair programming; adopt Gradle modules/monorepo, Compose plus lint rules; common failures include rewriting without a design system (colors everywhere) and poor communication about library adoption.
AI-written summary · about
chapters (15)
- 0:00Introduction to scaling Android
- 2:11Efficient large team structures
- 9:16Best scaling decisions made
- 14:15Regrets in scaling approaches
- 19:07Platform team responsibilities
- 21:13KPIs for scaled teams
- 27:54Consulting on scaling challenges
- 30:04Feature vs platform team balance
- 34:01Managing pull request reviews
- 39:20Attracting talent to scale teams
- 41:51Remote onboarding strategies
- 48:18Scaling platform teams across apps
- 52:28Remote vs onsite productivity
- 57:09Making platform teams attractive
- 59:38Closing remarks and Q&A
related talks
41mBuilding Mobile Apps At Scale
43mThe Engineering Playbook for Growing Android Teams
01h 32mLeveling Up: Panel Discussion
47mRoundtable: process for your Android team
01h 28mApps at Scale: An Industry Discussion
51mBuilding Effective Teams of Competent, Friendly People
29mGrowing Your Team While Remaining Efficient
21mScaling Android at PagesJaunes