What Makes a Senior Engineer Senior?

I’ve been thinking about this question for years. Not in the abstract — in the very concrete sense of sitting across from someone in an interview, reading their resume that says “Senior Software Engineer,” and trying to figure out if we’re talking about the same thing.

A quarter of tech jobs that were considered junior in 2019 now carry senior titles. Title inflation is real, and it’s made the word almost meaningless. When I’m hiring, I can’t trust the title. I have to evaluate for something deeper — and I think that something is force multiplication.

The Force Multiplier

There’s a concept borrowed from military strategy: a force multiplier is a factor that dramatically increases the effectiveness of a group. I think this is the single best lens for understanding what separates a senior engineer from everyone else.

A 10x engineer is a myth, or at best a misdiagnosis. The engineer who writes ten times more code than their peers isn’t ten times more valuable — they’re often ten times harder to work with. The engineer who makes five people twice as effective? That’s the one who changes the trajectory of a team.

Let me make this concrete.

Impact

Think about a team of five engineers. Let’s say each one gets six productive hours a day, five days a week. That’s 30 work units per person, 150 for the team. That’s the ceiling — the maximum output this team can produce in a week.

Now imagine a senior engineer joins and suggests three changes. Maybe it’s how the codebase is structured, or how deployments work, or how the team communicates about technical decisions. These changes improve each engineer’s output by 15%.

150 work units increased by 15% is 172.5 — an extra 22.5 work units per week. If you wanted to achieve that same gain through individual effort alone, you’d need to work two weeks in one. Every week. Forever.

Scale this to an organisation of 150 engineers. A 2% improvement across the board is 90 extra work units a week. No individual, no matter how talented or caffeinated, can match that through personal output. This is the math of force multiplication, and it’s why impact matters more than raw productivity.

The best senior engineers I’ve worked with don’t just write code faster. They change the conditions under which everyone writes code. Through technology choices, architecture decisions, processes, and patterns, they create leverage that compounds over time.

Mentoring

Force multiplication extends naturally into mentoring, but not in the way most people think about it.

There’s a phrase that gets thrown around — “make yourself redundant.” It sounds scary at first. Why would you work to replace yourself? But think about the alternative: imagine becoming so irreplaceable in your current role that you get passed over for every promotion, every interesting project, every team change, because nobody can fill your seat. That’s not job security. That’s a trap.

A senior engineer should be building the senior engineers of tomorrow. Not through formal mentorship programmes or lunch-and-learn talks (though those are fine), but through daily work — pairing on hard problems, explaining the why behind decisions, creating space for others to make mistakes safely.

James Clear puts it well: a person getting 1% better every day will be 37 times better by the end of a year. That’s the power of compounding. Now imagine that compounding happening across an entire team because a senior engineer is deliberately investing in the people around them.

Very few of us got where we are entirely on our own. Someone pulled us up. The duty is to keep pulling.

Knowledge

Do you actually know what you’re talking about? And — more importantly — do you know what you don’t know?

The Dunning-Kruger effect tells us that people with low expertise tend to overestimate their ability. Software engineering is uniquely vulnerable to this because there are so many layers — networking, databases, distributed systems, security, accessibility, performance, deployment, observability — that you’re constantly battling overconfidence across dozens of domains simultaneously.

Real knowledge at the senior level isn’t about knowing everything. It’s about having enough depth to recognise patterns, enough breadth to know which questions to ask, and enough humility to say “I don’t know, but I know how to find out.”

The engineers I struggle to hire aren’t the ones who lack knowledge. They’re the ones who’ve stopped being curious about what they don’t know. Every year they do the same thing, and they think that’s ten years of experience. It’s not. It’s one year, ten times.

Judgment

This might be the hardest skill to evaluate and the hardest to teach. John Allspaw puts it perfectly: mature engineers make their trade-offs explicit. Everyone cuts corners in every project. Immature engineers discover them in hindsight and are disgusted. Mature engineers spell them out at the start, accept them, and recognise them as part of good engineering.

There is never a black-and-white, this-is-the-only-way answer to a technical problem. There are better and worse solutions, but they exist on spectrums — speed vs. longevity, performance vs. operability, flexibility vs. simplicity. A system that’s 10% slower but your team can debug at 2am beats a performance monster that only one person understands.

Judgment is knowing which trade-off to make in which context. It’s knowing when to take the shortcut and when to invest in the right abstraction. It’s holding the tension between “ship it” and “do it right” and making the call based on the specific situation, not on dogma.

