Visual summary of operating lessons from Sebastian Barrios.

Lessons from Sebastian Barrios

Sebastian Barrios is the SVP of Engineering at Roblox and the former VP of Technology at Mercado Libre, where he grew the engineering team to nearly 20,000 developers. He favors fast-shipping cultures driven by an unusually low ratio of product managers to engineers. This profile covers his approach to executive communication, handling massive deployment volumes, and building platforms that accelerate development.

Part 1: The "State of Me" and Executive Communication

  1. On the purpose of the "State of Me": "I use a weekly email format called the 'State of Me' to update the CEO on what I've accomplished, what is next, and where I need help." — Source: [Business Insider]
  2. On freeing up calendar time: "Sending a structured weekly update eliminates the need to spend the first half of a one-on-one meeting giving status reports." — Source: [Lenny's Podcast]
  3. On strategic discussions: "When your manager already knows your status, your sync time can actually be used for long-term strategy and problem-solving." — Source: [Lenny's Podcast]
  4. On vulnerability in leadership: "The 'State of Me' explicitly includes a section on where I need help, which normalizes asking for support at the executive level." — Source: [Business Insider]
  5. On consistency: "The value of a weekly update isn't in a single email; it is the compounding context you build with your manager over months." — Source: [Business Insider]
  6. On written culture: "Writing down what you did forces you to evaluate whether you actually spent your week on the right priorities." — Source: [Lenny's Podcast]
  7. On upward management: "Your CEO is managing a massive context load. Structuring your updates makes it easier for them to unblock you." — Source: [Business Insider]
  8. On reducing operational drag: "Fewer status meetings means more deep work blocks for both the executive and the engineering teams." — Source: [Lenny's Podcast]
  9. On self-reflection: "Drafting the 'State of Me' acts as a weekly forcing function to review my own calendar and audit my focus." — Source: [Business Insider]
  10. On asynchronous alignment: "As organizations scale across time zones, asynchronous alignment tools like the weekly update become a requirement, avoiding the need for endless coordination meetings." — Source: [Lenny's Podcast]

Part 2: Empowering Engineering Over Traditional PM Models

  1. On PM-to-Engineer ratios: "At Mercado Libre, we operated with significantly fewer Product Managers, around 5% compared to the industry standard of 20 to 30%." — Source: [Lenny's Podcast]
  2. On product-minded engineers: "When you have fewer PMs, you are forced to hire and develop engineers who have strong product intuition." — Source: [Lenny's Podcast]
  3. On accountability: "Giving engineers direct ownership over the product outcome prevents the dynamic where PMs dictate what to build and engineers simply write the code." — Source: [Lenny's Podcast]
  4. On speed of execution: "Removing a layer of translation between the product requirement and the engineering implementation dramatically speeds up shipping." — Source: [Lenny's Podcast]
  5. On customer proximity: "Engineers should be looking directly at user metrics and feedback, rather than receiving it filtered through a product organization." — Source: [Lenny's Podcast]
  6. On organizational friction: "Too many PMs can sometimes lead to a feature factory, where teams build things to justify the roadmap rather than solving core problems." — Source: [Lenny's Podcast]
  7. On hiring criteria: "We screen engineering candidates for both technical depth and their ability to understand why a feature matters to the end user." — Source: [Lenny's Podcast]
  8. On autonomous pods: "A low-PM environment works best when engineering teams are organized into small, highly autonomous pods with clear business metrics." — Source: [Lenny's Podcast]
  9. On scaling the model: "As you add thousands of developers, keeping the PM ratio low forces the organization to rely on strong platform infrastructure rather than manual coordination." — Source: [Lenny's Podcast]

Part 3: Managing Extreme Scale and Deployment Volume

  1. On deployment velocity: "Managing 30,000 code deployments a day requires an infrastructure that assumes things will break and optimizes for instant recovery." — Source: [QCon SF]
  2. On trust and tooling: "You cannot maintain that volume of daily deploys without trusting your developers and giving them the tooling to test their own code safely." — Source: [Lenny's Podcast]
  3. On blast radius: "The key to continuous deployment at scale is containing the blast radius of any single failure so the broader platform remains stable." — Source: [QCon SF]
  4. On deployment anxiety: "We intentionally engineered our CI/CD pipelines so that pushing code to production feels boring and routine rather than nerve-wracking." — Source: [QCon SF]
  5. On the cost of bottlenecks: "Any manual approval step in a release process becomes an impossible bottleneck when you have thousands of engineers shipping simultaneously." — Source: [QCon SF]
  6. On observability: "High deployment frequency is only responsible if your observability tools can detect an anomaly and trigger an automatic rollback within seconds." — Source: [QCon SF]
  7. On continuous integration: "If code sits on a branch for more than a day, it becomes a liability. We optimize for small, continuous merges." — Source: [Lenny's Podcast]
  8. On system resilience: "A system's resilience is tested by how quickly it absorbs and recovers from bad deployments, not by how perfectly it prevents them." — Source: [QCon SF]
  9. On developer freedom: "When infrastructure handles the safety checks automatically, developers have the freedom to experiment and iterate in production." — Source: [QCon SF]

Part 4: Platform Engineering and GenAI Development

  1. On the purpose of internal platforms: "A good internal developer platform abstracts away infrastructure complexity so engineers can focus purely on business logic." — Source: [QCon SF]
  2. On deploying GenAI: "Rolling out Generative AI across a massive company requires treating AI capabilities as core platform primitives, rather than standalone tools." — Source: [QCon SF]
  3. On AI governance: "When you build a GenAI platform for over 60,000 employees, you have to build governance and privacy controls directly into the foundational layer." — Source: [QCon SF]
  4. On platform adoption: "You cannot mandate the use of an internal platform. It has to provide an experience that is so superior that developers choose to use it voluntarily." — Source: [QCon SF]
  5. On lowering the barrier to AI: "By embedding ML models into our platform services, we allowed frontend and backend engineers to utilize AI without needing to become machine learning experts." — Source: [QCon SF]
  6. On standardizing architecture: "Platform engineering is how you enforce architectural standards at scale without acting as a gatekeeper." — Source: [QCon SF]
  7. On self-service capabilities: "The metric for platform success is how many end-to-end tasks a product team can complete without ever submitting a Jira ticket to DevOps." — Source: [QCon SF]
  8. On iteration cycles: "Building a platform for GenAI meant we had to iterate our internal tools as rapidly as the underlying foundation models were evolving." — Source: [QCon SF]
  9. On managing technical debt: "Centralizing core services in a platform prevents distinct product teams from redundantly solving the same infrastructure problems and accumulating parallel technical debt." — Source: [QCon SF]
  10. On AI as a force multiplier: "We view GenAI as a development multiplier that accelerates how our own engineers write, review, and test code." — Source: [QCon SF]

Part 5: Navigating Massive Organizational Growth

  1. On hyper-growth challenges: "Scaling an engineering organization from 2,000 to over 12,000 people breaks every process you relied on when you were smaller." — Source: [QCon SF]
  2. On onboarding: "When you are adding hundreds of engineers a month, your onboarding documentation and environment setup must be flawless." — Source: [QCon SF]
  3. On communication breakdown: "The biggest risk in scaling a team by 5x is that context gets lost. You have to over-communicate the company strategy constantly." — Source: [Lenny's Podcast]
  4. On organizational design: "We structure teams to minimize cross-team dependencies. If one team cannot ship without waiting for another, growth stalls." — Source: [QCon SF]
  5. On maintaining culture: "Culture doesn't scale automatically. It requires deliberate reinforcement by leadership at every all-hands and in every architectural review." — Source: [QCon SF]
  6. On engineering levels: "As we grew, we had to define very clear, objective expectations for what constitutes a junior, senior, and staff engineer to ensure fairness." — Source: [QCon SF]
  7. On avoiding bureaucracy: "You have to fight the natural drift toward bureaucracy by regularly auditing and deleting processes that no longer serve a clear purpose." — Source: [QCon SF]
  8. On leadership scaling: "The hardest transition for an engineering leader is moving from managing technical output to managing the managers who oversee the output." — Source: [Lenny's Podcast]
  9. On the danger of silos: "Massive growth creates the risk of engineering silos. We counter this by enforcing company-wide technical standards through our internal platform." — Source: [QCon SF]

Part 6: Fostering an Entrepreneurial Engineering Culture

  1. On founder mentality: "We want engineers to act like founders of their own domains, making decisions based on business impact rather than technical elegance alone." — Source: [Startupeable]
  2. On calculated risk: "An entrepreneurial culture requires an environment where it is safe to take calculated risks and fail, provided the lessons are documented and shared." — Source: [Lenny's Podcast]
  3. On execution speed: "Startups win on speed. Even at the scale of Mercado Libre or Roblox, we try to maintain the urgency of a seed-stage company." — Source: [Startupeable]
  4. On problem solving: "Don't bring me an interesting technical puzzle; bring me a solution that directly moves a metric the customer cares about." — Source: [Startupeable]
  5. On resource constraints: "Constraints breed creativity. Sometimes giving a team fewer resources forces them to build a more elegant, focused solution." — Source: [Startupeable]
  6. On hiring former founders: "I actively look for former founders to join engineering teams because they possess an inherent bias toward action and business reality." — Source: [Startupeable]
  7. On breaking rules: "When a process gets in the way of shipping an urgent update, teams should feel empowered to bypass the process and address the fallout later." — Source: [Lenny's Podcast]
  8. On identifying opportunity: "An entrepreneurial engineer doesn't wait for a roadmap; they look at the data, spot an inefficiency, and build a prototype to fix it." — Source: [Startupeable]
  9. On ownership: "The difference between a good engineer and a great one is the willingness to own the product's success in the market, rather than only focusing on code stability." — Source: [Lenny's Podcast]

Part 7: Lessons from Founding Yaxi and Cabify

  1. On identifying markets: "Founding Yaxi in Mexico taught me the importance of building solutions tailored specifically to the realities of local markets, rather than copying a US model." — Source: [Endeavor]
  2. On acquisitions: "Transitioning from founder to a CTO role post-acquisition requires you to shift your ego from building your own company to serving a shared mission." — Source: [Endeavor]
  3. On operational complexity: "Ride-sharing is fundamentally a logistical challenge disguised as a software problem. The code is useless if the real-world operations fail." — Source: [Startupeable]
  4. On early-stage scaling: "When we were scaling Cabify, the biggest technical hurdle was refactoring systems built for one city to handle the asynchronous demands of a dozen different countries." — Source: [Startupeable]
  5. On the value of agility: "In a hyper-competitive space like ride-hailing, the company that can iterate its dispatch algorithm the fastest usually captures the market." — Source: [Startupeable]
  6. On technical debt in startups: "Early on, you accumulate technical debt intentionally to survive. The skill of a CTO is knowing exactly when that debt must be paid down before it kills the company." — Source: [Startupeable]
  7. On user trust: "In any platform involving physical transportation or payments, reliability is your primary feature. If the app drops during a ride, you lose the user's trust permanently." — Source: [Startupeable]
  8. On market consolidation: "The acquisition of Yaxi by Cabify showed that in certain industries, regional consolidation is the only viable path to achieving sustainable scale." — Source: [Endeavor]
  9. On transitioning technologies: "Moving from a scrappy startup architecture to a regional enterprise system required us to completely rethink our approach to database scaling and service isolation." — Source: [Startupeable]

Part 8: Mentorship and Early Career Lessons

  1. On early validation: "Receiving a personal phone call from Steve Jobs as a teenager regarding an app I built permanently altered my perspective on what was possible." — Source: [Lenny's Podcast]
  2. On the Endeavor network: "Being selected as the youngest-ever Endeavor Entrepreneur at 22 showed me the incredible compounding value of having access to experienced mentors early in your career." — Source: [Endeavor]
  3. On giving back: "I dedicate time to mentoring other founders because the guidance I received when I was struggling to scale my first startup was the only reason we survived." — Source: [Endeavor]
  4. On age and leadership: "Leadership is a function of execution and clarity, not age. If you can deliver results and communicate effectively, people will follow you regardless of your birth year." — Source: [Forbes]
  5. On continuous learning: "The half-life of technical knowledge is incredibly short. The only sustainable advantage an engineer has is the velocity at which they can learn a new paradigm." — Source: [Startupeable]
  6. On taking big swings: "Being featured on lists like Forbes 30 Under 30 is a byproduct of taking disproportionately large professional risks and executing on them." — Source: [Forbes]
  7. On feedback loops: "The best mentors don't give you the answers; they tighten your feedback loop so you can realize you are making a mistake faster." — Source: [Endeavor]
  8. On imposter syndrome: "Everyone dealing with extreme scale feels like they are making it up as they go. The trick is to build systems that catch you when you fall." — Source: [Lenny's Podcast]
  9. On building talent: "My proudest professional achievements are the junior engineers I've hired who are now CTOs of their own companies." — Source: [Startupeable]
  10. On the long game: "Technology changes rapidly, but the fundamentals of building high-trust teams, maintaining clear communication, and obsessing over the user remain exactly the same." — Source: [Lenny's Podcast]