Table of Contents
Will Larson's approach to engineering leadership emphasizes treating engineers as capable adults, applying systems thinking to complex problems, and building strategies that focus teams on what matters most.
Key Takeaways
- Engineers should be treated as capable adults who can handle real business problems rather than being coddled or sheltered from important decisions
- Systems thinking using stocks and flows helps leaders understand complex problems by modeling how things accumulate and move through organizational processes
- Engineering strategy requires honest diagnosis of current reality, guiding policies that address real constraints, and actionable steps for implementation
- The best engineering strategies are often boring but powerful - like standardizing on existing tools rather than constantly adopting new technologies
- Product managers and engineering managers should receive the same performance ratings to align their incentives and encourage collaborative problem-solving
- Measuring engineering productivity requires combining qualitative insights from talking to engineers with quantitative metrics that serve as starting points for deeper conversations
- Company values must be honest, applicable to real decisions, and reversible - if everyone would agree with a value, it's probably not useful for decision-making
- Writing consistently about topics that genuinely excite you is more sustainable than trying to create content based on what you think audiences want
Timeline Overview
- Early Career (2008-2012) — Larson starts at Yahoo during layoffs, experiences market volatility, joins Digg during failed rewrite and learns through crisis management
- Stripe Era (2012-2016) — Develops systems thinking approaches, works on incident management, implements Ruby monolith strategy, refines engineering leadership principles
- Uber Period (2016-2018) — Experiences hypergrowth hiring, manages large-scale engineering challenges, develops strategies for data center infrastructure and team scaling
- Calm/Carta Leadership (2018-Present) — Applies mature engineering leadership principles, focuses on treating engineers as peers, develops performance alignment strategies
- Writing and Books (2016-Present) — Publishes "An Elegant Puzzle" and "Staff Engineer," develops engineering strategy frameworks, prepares "The Engineering Executive's Primer"
- Current Focus (2023-Present) — Emphasizes engineering strategy, systems thinking applications, and sustainable approaches to engineering leadership and productivity
Treating Engineers as Capable Adults
One of Larson's most compelling insights challenges the widespread tendency to treat engineers like children who need protection from business realities. This paternalistic approach, while well-intentioned, actually hinders engineering teams' growth and effectiveness by preventing them from understanding the real problems they're solving.
The pattern manifests in numerous ways throughout organizations. Leaders hesitate to involve engineers in difficult conversations about priorities, timeline pressures, or business constraints. They make comments like "the engineers won't want to do that work" or shield technical teams from customer feedback and market dynamics that might inform better technical decisions.
This protective instinct often stems from the previous era of extreme engineering scarcity, when retaining technical talent at any cost became a primary management objective. Leaders learned to coddle engineers because losing team members was perceived as catastrophic, leading to organizational cultures that prioritized comfort over growth and accountability.
The current market shift provides an opportunity to return to healthier dynamics where engineers can be held to the same professional standards as other functions. This change enables putting engineers in senior leadership roles because organizations can now expect them to handle complex, ambiguous problems without constant protection.
Larson argues that engineers actually want to work on meaningful problems and understand how their work connects to broader business objectives. When sheltered from these realities, they miss opportunities to develop strategic thinking skills and make better technical decisions informed by real constraints and priorities.
The transition requires deliberate effort to include engineers in strategic discussions, share business context openly, and create accountability structures that treat technical contributions seriously. This approach respects engineers' intelligence and capability while enabling them to contribute at higher levels throughout organizations.
Successful implementation depends on consistent messaging and expectations. Leaders must resist the urge to revert to protective patterns when facing difficult decisions, instead viewing these moments as opportunities for engineers to demonstrate their ability to handle complex adult responsibilities.
Systems Thinking Framework
Larson's approach to systems thinking provides a practical framework for understanding complex organizational dynamics through the lens of stocks and flows. This methodology helps leaders move beyond surface-level symptoms to understand underlying patterns that drive organizational behavior.
The framework begins with identifying stocks - things that accumulate over time within systems. In organizational contexts, stocks might include the number of engineers on a team, the quantity of unresolved incidents, or the backlog of feature requests. These accumulations represent current state and capacity within systems.
Flows represent the movement between stocks - the processes that increase or decrease accumulated quantities. In hiring systems, flows might include sourcing rates, interview conversion rates, or offer acceptance rates. Understanding these flows helps leaders identify bottlenecks and intervention points.
The power of systems thinking emerges when leaders can model how stocks and flows interact over time. A hiring pipeline with high sourcing rates but low conversion rates suggests different problems than one with low sourcing but high conversion. The framework helps focus improvement efforts on actual constraints rather than assumed problems.
Larson emphasizes that systems thinking serves as a learning tool rather than a replacement for action. The goal is to develop better mental models of reality, not to create perfect representations that capture every variable. Models should be simple enough to be useful while complex enough to provide insight.
The framework's application extends beyond hiring to incident management, product development, and strategic planning. Any situation involving accumulation and flow can benefit from this analytical approach, providing leaders with structured ways to understand complex organizational dynamics.
Critical to successful systems thinking is maintaining humility about model limitations. When reality conflicts with models, reality is always correct. The gap between model and reality provides learning opportunities rather than evidence that reality is wrong.
Engineering Strategy Development
Larson's approach to engineering strategy builds on Richard Rumelt's framework of diagnosis, guiding policies, and actions, adapted specifically for technical organizations. This structure helps engineering leaders move beyond vague aspirations to create actionable strategies that focus teams on what matters most.
The diagnosis phase requires honest assessment of current technical and organizational constraints. This might include evaluating existing technology stacks, team capabilities, infrastructure limitations, or market pressures. Good diagnosis acknowledges uncomfortable realities rather than wishful thinking about desired future states.
Guiding policies emerge from diagnosis and dictate how organizations will address identified constraints. These policies often involve saying no to attractive options that would distract from core objectives. Effective policies feel restrictive but channel energy toward problems that matter most to organizational success.
Actions represent specific implementations of guiding policies. Without concrete actions, strategies remain theoretical exercises that don't change organizational behavior. Larson emphasizes that actions must be specific enough to guide decision-making and resource allocation.
The best engineering strategies often appear boring because they establish constraints that focus effort rather than expanding possibilities. Strategies like "we only use our existing technology stack" or "we run everything in our own data centers" may frustrate engineers who want to explore new technologies, but they prevent resource fragmentation.
Strategy development requires understanding that good strategies disappoint some stakeholders. The goal is not to make everyone happy but to optimize for organizational effectiveness given real constraints. This requires courage to make unpopular decisions that serve broader objectives.
Regular strategy review and adjustment ensures that policies remain relevant as conditions change. Markets shift, technologies evolve, and organizational capabilities develop, requiring periodic reassessment of strategic assumptions and priorities.
Practical Engineering Strategy Examples
Larson provides concrete examples of effective engineering strategies from his experience at major technology companies, illustrating how strategic constraints can drive organizational focus and effectiveness.
At Uber, the strategy of running everything in company-owned data centers rather than using cloud providers seemed limiting but enabled rapid international expansion. When entering China, the team could establish operations in three months because they weren't constrained by cloud provider availability or geopolitical restrictions.
The strategy required significant investment in infrastructure and operations capabilities that cloud providers might have handled more efficiently. However, this investment paid off in operational flexibility and the ability to quickly enter and exit markets based on business needs rather than technical constraints.
Stripe's Ruby monolith strategy provides another example of strategic constraint driving focus. Rather than allowing teams to adopt different programming languages and frameworks, the company standardized on a single technology stack that enabled knowledge sharing and reduced operational complexity.
This strategy frustrated some engineers who wanted to explore new technologies, but it focused the engineering organization on building innovative features for customers rather than maintaining diverse technology ecosystems. The constraint enabled faster development and easier knowledge transfer between teams.
Carta's "standard kit" approach exemplifies how boring strategies can be highly effective. By explicitly defining approved technologies and requiring justification for exceptions, the company prevents the proliferation of tools that would fragment expertise and increase operational overhead.
These examples demonstrate that effective engineering strategy often involves choosing limitations that enable focus. Rather than trying to optimize for every possible scenario, successful strategies accept constraints that channel energy toward problems that matter most to business success.
The key insight is that constraints are not necessarily limitations but can be enablers of effectiveness. By removing certain choices, strategies free teams to focus on problems that truly matter rather than constantly debating tool selection and technology adoption.
PM-EM Relationship Alignment
Larson addresses one of the most persistent challenges in technology organizations: the frequent tension between product managers and engineering managers. His approach focuses on understanding underlying causes rather than treating symptoms of poor collaboration.
The most common problem involves misaligned incentives where product managers optimize for different outcomes than engineering managers. Product managers might prioritize feature delivery and customer impact while engineering managers focus on technical excellence and team satisfaction, creating natural tension in resource allocation decisions.
Larson's solution involves giving product managers and engineering managers the same performance ratings, forcing them to succeed or fail together. This alignment ensures that both roles optimize for shared outcomes rather than competing for different objectives that might conflict.
The approach requires careful implementation to avoid punishing individuals for their counterparts' clear performance failures. When one person demonstrates obvious incompetence, the other shouldn't be penalized. However, in most cases where execution struggles, both roles contribute to problems and both can contribute to solutions.
Before attempting to resolve conflicts, Larson recommends that both parties deeply understand each other's actual needs and constraints. Many apparent conflicts dissolve when people move beyond surface-level positions to understand underlying concerns and requirements.
The framework extends beyond individual relationships to team dynamics. When product and engineering leaders consistently work together to solve problems rather than advocating for their functional areas, teams develop more collaborative cultures and achieve better outcomes.
Success requires executive support for shared accountability. Leaders must model collaborative behavior and resist the temptation to side with one function over another when conflicts arise. This consistent messaging reinforces the importance of joint problem-solving.
Measuring Engineering Productivity
Larson's approach to measuring engineering productivity acknowledges both the importance of measurement and the limitations of purely quantitative approaches. His framework combines qualitative insights with quantitative metrics to provide actionable guidance for engineering leaders.
The foundation of productivity measurement involves regularly talking to engineers about their effectiveness and obstacles. Engineers generally know whether their teams are performing well and can identify specific problems that impede progress. This qualitative feedback provides context that metrics alone cannot capture.
Quantitative metrics serve as starting points for deeper conversations rather than definitive productivity measures. The DORA metrics (lead time, deployment frequency, failure rate, and recovery time) provide useful diagnostic information but don't determine whether teams are working on valuable problems.
Larson emphasizes aligning engineering evaluation with business and product goals rather than purely technical metrics. Engineering organizations exist to support product development and customer value creation, not to optimize technical metrics in isolation from business objectives.
The most powerful productivity indicator involves demonstrating meaningful accomplishments over specific time periods. Teams that can show substantial, impactful work completed in recent months generally indicate healthy productivity, while teams struggling to populate such lists may have underlying issues.
Measurement conversations should focus on education rather than evaluation. When stakeholders ask about metrics, leaders should use these opportunities to explain the nuances of engineering work and help non-technical stakeholders understand the complexities involved in software development.
The key insight is that measurement serves diagnosis rather than judgment. Metrics help identify areas for improvement and guide resource allocation decisions, but they shouldn't be used to rank or compare teams working on different problems with different constraints.
Company Values Framework
Larson's approach to company values emphasizes practicality over inspiration, focusing on creating guidelines that actually influence decision-making rather than serving as aspirational statements that everyone ignores.
The first requirement for useful values is honesty - companies must actually operate according to their stated values. Values that conflict with observed behavior undermine credibility and create cynicism among employees who notice the disconnection between rhetoric and reality.
Values must be applicable to real decisions that teams face regularly. Generic statements like "we build good software" or "we care about customers" don't provide guidance for choosing between alternatives. Effective values help people make specific choices when facing competing priorities.
The reversibility test ensures values are meaningful by confirming that reasonable companies might choose different approaches. If every company would agree with a value, it's probably not useful for decision-making. Values should distinguish companies and guide unique approaches to common problems.
Larson warns against identity values that describe who companies want to be rather than who they actually are. These aspirational statements feel good during executive discussions but don't help teams make difficult choices because they're not grounded in organizational reality.
The framework extends beyond value creation to value maintenance. Companies must regularly assess whether their values remain relevant as they grow and change. Values that worked for early-stage startups may not serve larger organizations facing different challenges.
Implementation requires consistent reinforcement through hiring, promotion, and resource allocation decisions. Values that aren't reflected in these critical organizational processes become meaningless rhetoric rather than operational guidance.
Sustainable Content Creation
Larson's approach to writing and content creation emphasizes sustainability over short-term optimization, focusing on intrinsic motivation rather than external validation or monetary rewards.
The foundation of sustainable content creation involves writing about topics that genuinely excite the author rather than trying to anticipate audience preferences. This approach enables long-term consistency because authors maintain energy and interest over extended periods.
Larson recommends focusing on subjects directly related to current work, allowing writing to serve dual purposes of skill development and content creation. This alignment reduces time pressure and creates natural material for discussion and analysis.
The biggest risk to content creation is quitting too soon rather than growing too slowly. Building audiences requires patience and consistency over years rather than months. Authors who focus on sustainable practices outperform those who optimize for immediate growth.
Quality matters more than quantity for establishing credibility and building audiences. Larson suggests that people focused on career advancement should write two or three excellent pieces rather than maintaining regular publishing schedules. Deep, thoughtful work has more lasting impact than frequent shallow content.
The framework emphasizes publishing regularly rather than perfecting content indefinitely. Authors who maintain high standards for publication often end up with hundreds of unpublished drafts rather than building audiences through consistent output.
Success requires ignoring critics and feedback that doesn't contribute to improvement. The internet provides unlimited opportunities for unproductive conflict and debate. Authors should focus on constructive feedback from trusted sources rather than defending their work against random criticism.
The Digg Rewrite Failure
Larson's experience with the Digg version 4 rewrite provides a cautionary tale about the dangers of complete system rewrites and the importance of incremental improvement. The project demonstrates how heroic efforts can temporarily mask fundamental strategic problems.
The decision to rewrite Digg completely stemmed from recognition that the platform was losing ground to social networks and needed social functionality that the existing system couldn't support. This strategic assessment was correct, but the chosen solution created more problems than it solved.
The rewrite consumed enormous resources and time while providing no incremental value to users during development. When the system finally launched, it failed catastrophically, requiring a month of intensive work to restore basic functionality. The technical failure overshadowed any potential product improvements.
Larson and his team demonstrated remarkable persistence in getting the system working despite overwhelming technical challenges. They wrote caching systems from scratch, diagnosed obscure bugs, and maintained functionality through manual restarts and heroic efforts.
The experience illustrates that technical execution excellence cannot overcome fundamental strategic problems. Despite successfully launching the rewritten system, Digg continued declining because the underlying business model and market position remained problematic.
The failure provided valuable learning opportunities for everyone involved. Larson gained management experience and technical skills that shaped his entire career, demonstrating how challenging experiences can provide disproportionate growth opportunities.
The story reinforces the importance of incremental improvement over revolutionary change. While complete rewrites occasionally succeed, they represent extremely high-risk approaches that typically fail to deliver promised benefits while consuming massive resources.
Will Larson's engineering leadership philosophy emphasizes treating engineers as capable professionals who can handle complex business problems while applying systematic thinking to organizational challenges. His approach to strategy, measurement, and team management provides practical frameworks for building effective engineering organizations. The emphasis on honesty, applicability, and sustainability runs through all aspects of his leadership approach, from defining company values to creating content. His experience across multiple high-growth companies demonstrates that consistent application of these principles can drive both technical excellence and business success.
Conclusion
Will Larson's engineering leadership approach demonstrates that the most effective technical organizations treat engineers as capable adults who can handle complex business problems while applying systematic thinking to organizational challenges. His frameworks for strategy development, productivity measurement, and team alignment provide practical guidance for building sustainable engineering cultures that balance technical excellence with business impact.
Practical Implications
- Stop treating engineers like children - Include technical team members in strategic business discussions and hold them accountable for outcomes rather than protecting them from difficult decisions
- Apply systems thinking to complex problems - Model organizational challenges using stocks and flows to identify actual bottlenecks rather than assumed problems
- Develop boring but effective strategies - Create constraints that focus teams on what matters most rather than trying to optimize for every possible scenario
- Align PM and EM incentives - Give product managers and engineering managers the same performance ratings to encourage collaborative problem-solving
- Combine qualitative and quantitative measurement - Talk to engineers regularly about effectiveness while using metrics as starting points for deeper conversations
- Create honest and applicable values - Ensure company values reflect actual behavior and help teams make specific decisions between competing alternatives
- Focus on sustainable content creation - Write about topics that genuinely excite you rather than trying to anticipate audience preferences
- Prioritize incremental improvement - Avoid complete system rewrites in favor of gradual improvements that provide continuous value
- Understand underlying needs in conflicts - Dig deeper than surface-level positions to find compromise solutions that address everyone's actual requirements
- Build strategy from honest diagnosis - Start with accurate assessment of current reality rather than aspirational thinking about desired future states
- Standardize on existing tools - Resist the urge to constantly adopt new technologies in favor of maximizing value from current systems
- Show meaningful accomplishments - Demonstrate productivity through substantial work completed rather than optimizing technical metrics in isolation
- Maintain energy through selective focus - Choose projects and topics that energize rather than drain to sustain long-term effectiveness
- Use constraints as enablers - View limitations as opportunities to focus effort rather than obstacles to overcome
- Invest in relationship alignment - Spend time understanding team dynamics and incentive structures before trying to solve execution problems
