5 Things World-Class Engineers Do That You Don't

Steve Huynh · article · 2026-07-01 source ↗ Reader 🖥️

Career Development Feedback Loops Informal Leadership Performance Psychology Software Design Fundamentals SRE & Incident Response

Elite engineers are distinguished not by raw intelligence or effort but by five deliberate practices the author claims to have observed repeatedly across podcast conversations with principal/distinguished engineers: measuring growth monthly rather than waiting for reviews, amplifying colleagues instead of maximizing solo output, absorbing complexity so customers experience simplicity, deliberately avoiding the crowded competitive path, and converting personal failures into institutional lessons.

practical · mixed — Practical/argumentative: each of the five sections argues 'you should do X.' The argumentative core is thin and rests almost entirely on narrative — a single named anecdote per point, drawn from the author's podcast guests, followed by a generic 'what most people do / do this instead' template. It reads as testimonial evidence dressed as pattern-recognition.

Structure

Part	Role
Framing intro: the author's podcast gives him unusual access to principal/distinguished engineers, from which he claims to have 'recognized a handful of patterns that have held over the decades and across different companies.'	context / credibility claim
Point 1 (Kun Chen, Carlos Arguelles): measure growth on a monthly cadence, tracking new capability rather than accumulated knowledge, because knowledge decays and annual/promotion-based feedback is lagging.	evidence via testimonial anecdote + prescriptive template
Point 2 (Michael Novati): individual throughput ('coding machine') has a ceiling; growth past it comes from amplifying others, illustrated by Novati organizing a company-wide code health summit.	evidence via testimonial anecdote + prescriptive template
Point 3 (Christopher Brown, Bezos/EC2/S3 anecdote): the best engineers absorb internal complexity so the customer-facing interface stays simple ('packaged engineering').	evidence via testimonial anecdote + prescriptive template
Point 4 (Philip Su, Kun Chen at Bing): being as smart/hardworking as peers only makes you average; differentiation requires finding a non-consensus problem nobody else is working.	evidence via testimonial anecdote + prescriptive template
Point 5 (Carlos Arguelles, Amazon Black Friday outage / TPSGenerator): elite engineers turn their worst failures into infrastructure or process that protects everyone, and the story told about the failure-then-fix matters for career growth.	evidence via testimonial anecdote + prescriptive template
Closing: 'none of these 5 things come down to raw talent, intelligence, or hard work' + call to action to pick the one that 'stung' and start there.	conclusion / call to action

Key terms

coding machine
Novati's self-description of his early career mode: keeping the whole codebase in his head and shipping at a volume almost nobody could match, purely through solo output.
packaged engineering
Christopher Brown's term for what AWS sells: complexity absorbed and hidden by the provider so the customer-facing interface (e.g. 'get object, put object') stays simple.
the story
Carlos Arguelles's claim that career growth and organizational buy-in depend on how a failure-then-fix is narrated ("we skipped the test and caused an outage... we built the infrastructure and prevented the next one"), not only on the underlying engineering work.

Propositions

explicitcorroboratedElite engineers evaluate their own growth on a monthly (or shorter) cadence — asking 'what could I do this month that I couldn't do last month' — rather than waiting for an annual review or promotion to reveal whether they are growing.conf: high
supports ←SWLW #711: The laws of this world (game theory), Should you still become a Software Engineer in 2026, and more. · p7 — Digest blurb restates the source piece's first practice (monthly growth check vs. annual review) verbatim in substance.
explicitSpecific technical knowledge decays in value over time, so the object worth tracking each period is a new applied capability, not accumulated facts.conf: high
explicitIndividual output has a hard ceiling, so engineers who want to progress past a certain level must shift effort from personal throughput to amplifying the people around them.conf: high
explicitThe best engineers treat internal system complexity as their own problem to absorb, so the person on the other side of the interface experiences something simple ('packaged engineering').conf: high
extendsIt Ain't Broke: Why Software Fundamentals Matter More Than Ever · p11 — Christopher Brown's 'packaged engineering' (absorb internal complexity, expose a simple customer interface) is the same principle as Ousterhout's deep modules (simple interface, complex implementation), applied one level up — to a product/customer-facing API rather than a code module.
explicitMatching peers on intelligence and effort only makes an engineer average; differentiation requires deliberately working on a non-consensus problem or bet that others are not competing over.conf: high
explicitWhat separates elite engineers after a serious failure is not avoiding blame but converting the failure into infrastructure, tooling, or process that prevents the same failure for everyone else.conf: high
implicitCareer growth and organizational credit depend substantially on how a person narrates their work — the story told about a failure-then-fix — not only on the underlying engineering merit.conf: medium
implicitcontestedA small number of self-reported practices, elicited retrospectively from already-elite engineers in interview form, are sufficient evidence to prescribe those practices as causally productive for any reader who wants to become elite.conf: high
contradictsHow to Turn Individual Talent into Organizational Excellence · p1 — Huynh's article diagnoses elite performance as a set of individual habits/traits; this HBR piece explicitly argues sustained excellence comes from systems (talent, team, routine woven together), not individual brilliance, and that leaders who diagnose performance as an individual problem default to an ineffective playbook.

