High growth startups: Uber and CloudKitchens with Charles-Axel Dein

The Pragmatic Engineer • • 1h44 → 8 min • #50
High growth startups: Uber and CloudKitchens with Charles-Axel Dein
Watch on YouTube

Summary

  • Charles Axel Dein was engineer #20 at Uber in 2012, grew with the company through its hypergrowth phase, and now works at CloudKitchens. He’s also the maintainer of the popular “Professional Programming” GitHub repo (a curated reading list for engineers). This episode covers what it’s like to work inside a hypergrowth startup, how to thrive as a software engineer in fast-paced environments, practical productivity tactics, and how AI is changing software engineering.

Working inside a hypergrowth startup

  • What hypergrowth actually looks like day-to-day:

    • At Uber, the team went from ~20 engineers to 2,000+ in about 5 years, with 1–2 new engineers joining per week in some offices.
    • There was no roadmap and very little process; people learned by doing.
    • Headcount planning was chaotic: the real process was “keep hiring until you hit your limit, then more headcount appears.”
    • On-call was brutal—engineers were woken up almost every night, and incidents were constant.
    • Despite the chaos, a continuous stream of new hires brought energy that lasted 4–6 months each, creating a culture of “let’s fix this.”
    • The company prioritized building new features over fixing root-cause architectural problems because each project represented $50–100M in incremental revenue.

  • Why hypergrowth startups are probably behind us:

    • The era of zero-interest-rate money fueled hyperscale startups that could raise billions and hire extremely fast.
    • Charles believes that era is over and that’s a good thing—it leads to less waste and better financial discipline.
    • CloudKitchens operates with a smaller, more focused team and more humility than Uber did at its peak.

  • The physical world as a source of interesting engineering problems:

    • Startups that operate in the physical world (Uber, CloudKitchens) face unique technical challenges like optimization across space and time, latency budgets (food must be delivered within a time window), and real-world impact when things break.
    • Charles argues these companies are “fundamentally good” because they optimize real processes rather than creating addictive virtual products.

Deployments, incidents, and reliability

  • Decoupling deployment from release:

    • The most fundamental way to improve stability is to deploy code behind feature flags first, test with your own user, then gradually roll out.
    • This ensures a deploy never breaks production; you release and monitor incrementally.

  • Tenancies vs. staging environments:

    • Uber used “tenancies” (running the same code everywhere with test tenancies and feature flags) rather than separate dev/staging/prod environments.
    • Charles thinks you need all three: a quick tenancy for routing traffic, a staging environment to “go crazy,” and a pre-production environment that’s stable enough that breaking it opens an incident.
    • The earlier you detect a problem, the faster and cheaper it is to fix.

  • Incident management at CloudKitchens:

    • Three key metrics: time to detection, time to mitigation, and time to resolution.
    • Time to mitigation is the most important—how long until the customer no longer sees the impact.
    • At Uber scale, high traffic volume makes detection easier because monitoring catches anomalies quickly.

  • The danger of overly blameless postmortems:

    • Removing the human component from incident reviews misses ~80% of potential mitigations.
    • Example: an engineer woke up at 2 a.m., tried to fix a small outage, and turned it into a major one because they were tired. A blameless postmortem focused on system fixes but missed the human reality.
    • Not discussing the human element also misses training opportunities (e.g., if no one was trained on feature flags, they won’t use them).

Hiring at scale

  • Treat hiring as a funnel:

    • Map every step of the process as a pipeline and identify where you have leaky buckets.
    • Build a tight partnership with recruiters—weekly syncs where engineering managers and recruiters share sourcing strategies, target companies, and profile requirements.
    • Charles’s manager Tuan Fan checked in with recruiters every morning to review interesting profiles.

  • Pairing interviewers:

    • Two interviewers per interview: a primary who leads and a secondary who observes and gives feedback afterward.
    • New interviewers shadow experienced ones first, then reverse-shadow (lead while the experienced interviewer gives feedback).
    • This creates a feedback loop that improves interviewing skills over time.

Personal productivity and avoiding burnout

  • Divide and conquer:

    • When overloaded (e.g., Charles had 30 direct reports during a performance review season), explicitly delegate projects to others.
    • Be clear about expectations: “I need you to lead this project. I’ll check in weekly. Make a plan.”
    • This gives people growth opportunities, stretches them outside their comfort zone, and saves the manager’s time.

  • Charles’s personal productivity system:

    • Uses the Getting Things Done (GTD) methodology.
    • Uses a plain to-do file and a GitHub repo for personal knowledge management (PKM).
    • Uses Anki flashcards to memorize things like the Python standard library, architecture patterns, and data science methodologies.
    • Reads about 1 hour per day (both fiction and non-fiction) and adds “classic” articles to his Professional Programming repo.

Traits of standout software engineers

  • Ship and lift:

    • The best engineers focus on shipping value and building things, even at the staff level. They find creative ways to achieve 10x improvements in quality or speed.
    • They also “lift” people around them—helping, training, and having a good attitude.
    • They don’t stop at team boundaries; they’ll trace a problem through the API gateway to the backend and fix it, even if they’re a mobile engineer.

  • Humor and self-deprecation:

    • Taking yourself lightly prevents ego from getting in the way.
    • It makes you easier to work with and more open to learning.

  • Structure and method:

    • Good engineers have a systematic approach to debugging: start with observability and metrics, form hypotheses, and find creative quick mitigations.
    • Example: during an incident where everyone thought the problem was in System A, a creative engineer identified the real issue elsewhere and found a quick mitigation.

  • Reading and doing go hand-in-hand:

    • The Professional Programming repo is not meant to be read cover-to-cover.
    • During the day, you’re in “doing mode”—try things, use AI to unblock yourself.
    • Outside of work, read about the fundamentals of the topic you’re stuck on; this unblocks you and speeds up your process.

