Two Engineers Joined My Team the Same Week With the Same Skills. Three Years Later One Was Staff and One Was Stuck. The Difference Was Not Talent.
I watched it happen up close, from hire to divergence, and I can tell you exactly what separated them, because it was not intelligence, not work ethic, and not how good their code was. It was a specific, nameable, learnable set of things, and the stuck one never found out what they were.
They started the same week. I remember, because I onboarded both of them, and if you’d asked me then to bet on which one would go further, I genuinely could not have called it. Same level of raw skill. Both smart. Both hard workers. Both wrote perfectly good code. On paper, on day one, they were interchangeable.
Three years later one of them was a staff engineer with scope across multiple teams, and the other was in the exact same role they’d been hired into, doing good work, quietly wondering why they hadn’t moved. And I had a front-row seat to the whole divergence, so I want to tell you what actually separated them, because it’s not what most people assume, and it’s the most useful thing I’ve learned about this career.
It was not talent. That’s the first thing to kill, because it’s the comforting explanation and it’s wrong. The one who got stuck was every bit as smart as the one who moved. If anything, on pure technical depth, they were slightly ahead early on. Talent was not the variable. Something else was, and it was a set of specific behaviors, and I watched one of them do these things and the other not, over and over, for three years.
The one who moved treated every problem as bigger than his ticket
Here’s the first difference, and it showed up early.
When you gave the one who moved a task, he’d do the task, but he’d also notice the thing next to the task. “This works, but I think it’s going to break the reporting job downstream, I checked, here’s what I found.” Nobody asked him to check. He just treated the problem as the whole problem, not the slice on his ticket, and that instinct, extended over three years, meant he was constantly catching things, connecting things, seeing the system while everyone else saw their piece.
The one who got stuck did his ticket. Well. Completely. And then stopped, at the edge of the ticket, because that was the job as written. Every individual instance of this looked totally fine. You could not fault him on any single task. But three years of doing exactly your ticket and nothing past it adds up to an engineer who is trusted with tickets, while three years of quietly owning the whole problem adds up to an engineer you trust with the system, and only one of those becomes staff.
The one who moved made his reasoning visible
This one was subtle and I almost missed it.
When the one who moved made a decision, he’d say why, out loud, in a way other people could follow. In a review: “I went with this approach because we care more about read latency here than write throughput, so I optimized for the reads.” He wasn’t showing off. He was making his judgment legible, so the people around him could see not just what he did but how he thought, and over time that meant everyone knew he had good judgment, because they’d watched it work, out loud, hundreds of times.
The one who got stuck had good judgment too. He just kept it inside. He’d make the same quality of decision and say nothing about why, so his reasoning was invisible, and invisible judgment doesn’t build a reputation, because nobody can see it to trust it. Three years later, everyone knew the first one was a strong thinker and was fuzzy on the second one, and the difference was almost entirely that one narrated his thinking and one didn’t. Same thinking. One made it visible. One left it in his head.
The one who moved was comfortable saying “I don’t know”
Watch for this one, because it’s counterintuitive.
The one who moved would say, in front of everyone, “I don’t know, let me find out,” or “I’m not sure that’s right, help me understand.” And it made people trust him more, not less, because when he did say he was sure, you could believe it, since he’d shown you he’d tell you when he wasn’t. He was calibrated, and visibly so, and that made him someone you could hand an ambiguous, high-stakes problem to, because you knew he’d tell you the truth about what he did and didn’t know.
The one who got stuck always had an answer. Always. Even when he was guessing, it came out sounding certain, and because you couldn’t tell his guesses from his knowledge, you couldn’t fully trust either. It made him hard to rely on for the ambiguous problems, the ones without clear answers, which are exactly the problems that get you promoted, because those are the ones that require judgment and honesty about uncertainty, and he’d trained everyone to be slightly unsure whether to believe him.
The one who moved communicated like the listener
In meetings, the one who moved led with the point. “I think we should do X.” Then the reasoning, if asked. Short, clear, aimed at getting the room to actually understand, because he treated being understood as his job, not the listener’s.
The one who got stuck explained everything, thoroughly, all the context and caveats, and buried the actual point somewhere in the middle, and made the room do the work of digging it out, which most rooms won’t do. So his good ideas landed less often than the first one’s equally good ideas, purely because of delivery. Over three years, the one whose ideas kept landing got the reputation for having good ideas, and the one whose equally good ideas kept dying in delivery got the reputation for being hard to follow. Same ideas. Wildly different outcomes, decided by whether they were compressed and delivered or dumped and abandoned.
The pattern, and why it matters that it’s learnable
Look at the four differences together, because they rhyme. Owning the whole problem instead of the ticket. Making reasoning visible instead of internal. Being honest about uncertainty instead of falsely certain. Communicating so the listener gets it instead of so you feel complete. None of those are talent. Every one of them is a behavior, a choice, a thing you can decide to start doing on Monday.
That’s the part that should either thrill you or sting, depending on where you are. The one who got stuck was not lacking some innate gift. He was not doing four learnable things, and nobody ever told him they were the four things, so he kept grinding the technical skill that was already good enough and stayed exactly where he was, mystified, watching someone no more talented than him move past. The gap between them was real and it was large, and it was made entirely of habits, which means it was closeable, which means his being stuck was, in a quiet and awful way, unnecessary.
I think about this a lot, because I’ve been both of these engineers at different times, and the difference in outcome is enormous and the difference in behavior is small. Four things. Own past your ticket. Say your reasoning out loud. Tell the truth about what you don’t know. Lead with the point. Do those consistently for a few years and you become the one who moves, and skip them and you become the one who’s stuck and can’t figure out why, and the cruelest part is you’ll blame talent or politics or luck, when it was four habits sitting there available the whole time.
The engineers who move up are not the most talented ones. They’re the ones doing a specific set of visible-judgment behaviors that the stuck ones never learned were the actual job. I watched it happen over three years, to two people who started identical, and the whole difference was learnable, and one of them just never got told what to learn.
Those behaviors, owning the outcome, making judgment visible, the honesty and communication that separate the engineers who move from the ones who stall, are the entire spine of The Senior Backend Engineer Handbook. If you’re technically strong and quietly stuck, you’re probably not missing skill, you’re missing these, and they’re learnable starting now.
The Senior Backend Engineer Handbook: From 3 AM Outages to Senior Offers
— longer writing goes out through my newsletter:
Devrim’s Engineering Notes | Substack
Two Engineers Joined My Team the Same Week With the Same Skills. was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More