5 Things World-Class Engineers Do That You Don't
Here is what the truly elite do differently.
One of the best things about doing my podcast is the hours it buys me with engineers at the very top of the field, the principal and distinguished engineers whose careers other people seek to model their own.
After participating in many such conversations, both through my podcast and during my time at Amazon, I have recognized a handful of patterns that have held over the decades and across different companies.
What follows is my running list of those patterns, the ones that keep surfacing whenever I sit down with someone elite. There are five of them, and I explain the gap between what they do and where most other people stop. If you would add another one to the list, drop it in the comments.
1. They measure their growth on a monthly cadence
The best engineers do not wait for a promotion or annual performance review to tell them whether they are growing. (By the time a stalled promotion comes to you, you have already lost a year.) The best check their growth on a much shorter loop.
Kun Chen, who reached E7 at Facebook and partner level at Microsoft, gave me the cleanest version of this on the podcast:
“People wait until they are not getting promoted to realize, ‘Oh, I’m not growing.’ That is a very lagging indicator. The way I could tell I was not growing was by asking myself, ‘What did I do this month that I couldn’t do last month?’”
And he keeps shortening the loop as the field speeds up: “Given how fast things are moving now, people should continue to compress that time frame.”
Carlos Arguelles, a senior principal who has rebuilt himself at Microsoft, Amazon, and Google, explains why the cadence matters: because specific knowledge decays. “Whatever you learn right now, there is a decay to the value of what you’ve learned. So you have to have this mindset of embracing new things and learning from them.”
Put those two together, and the target becomes very clear.
Notice the verb in Kun’s question. “What can I do?” A higher bar than ‘What do I know?’
“Knowledge expires,” as Carlos says. The thing worth tracking each month is a new capability you can put to work.
What most people do: They sit at one of two extremes. They measure on a yearly cycle and only notice a gap when no promotion comes. Or they swing the other way and chase every shiny new technology the week it lands, but they stay shallow on everything.
Do this instead: Look back at the last month and name one new skill or capability you picked up and can already put into practice. If nothing comes to mind, choose one thing this week that you will commit to learning and using before the month ends. Make it concrete enough to apply, for example, a technique or a workflow you can take into a real task.
2. They amplify the people around them
Michael Novati went from intern to principal (E7) at Meta in six years, largely by being what he calls a “coding machine.” He kept the whole codebase in his head and shipped at a volume almost nobody could match.
But then he hit a wall.
“There is only so much that one person can do themselves,” he told me. “The coding machine is a lone-wolf kind of thing.”
When Meta wanted to push him toward the next level, the feedback they gave him was about broadening his influence. He organized a company-wide code health summit, pulled a dozen people doing hard migration work into one room, and in so doing, he earned both the rating and the path up.
The lesson worth stealing is the one that Michael learned the hard way: raw individual output has a ceiling, and the way up past it runs through other people.
Helping people is one of the few real win-win-wins in this job. The person you help levels up; the company ends up with a stronger engineer; and you get the credit for scaling past your own two hands.
What most people do: They try to win on personal throughput, thus capping themselves at whatever work one person can produce.
Do this instead: Pick one piece of work you would normally grind out alone this week. Route it through someone else instead, by pairing on it or handing it off with enough context for the other person to own it.
3. They work backward from the customer and hide the complexity
Christopher Brown, currently a distinguished engineer at NVIDIA, was a founding engineer on EC2, which became the cornerstone of the hundred-billion-dollar cloud business that is AWS. He watched the same instinct shape S3 in its earliest days, and it came straight from the top.
He remembers Jeff Bezos pushing back on an early, complicated design: “No, no, no, this is too complicated. It needs to be like ‘get object, put object,’ and it needs to be redundant and it needs to be fast.”
The engineers wanted to expose the system’s real structure. Bezos wanted the complexity hidden so the customer never had to feel it.
Christopher calls what AWS sells “packaged engineering,” and that phrase is the tell. The best engineers treat the messy internals as their own problem to absorb, so the person on the other side of the interface gets something simple.
What most people do: They expose the complexity they had to wrestle with and call it transparency, leaving the client or user to untangle it.
Do this instead: On your current project, ask yourself one question. Am I passing the complexity down to my clients, or am I bending over backwards to absorb it and hand them packaged engineering? Aim to do the second thing.
4. They refuse to be average
Philip Su earned eight promotions in eight years at Microsoft and reached distinguished engineer (E9) at Meta. His explanation for why most people stall is blunt:
“If you’re just as smart as everybody else and you work just as hard as everybody else, you’re just as average.”
Smart and hardworking is the price of entry, and almost everyone in the building has paid that fee. If everybody, including you, is out-grinding everybody else, and if the people around you are every bit as capable as you are, that makes you average.
Separation from the average comes from working on something different.
The best engineers will find the non-consensus bet or the unglamorous problem that nobody else wants to tackle, and they will plant their flag there.
What most people do: They try to win by being a little smarter and working a little harder than the person beside them, on the exact same work everyone else is chasing.
Do this instead: Name the one thing your most talented peers are all competing on, then find the valuable problem next to it that none of them have claimed. Kun Chen did exactly this at the start of his career at Bing. While everyone else worked the roadmap they were handed, he used his spare cycles to build a tool that let the search team see where users clicked on the results page. Nobody had asked for that tool, but that work carried his first promotions.
5. They turn their worst failures into lessons for everyone
When they cause a disaster, they develop something that will protect everyone from a recurrence.
This is Carlos’s best story, and it is the reason he is a senior principal today. As a tester, he once made the call to skip load testing before Black Friday. The result? On Amazon’s biggest shopping day of the year, his system fell over and took down the database, causing an eight-hour outage.
He walked into his director’s office expecting to be fired. Instead, after the director heard the news, “He stops and he says, ‘Well, that’s enough of that. How are you going to prevent this from ever happening again?’”
Carlos spent the next months building generic load-testing infrastructure. He realized that other teams had been skipping load tests for the same reasons he had, and he gave them his new tool. It became the TPSGenerator on which Amazon and AWS now run basically everything.
He is sharp about why it worked. It was not only the engineering: “A lot of career growth and socializing things are dependent on the story that you tell.”
His pitch was simple. We skipped the test and caused an outage. We built the infrastructure, tested it, and prevented the next one. A good story.
This is the stance that Carlos carries into the interviews he runs: “I don’t care that you failed. I care what you did after the failure.”
What most people do: They quietly patch their own code and hope nobody remembers.
Do this: Take your most recent real mistake and ask what lesson the whole team could take from it. Turn that into something they can use. Then tell the story.
Notice that none of these 5 things come down to raw talent, intelligence, or hard work.
Pick the one that stung you the most, and start there this week.
Enjoyed this week’s newsletter? Give it a ❤️ so I know to write similar ones in the future.
Ah “packaged engineering” that’s the term I’m trying to do currently for a PoC that was built recently with an intern. Thanks for giving it a label.
Another banger of an article.