Project management for engineers

  • Why engineers need project management skills:

    • As you become more experienced and higher-paid, you take on more complex problems. There’s only so far you can go without project management.
    • At Uber, engineers led projects because there weren’t enough product managers. Charles brought in an external trainer, but engineers rejected it as “old school.” The lesson: build your own training based on what your team actually needs.

  • A lightweight project management process:

    • Do some planning up front (whiteboarding, document, whatever works).
    • Send the plan out for comments.
    • Have a kickoff meeting (projects without one tended to go poorly).
    • Send a weekly summary to the team and stakeholders with status (on track/at risk), highlights, lowlights, and mitigation plans.
    • Lowlights force early conversations and prevent surprises.

  • Weekly updates as a superpower:

    • Forces you to be explicit about goals, successes, and areas for improvement.
    • Drives perception of movement—just sending a weekly update makes people feel progress is happening.
    • Works for both teams and individual contributors.

  • Understanding the time-cost-quality tradeoff:

    • If a project is late, you can cut scope, add people (which doesn’t always work), or extend the timeline.
    • The right balance depends on where your product is: a startup MVP team that might not exist in 2 months should move fast and take on technical debt; a mature platform team building architecture for the next few years should invest in quality.

Getting hired as a software engineer

  • Resume advice:

    • Focus on experiences and projects. For new grads, promote personal projects.
    • Don’t use AI to generate your resume—Charles estimates 25 of the last 30 resumes he reviewed were AI-generated, full of relative numbers (“reduced deploy time by 30%”) without absolute context.
    • Be original and creative; recruiters review hundreds of resumes per day.

  • Interview preparation:

    • Have a structure and method: for algorithms, start with brute force and optimize; for system design, start with requirements and work through architecture focusing on tradeoffs.
    • Prepare questions for the interviewer about technical challenges you’ll face—this helps you evaluate whether the company is right for your career.
    • Research the company thoroughly: understand their products, business model, and trajectory.

  • AI in the hiring process:

    • AI-generated resumes are increasingly common and easy to spot.
    • In interviews, some candidates use AI during coding exercises, which only tests prompting ability, not engineering skill.
    • Charles recommends using AI as a coach/trainer (e.g., preparing questions, practicing architecture interviews) but not during the actual interview.
    • The industry may move back toward on-site interviews to prevent AI cheating.

AI’s impact on software engineering

  • Current state at CloudKitchens:

    • AI coding tools are “moderately useful”—helpful but not transformative.
    • Best use cases: navigating code, refactoring, well-specified APIs, and migrations.
    • Migrations are a particularly good use case because teams hate doing them but they need to happen. At CloudKitchens, the platform team created a prompt engineers could copy-paste to do migrations, then review the code.

  • What AI is not good at:

    • Design and architecture decisions—these will likely remain human work.
    • Complex, poorly specified problems.
    • It often reinvents features that already exist in standard libraries because it’s trained on Stack Overflow and open-source code of varying quality.

  • Security implications:

    • AI agents operating at scale will amplify supply chain attacks (typosquatting, repo takeovers).
    • Security engineering will be a high-demand role.

  • Engineering management and AI:

    • Charles uses AI as a coach for reviewing documents and getting initial feedback.
    • Warns against using AI to generate performance review feedback—“writing is thinking” and outsourcing it loses the reflection process.
    • Nobody wants to read AI-generated text; it’s better to exchange the original prompt directly.

  • Code review becomes more important:

    • The first time Charles used AI to generate code, he didn’t proofread it carefully, submitted a PR, and got extensive feedback.
    • Reading and making sense of code you didn’t write is higher cognitive load than writing it yourself.
    • If AI generates a lot of verbose, unmaintainable code and code review practices are weak, startups may slow down or fail because the code becomes unmaintainable even for AI.

Thriving in fast-paced environments

  • Non-obvious recommendations:

    • Memorization with flashcards: Memorize your language’s standard library, architecture patterns, and commonly used commands. This pays dividends over time.
    • Extreme ownership: Treat the team and project as fully yours. Understand all dependencies and the broader context. Don’t stop at team boundaries.
    • Underpromise and overdeliver: Set timelines conservatively and find creative ways to deliver faster.
    • Meet people in person: Especially in remote or multi-office setups, meeting colleagues face-to-face prevents miscommunication and builds trust. Written messages (Slack, email) can come across as aggressive when the person is actually nice.

  • Imposter syndrome is underrated:

    • It drives curiosity and continuous improvement.
    • Feeling like people around you are smarter is natural at a high-growth startup and suggests you’re in the right place.
    • As Dan Heller says: “Embrace self-skepticism and doubt yourself every day.”

Reading recommendations

  • Fundamentals over trendy books:
    • The Linux Programming Interface—explains kernel APIs and historical technical decisions (e.g., why red-black trees over hash maps).
    • Complications by Atul Gawande—about learning from mistakes and having a scientific process for error.
    • Aviation incident postmortems—the human component of outages is very applicable to software incidents.
    • Fiction—improves writing and reading skills, and trains you to digest information quickly.
    • Philosophy—software design is fundamentally about decomposing problems, which is the core of human reason and classical philosophy.

Survivor bias in advice from successful companies

  • Much advice from Uber, OpenAI, and similar companies suffers from survivor bias.
  • The chaos and speed that caused quality problems may have been the very things that made the companies successful.
  • Charles’s view: first build a product and a successful business; quality and platform investments come after.
  • Be skeptical of best-practice blog posts from successful companies—optimize for your most pressing problems, not for what worked for someone else.
  • “Malleable software” (tools that leave users in control, like spreadsheets) often works better than over-engineered internal tools because it provides speed and flexibility.
Back to The Pragmatic Engineer