I’ve been thinking about scaling in my current role as the Manager of Managers for our Platform Group.
No, this isn’t about a ridiculously impressively large MongoDB cluster, or scaling MongoDB config servers with insufficient network bandwidth at scale, about finding the right abstractions for a tangled web of an area, or using wiredtiger’s zlib to reduce storage needs and no it isn’t about platform services with high QPS.
I’ve been thinking about scaling people and their units of operation.
We’ve been growing ~30-50% per year in my part of the Engineering organization and I see the inherent challenges of staying far enough ahead of that growth curve so that it’s a sustainable climb.
At this rate of growth:
- What you start planning now needs to be the solution that will serve from now+6 months to now+18 months. Anticipate the execution lag. Watch the more distant horizon.
- Hire leaders before you’ve filled your IC ranks, otherwise you’ll be ~6 mo or more behind and straining existing leaders.
- Treat org design as you would distributed systems, anticipate the following challenges and be ready with redundancy and fallback positions:
- Attrition
- Promotion
- Re-organization
- Parental leave
- Bus factor
- Burnout
- Believe in specialization of labor and use that as a way to horizontally scale leadership and to help IC engineers focus on their area of expertise. Hire PMs and EAs to scale out EMs, their bosses and the ICs.
- Invest in recruiting org to enable hyper growth hiring. They need to be hired in advance of the true necessity or results will be 6 months delayed.
- Hire additional EMs when your teams exceed 5 engineers so that the group can avoid scaling bottlenecks. By the time a new EM starts, you’ll have 8 engineers in that group and be blocked from scaling further without starting to stretch leadership thin.
- Minimize as much friction in hiring as possible and get better at managing performance.