In Praise of 'Normal' Engineers

TL;DR / Abstract

The pursuit of the "10x engineer" is a fallacy. High-performing organizations are not built by hiring mythical individuals, but by architecting a sociotechnical system where teams of "normal" engineers are empowered to consistently deliver extraordinary results.

Core Problem / Challenge

What specific problem or set of challenges is being addressed in this article?

• The tech industry's persistent and harmful myth of the "10x engineer" promotes toxic hiring practices and ignores the systemic nature of performance.
• It wrongly frames productivity as an individual attribute, when in reality, the team is the smallest unit of software ownership and delivery.
• This focus on individual heroics lets leadership off the hook for their actual job: building an environment that multiplies the effectiveness of the entire team.

Key Solutions & Concepts Presented

What are the primary solutions, mental models, or architectural patterns presented? Use Wiki Links for concepts.

Core Philosophy

• Team Software Ownership: Shift focus from individual output to team efficacy. The team, not the person, owns the entire software lifecycle. An individual owning a critical service is a bug, not a feature.
• 10x Engineering Teams: Stop hunting for 10x engineers. Start building the environment that creates 10x teams.
• Sociotechnical Systems Design: Design systems for normal humans—accounting for cognitive biases, fatigue, and stress—not for idealized, infallible robots.

The Three-Pillar Framework for 10x Teams

Pillar 1: Accelerate Flow & Feedback

• Fast Feedback Loops: Radically shorten the commit-to-deploy interval. This is the central feedback loop of development. Avoid the "deploy death spiral" where slow deploys lead to batching changes, which increases risk and slows things down further.
• DORA Metrics: Use Deployment Frequency, Lead Time for Changes, MTTR, and Change Failure Rate as vital signs for the health of the delivery system.

Pillar 2: Reduce Cognitive Load

• Platform as a Product: Treat the internal developer platform as a first-class product with your developers as its customers. Prioritize Developer Experience (DevEx).
• Team Topologies: Structure teams (e.g., Platform, Stream-Aligned) to explicitly manage and reduce the cognitive load on developers, allowing them to focus on business value.
• Paved Roads: Use platform engineering to create well-lit, easy-to-use "paved roads" for shipping code, making the right way the easiest way.

Pillar 3: Cultivate Psychological Safety

• Blameless Culture: Treat failures as system problems, not people problems. Mandate blameless postmortems to turn every incident into a high-leverage learning opportunity.
• Error Budgets: Quantify acceptable risk, giving teams explicit permission to innovate and deploy without fear, as defined in SRE principles.
• Safe to Fail: Make recovery from failure trivial. Fast, easy, and thoughtless rollbacks are a critical safety mechanism that encourages experimentation.

Memorable Quotes

Extract 1-2 direct, impactful quotes that capture a key insight. Attribute them to the speaker.

"The smallest unit of software ownership and delivery is the engineering team. It doesn't matter how fast an individual engineer can write software, what matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own." - Charity Majors

"When your systems are designed to be used by normal engineers, all that excess brilliance they have can get poured into the product itself, instead of wasting it on navigating the system itself." - Charity Majors

"It is engineering’s job to own their code in production. It is management’s job to make sure it doesn’t suck." - Charity Majors

Connecting to My Existing Knowledge

How does this new information interact with my existing notes?

• This framework directly applies the measurement philosophy from Accelerate - Jez Humble Gene Kim Nicole Forsgren, using DORA Metrics as the key indicators for the Flow & Feedback pillar.
• It operationalizes the concept of Error Budgets from the Site Reliability Engineering - Betsy Beyer Chris Jones Jennifer Petoff Niall Richard Murphy book, making it a cornerstone of Psychological Safety.
• The focus on Cognitive Load Reduction provides a powerful "why" for the organizational patterns described in Team Topologies, particularly the Platform Team's role in serving Stream-Aligned teams.
• It reframes the Staff Engineer role from The Staff Engineer's Path - Tanya Reilly as less of a lone superstar and more of a "team force multiplier" who architects these effective systems.

Actionable Ideas & Open Questions

What should I do or think about next?

System Health Check

• Flow Audit: Measure our core DORA Metrics. What is the real lead time for a single line of code to reach production?
• Cognitive Load Audit: Survey developers: "What is the most draining or frustrating part of your day-to-day workflow?" Identify key sources of friction.
• Safety Audit: Analyze on-call health. Are alerts actionable? Are rotations sustainable? Do our postmortems drive meaningful, tracked improvements?
• Ownership Audit: Map our critical services. Can we identify any systems owned by an individual instead of a team?

Potential Strategic Initiatives

• Champion a Platform as a Product mindset for our internal tooling, including creating developer feedback channels.
• Define and implement Error Budgets for one critical service to pilot the concept.
• Formalize the Blameless Postmortems process, ensuring action items are always captured and prioritized.
• Review hiring rubrics to ensure we're optimizing for team multipliers, not just individual technical skill.

Open Questions

• How would we design our observability dashboards specifically for a "tired human at 3 a.m."?
• What is the smallest, most impactful "paved road" we could build for our teams right now?
• What are the early warning signs that a platform team is becoming a bottleneck instead of an enabler?