Arguments

You should measure your own growth monthly (or on an even shorter loop) rather than annually. strength: low

Explicit premises:

Annual/promotion-based feedback is a lagging indicator of whether you are growing.
Specific technical knowledge decays in value, so growth must be re-earned continuously.
Two named elite engineers (Kun Chen, Carlos Arguelles) independently report using a monthly or shorter self-check.

Implicit premises:

Self-reported retrospective practice from successful people reliably identifies the cause of their success rather than being a post-hoc story they tell about it.
A practice two people say they use generalizes as a prescription for readers who are not at E7/partner/senior-principal level.
Consciously naming a new monthly capability is itself sufficient to produce durable career growth, independent of context, luck, or what work is available to apply it to.

Inferences:

If knowledge decays and growth requires monthly-visible new capability, then someone who cannot name a new capability this month is, by the article's own logic, not growing — but the article gives no account of false negatives (people who are growing in ways not reducible to a monthly-nameable skill).

You should route more of your work through other people instead of maximizing personal throughput. strength: medium

Explicit premises:

Novati hit a ceiling as a 'coding machine' and only advanced further after broadening his influence (organizing a cross-team code health summit).
Helping people is a 'win-win-win': the helped person grows, the company benefits, and the helper gets credit for output beyond their own hands.

Implicit premises:

Formal promotion criteria at Novati's employer (Meta) reward visible cross-team influence, and this generalizes to other organizations and levels.
The counterfactual — Novati NOT organizing the summit — would have left him capped, rather than some other unobserved factor (timing, sponsorship, org need) being the actual cause of his promotion.

Inferences:

Taken to its logical end, this argument implies coding output itself is a subordinate good once past entry level — a claim the article asserts but never qualifies against contexts (e.g. small teams, ICs by choice) where deep solo output remains the primary value driver.

You should absorb complexity yourself so the people you serve get a simple interface ('packaged engineering'), rather than exposing internal complexity and calling it transparency. strength: medium

Explicit premises:

Bezos reportedly rejected an early, complicated S3/EC2 design in favor of a simple 'get object, put object' interface.
AWS's commercial success is built on hiding operational complexity from customers.

Implicit premises:

What worked for a hyperscale cloud product interface (S3/EC2) generalizes as a universal engineering principle at any scale of system or team.
'Exposing complexity' and 'calling it transparency' are the same failure mode — the article does not distinguish between legitimate transparency (e.g., for debuggability, for informed consent) and simply failing to do the design work of simplification.

Inferences:

This is structurally the same claim as the software-design principle that a module's value lies in a small interface hiding a large, complex implementation (deep modules) — the article rediscovers a known design principle via a business anecdote rather than engineering theory, but the underlying claim is genuinely mechanistic, not vague.

You should deliberately seek out a non-consensus problem or bet rather than competing with peers on the same, obvious work. strength: low

Explicit premises:

Philip Su: being equally smart and hardworking as everyone else makes you average, not exceptional.
Kun Chen built an unrequested tool at Bing (letting the search team see click data) that carried his first promotions, instead of working only the assigned roadmap.

Implicit premises:

'Average' among a pool of highly capable peers at Microsoft/Meta is a meaningful, bad outcome to avoid — a framing that assumes a scarce, competitive, up-or-out promotion ladder as the default backdrop for all engineering careers.
Choosing unclaimed problems is a reliably available strategy, rather than something contingent on slack time, managerial tolerance, or being senior enough to get away with unsanctioned work.

Inferences:

If everyone follows this advice, the 'non-consensus' space becomes contested too — the strategy is partly self-defeating at scale, which the article does not address.

You should turn your worst failures into infrastructure or process that protects the whole team/org, and tell that story, rather than quietly patching your own code. strength: medium

Explicit premises:

Carlos Arguelles skipped load testing before Black Friday, caused an 8-hour outage, and instead of being fired was told by his director to prevent recurrence.
He built generic load-testing infrastructure (TPSGenerator) now used across Amazon/AWS.
Carlos: career growth depends on 'the story that you tell,' and his own interviewing philosophy rewards what candidates did after failure, not whether they failed.

Implicit premises:

A blameless-postmortem culture (director asking 'how are you going to prevent this' rather than punishing) is assumed to be available to the reader, when it is itself a significant organizational precondition the article treats as a given rather than a variable.
Every serious personal failure can be generalized into reusable infrastructure — many failures are one-off or context-specific and don't scale into a tool anyone else needs.

Inferences:

