High growth startups: Uber and CloudKitchens with Charles-Axel Dein (Category Engineering)
I saw something interesting. interview Charles-Axel Dein gave Gergely Orosz in the Pragmatic Engineer podcast. The guest was the 20th engineer at Uber and is now a tech leader at CloudKitchens. He is also the author of the legendary Professional Programming Reading List (15 He has been collecting useful articles for years, now 48K е on GitHub.). He’s interesting to listen to, as he’s caught up in this period of hyper-growth at Uber and on the podcast tells a lot of stories and lessons learned from that time. If you cut them down, they sound like this.
🚀 Team on takeoff Hypergrowth = avalanche-like expansion of commands. Early Uber hiring was non-stop. We were looking for experts-generalists with a wide range of skills: during hypergrowth, adaptable people are valued, not narrow cogs. Every engineer is involved not only in the code, but also in the product: Programming is only a part of our work. We are highly involved in product decision-making To scale organizationally, Uber even rehearsed and divided engineers into platform teams. (infrastructure) and product teams (product) It is a decision that defines culture for years to come. At CloudKitchens, Déin applies the same principle: to assemble strong autonomous teams ready for rapid growth.
⚙️ Architecture and scale
- Uber's supergrowth challenged tech. Monolithic Python code base (~450k lines) She stopped pulling and ~5 for years 1000+ microservices
- Our own data centers also cracked at the seams; later 9 Uber has been migrating to the cloud for years. In parallel, we built internal platform solutions. (For example, observability) for monitoring and deploitation so that every product team does not reinvent the wheel Bottom line: architecture is evolving in leaps and bounds, and you have to be prepared for that.
🔥 Incidents and automation Lightning growth = inevitable failures in production. Charles Explains How Important Oncall Culture Is: Responding Quickly and Learning Post-Myself ("Blameless" parsing of files - all our). CloudKitchens has learned the lesson of not automating everything blindly. First you need to do it manually and make sure that the process makes sense – sanity check! Otherwise, automation can bring bugs on its own. (designer errors). Manual first, automation second.
🤕 Burnout vs Imposter Syndrome Work in hypergrowth is exhausting, it is worth saving energy and not driving yourself into chronic burnout. In fast-growing teams, it is normal to feel incompetent. Instead of panicking, use that feeling as a growth driver – if you feel uncomfortable, you’re actually growing out of your comfort zone.
Productivity and growth To manage the chaos of hypergrowth, you need personal life hacks. Charles is a fan of GTD methodology (Getting Things Done) Things for Task Management: These Tools Help You Keep Focus and Don’t Drown in Business In addition, he is constantly learning: 15 For years, it has been expanding its reading list for programmers. (The same repo at 48K) and absorbs tons of information He also advises to pump the CS-base: understanding how compilers, operating systems and other tech fundamentals work. Such fundamental skills remain valuable in any stack and any hype cycle.
Career insights Hypergrowth values engineers who do more than just write code. The main thing is ownership and flexibility of thinking: top engineers take responsibility, think about the product and tighten the team, not just features roll out. At the interview it is better not to cheat, but to show your real skill, albeit with small flaws, than ideal, but someone else's solutions.
In summary, hypergrowth companies are chaos, speed, risk and huge opportunities.)
#Architecture #Engineering #Management #VC #Startup #Software #Leadership