Scaling During Hypergrowth
summary
Hypergrowth needs specific guardrails: start a Wiki now and put runbooks and postmortems there, hire generalist A‑players plus a people person, and assume anything can fail. Use boring, well‑known tech for defaults (MySQL at scale, Node.js only where it fits), isolate realtime state from backend writes so core flow survives database outages, instrument everything (Kafka/Celery logs to S3, Graphite, Nagios, PagerDuty) and encode best practices in in‑house frameworks like Clay and Playdoh. Expect failure and plan for recovery.
AI-written summary · about
chapters (29)
- 0:00Intro
- 1:14Scaling During Hypergrowth
- 3:12Who am I
- 5:36Oberthur
- 6:26What is Uber
- 8:14Why should you listen to me
- 9:31What is the most important thing
- 11:09Second most important thing
- 13:29Hiring generalists
- 14:19People
- 15:35Failure
- 17:58Design for failure
- 20:30Woody Allen quote
- 22:14Testing wont save you
- 22:59Minimize failures with redundancy
- 23:19Disaster recovery plans
- 27:09Stateless processes
- 29:52Serviceoriented architecture
- 32:03Service isolation
- 35:06Automated monitoring
- 37:06Logging everything
- 40:35Graphing everything
- 42:10Monitoring everything
- 43:22Dont get creative
- 45:10We did something crazy
- 45:28Choose the right tool
- 46:07Be secure
- 47:02Create frameworks
- 48:09Hire pretty geniuses
related talks
33mScaling yourself during hypergrowth
29mNavigating the chaos of scaling
24mFrom Startup to Scale Up Designing for Growth from Day One
24mHow to design your team for scale
31mBuilding World Class Ops Teams
26mScaling engineering organizations
28mFrom Startup to Scale Up: How to Scale Engineering teams
31mScaling