Kent Beck captures the soul of it: “It depends.” Those two words contain more engineering wisdom than any framework or methodology.

Communication

I used to think communication was a soft skill — nice to have but separate from the real work. I was wrong. Communication is a technical skill, and it might be the highest-leverage one a senior engineer can develop.

Tanya Reilly nails this: at the senior level, people assume you know what you’re talking about. That perceived authority makes careless communication actively dangerous. A throwaway comment in a design review can send a team down a two-week rabbit hole.

The practical side is less dramatic but equally important. Will Larson’s SQCA framework changed how I think about written communication: every document’s opening should cover the Situation (context), Complication (why it’s a problem), Question (what needs deciding), and Answer (your recommendation). It sounds obvious, but most engineers bury the point three pages deep.

Writing things down scales in a way that conversations don’t. A well-written RFC, decision record, or post-mortem reaches people across teams and time zones. It survives after you leave the meeting, the team, or the company. Reilly calls documentation “the number one tool for project success,” and she’s right.

Camille Fournier adds the uncomfortable truth about repetition: most people need to hear something at least three times before it sinks in. If you’ve said it once and you’re frustrated that nobody listened, you haven’t communicated — you’ve just talked.

Being Amenable

This one is underrated and often misunderstood.

Being amenable doesn’t mean being a pushover. It means being genuinely open to being wrong. It means recognising that there is never only one solution to a problem. There are better and worse approaches, but I’ve never encountered a meaningful engineering decision where there was only one viable path.

The engineers who struggle at senior level are often the ones who pick hills to die on over implementation details. They’re so attached to their solution — their framework, their architecture, their pattern — that they can’t engage productively when someone proposes an alternative.

A senior engineer should have strong opinions, loosely held. They should be able to argue passionately for their approach, genuinely listen to the counter-argument, and change their mind when the evidence warrants it. Not performatively. Actually.

This is especially important when working across teams or with non-technical stakeholders. Sometimes the business will make a decision you disagree with. Sometimes your team will choose an approach you wouldn’t have chosen. A senior engineer doesn’t need to agree with every decision — they need to disagree constructively and then commit fully once the decision is made.

No good senior engineer chooses a hill to die on over a technical preference. Save that energy for the things that actually matter — user safety, data integrity, accessibility, ethical boundaries.

Empathy

Related to being amenable but distinct: empathy is understanding where other people are coming from. Not just intellectually, but practically.

When you give feedback, do you consider how the person will receive it? When you propose a technical change, do you think about the engineer who’ll be maintaining it at 2am? When you push back on a deadline, do you understand the business pressure behind it?

Empathy in engineering isn’t about being nice (though being nice helps). It’s about understanding the hills that other people are willing to die on, so you can navigate around them. It’s about knowing that the way you deliver a code review comment matters as much as the comment itself. It’s about recognising that someone’s resistance to your brilliant idea might be rooted in an experience you don’t have.

Belief in the Goal

This one depends entirely on context. Some teams and roles don’t require deep belief in the mission — the work is the work, and professional execution is enough. Other teams, particularly those building something from zero or working through existential uncertainty, need people who genuinely care about where they’re going.

I don’t think this belongs on a universal checklist of senior attributes. But when it’s present, it’s a force multiplier of its own.

The Hiring Problem

I said at the start that I struggle to find senior engineers who match what I think senior actually means. I’ve sat through hundreds of interviews where the title said senior but the conversation revealed someone who writes good code individually and has done it for enough years to earn the promotion.

That’s not senior. That’s experienced mid-level — and that’s fine. Not everyone needs to be a force multiplier. Not everyone wants to be. But when I’m hiring for senior, I’m looking for someone who will change the trajectory of the team, not just contribute to its velocity.

Charity Majors captures the paradox perfectly: many engineers get stuck trying to reach senior because they want someone to tell them what to do — which is the very opposite of what a senior engineer does.

We’re All Figuring This Out

I want to be clear: I don’t think my definition is the definitive one. Every company, every team, every context needs something slightly different from their senior engineers. The attributes I’ve described — impact, mentoring, knowledge, judgment, communication, being amenable, empathy — aren’t a checklist. They’re a lens.

What I do believe is that the industry’s current approach of handing out senior titles based on tenure is failing everyone. It fails the engineers who get the title before they’re ready and then struggle under expectations they can’t meet. It fails the teams who hire for “senior” and get an individual contributor. And it fails the actual senior engineers whose title now means nothing without a conversation to back it up.

A senior engineer is a force multiplier. They make the people and systems around them better. That’s it. Everything else is detail.