Uber EM Reveals 14 Principles for System Design, Team Leadership & Career Transition

1. Core Elements of Building Large-Scale Systems

Sendil emphasizes that success hinges on laying a solid architectural foundation . Slow down during groundwork: understand what you're building, the system's criticality, existing problems, and delivery approach. Once the foundation is set, you can execute at high quality and speed, achieving exponential growth. Post-delivery, observe user feedback, understand usage patterns, and be explicit about trade-offs. This creates a feedback loop: shorter loops → deeper understanding → faster iteration.

2. When to Compromise on Infrastructure

Compromise depends on the problem. Sendil describes starting with a proof-of-concept (POC) with reduced scope to validate the solution. If the POC solves the real problem in a small scope, you can accelerate and take shortcuts because the blast radius is limited. Ship a version, learn, gather data.

3. Scaling from 2,000 to 50 Million Users

After launch, compare data and experience to decide next steps. Scaling requires considering budget, SLOs, SLAs and using the feedback loop from the first iteration. Combine data and feedback to build an architecture that supports faster progress while delivering meaningful impact. Break problems into small chunks and iterate in cycles. For legacy systems where big changes are risky (e.g., Uber's core path), Sendil uses a "walled garden" approach : isolate a function with event-based ingress/egress, map data flows and funnels, then make tiny incremental changes. Short feedback loops build confidence for gradual migration.

4. Clarity Is the True Differentiator

The biggest gap between engineers isn't seniority but clarity . Clearly stating what you're doing and why makes collaboration efficient regardless of experience. In greenfield scenarios, alignment requires explicit goals and direction.

5. Why Experience-Driven "Muscle Memory" Can Be a Trap

People apply past patterns to new blank-slate problems. A manager's key duty is to break that inertia and encourage a fresh, broader perspective. Define the problem and constraints first, then solve — but set aside preconceived assumptions. A solution for 10M users may not fit a 2K-user problem. Adaptability within constraints distinguishes great teams.

6. MVP Trade-offs: What to Cut, What to Keep

Sendil accepts approximate latency metrics and reversible decisions (low cost to roll back). He prefers decide fast, ship, iterate on user feedback , especially in unexplored domains where real data only comes post-launch. Optimize for delivery speed while documenting assumptions for later review. Core strategy: shorten feedback loops, understand system and users, iterate continuously.

7. How High-Performance Teams Handle Growing Complexity

Post-production, make assumptions and outcomes explicit; feed data back into the system. As complexity grows, revisit architecture with the team to define optimization targets (latency, user volume, impact, wait tolerance). Continuous hypothesis validation and feedback loops are hallmarks of effective teams. When this becomes culture, managers can focus on the next layer of complexity. Without clarity on what problem you're solving, complexity explodes.

8. Hypothesis-Driven Culture Is a Shared Responsibility

Ownership of production deliveries belongs to the entire team , not just senior engineers. If a senior doesn't document assumptions, a mid-level engineer should; if no one does, the manager steps in. Every system needs an "operating manual" capturing all assumptions. Anyone pushing code must record and validate them. Sendil builds an open, evolving framework (checklists, lessons learned) that the team uses to run projects in parallel. Retrospectives feed learnings back into the framework. His mindset shifted from making every design decision to creating a framework that enables the team to operate .

9. Latency Is Overrated

Industry over-indexes on latency. In domains like payments, correctness trumps speed — showing wrong data destroys trust. Sendil prefers not showing data until it's correct , using pre-fetching and pre-loading to have data ready when the user scrolls. Chunked loading, on-demand pre-fetch/pre-load are effective. Latency optimization means getting the right dataset in context and optimizing presentation/loading.

10. The Biggest Trap in System Design

Lack of clarity is the primary failure mode. If the team doesn't know what and why , processes become dogmatic. The second trap: engineers obsessing over specific patterns/frameworks regardless of fit. Sendil recounts a Scala calendar codebase written in pure functional style — elegant but unmaintainable; it took 2.5 years to replace. He now tries to think one step ahead : what optimization, what info can I gather early? As a manager, he has broader context and uses weekly 1:1s to understand blockers, then guides: "Here's the problem; don't just reuse old patterns, think what fits now." Over time, a manager's job isn't to perfect every design but to give the team room to fail and learn .

11. Handling Strongly Opinionated Engineers

Ask the right questions: what problem, how to solve, what's the lifecycle (short-term POC vs long-term maintenance)? Optimize within existing constraints (e.g., team's Go expertise). But if the solution truly needs safety and concurrency beyond just performance, steer toward the appropriate direction — the team should be able to follow.

12. When Managers Should Set Guardrails

In the design phase, set guardrails and pave the road before the team runs. Constraints can be dynamic but define current boundaries. This speeds up delivery and ensures quality because the team works within clear limits. Pause before irreversible decisions (e.g., language choice like Rust vs Go — hard to reverse without rewrite). The manager's role is strategic: understand context, decide when to allow mistakes for learning vs when stakes are too high.

13. The Hardest Trade-off Moving from Engineer to Manager

Sendil initially insisted on coding but realized management is a completely different job ; prior "muscle memory" doesn't apply. As a senior engineer, his job was to provide solutions; as a manager, the goal is to ensure the team finds the right direction . He resists giving answers, instead asking questions to understand their reasoning. He reminds himself before meetings: "Don't give the solution, help them find it." This is the biggest, hardest shift.

14. The Real Cost of Management — and Why It's Worth It

Managers must grow others, but promotion ladders are limited. Growth becomes not about "did I do X and Y" but "am I willing to slow my own advancement to elevate others?" If you feel satisfaction when others progress and invest time in coaching, you'll be a good manager. Sendil's turning point: coaching a technically brilliant but poor communicator to senior engineer — he felt prouder than his own promotion. As a manager, recognition drops sharply ; feedback loops are long (cancelling a 30-min meeting may take months to be valued). Decisions face constant opposition; you need thick skin and patience for delayed returns.