The claim, taken with the aside about 'the story,' implies career credit for failure-recovery is partly rhetorical/political — a more interesting and less comfortable claim than the tidy 'do this instead' box acknowledges.

Narratives

Kun Chen's monthly self-check ('what did I do this month that I couldn't do last month') and his warning that the checking interval must keep shrinking as the field speeds up.
→ Supports proposition 1 (monthly growth measurement) and proposition 2 (knowledge decay) — functions as the sole evidentiary basis for the entire first point.
Michael Novati going from intern to principal (E7) at Meta in six years as a 'coding machine,' hitting a wall, then organizing a company-wide code health summit that pulled a dozen engineers together on hard migration work.
→ Supports proposition 3 (individual output ceiling; amplification through others) — the article's evidence that leverage-through-others, not raw output, produced his next promotion.
Christopher Brown recounting Jeff Bezos rejecting an overcomplicated early EC2/S3 design in favor of 'get object, put object,' redundant and fast.
→ Supports proposition 4 (absorb complexity, hide it from the customer / 'packaged engineering') — the article's single, famous anecdote for its most mechanistic point.
Kun Chen, early in his career at Bing, spending spare cycles building an unrequested tool that let the search team see where users clicked on results — a project nobody asked for that carried his first promotions.
→ Supports proposition 5 (non-consensus bet differentiates from average) — offered as the concrete instance behind Philip Su's abstract claim.
Carlos Arguelles skipping load testing before Black Friday as a tester, causing an 8-hour Amazon outage, expecting to be fired, and instead being told by his director to prevent it from ever happening again — which led to the TPSGenerator, now widely used across Amazon/AWS.
→ Supports proposition 6 (turn failure into shared infrastructure) and proposition 7 (career credit depends on the story told) — the article's most detailed and highest-stakes anecdote.

Questions addressed

✅ What separates the engineers who reach the very top of the field (principal, distinguished) from everyone else?
The article claims to answer this with five recurring patterns observed across many podcast conversations and Amazon experience, none of which reduce to raw talent, intelligence, or hard work.
⭕ Is the sample the author draws these patterns from representative of engineering careers broadly, or only of a narrow set of large, prestigious tech companies?
⭕ Are these five practices causes of these engineers' success, correlates of it, or retrospective narratives successful people construct about themselves after the fact?

Gaps

illogicalThe article's method is testimonial induction with no counterfactual: five 'patterns' are derived from a handful of retrospective, self-reported anecdotes told by engineers who already reached elite levels (E7/E9, senior/distinguished principal), then presented directly as causal prescriptions ('do this instead') for any reader. There is no discussion of engineers who did these same things and did not advance, engineers who advanced without doing them, or the base rate of these behaviors among the much larger population of engineers who never reach E7/distinguished. This is close to classic survivorship bias dressed as pattern-recognition — the five 'things' are what elite engineers said about themselves in an interview, not what was shown to distinguish them from a comparable population that didn't reach the same level. A directly relevant counter-finding already in this corpus: extract-hbr-individual-talent-organizational-excellence argues that sustained excellence is produced by systems (talent, team, routine woven together) rather than individual brilliance or habits, and that diagnosing performance as an individual-trait problem is precisely the mistake leaders default to and that produces an ineffective 'familiar playbook.' Huynh's article does the individual-trait diagnosis wholesale.
Read next: Work on survivorship bias and outcome-based sampling in career/success research (e.g. critiques of 'study the winners' methodology); Abbott's jurisdiction framework or systems-level accounts of career advancement (e.g. extract-hbr-individual-talent-organizational-excellence, extract-you-wont-get-replaced-youll-get-skipped) for a structural counterweight to the individual-habits framing.
incompleteAll five anecdotes are drawn from a narrow institutional band — Meta, Microsoft, Amazon/AWS, Google, NVIDIA — large, resourced, prestige-laden organizations with internal audiences for cross-team initiatives (a company-wide code health summit), promotion committees that reward 'the story,' and executive-level design reviews (Bezos personally weighing in on S3's interface). The article never examines whether 'measure growth monthly,' 'amplify others,' 'absorb complexity,' 'chase a non-consensus bet,' or 'turn failure into shared infrastructure' are equally available, meaningful, or even advisable for engineers at small companies, understaffed teams, blameful cultures, or organizations without a promotion ladder that rewards these exact behaviors. Point 5 in particular assumes a blameless-postmortem culture (a director who responds to an 8-hour outage by asking 'how do we prevent this' rather than punishing) as a given, when that culture is itself a scarce organizational precondition, not a personal practice a reader can simply adopt.
Read next: Literature on organizational preconditions for the behaviors prescribed here — psychological safety and blameless postmortem culture (extract-human-scalability-problem, SRE incident-response literature), and accounts of career advancement outside FAANG-scale organizations — to test whether the five practices travel, or whether they are downstream of already being inside a resourced, high-visibility organization.

5 Things World-Class Engineers Do That You Don't

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents