What it actually means to be a senior engineer

Nobody told me what the job actually was when I became a senior engineer. I assumed it was mostly about being better at the technical parts, faster, more accurate, knowing more. That's true but it's table stakes. The actual shift is harder to name and took me longer to notice.

You Stop Optimising for Being Right

Early in my career I argued for the technically correct solution. If I knew the better approach, I pushed for it. Senior me still does that, but much less often and much more carefully.

The thing I had to learn is that being right about a technical decision is not the same as the team making the right technical decision. If I'm not bringing people along: if I win the argument but half the team is confused or unconvinced, we end up with code nobody owns properly. A slightly worse solution that the whole team understands and believes in will outperform a better one that only I can defend.

This doesn't mean lowering standards. It means spending more energy on the explanation than the conclusion.

Scope Changes, Whether You Want It To or Not

As a junior engineer, your scope is your task. As a senior, your scope is your team's output. These are different jobs.

The uncomfortable part is that nobody formally reassigns you. It just starts happening: you get pulled into decisions that aren't your code, you get asked for opinions on projects you're not working on, people check their approach with you before committing to it. If you keep treating your scope as your own tickets, you'll be technically productive but you'll have missed the actual job.

I remember the moment I realised this had changed. A colleague was about to design a caching layer in a way that was going to cause problems three months down the line. I knew it, said nothing because it wasn't my project, and three months later we spent two weeks untangling it. That was my failure, not theirs.

The Pushback Skill

Senior engineers push back: on timelines, on scope, on requirements that don't make sense. Not obstructively, but clearly and early.

The worst version of seniority I've seen is someone who knows a deadline is unrealistic, says nothing, then works 70-hour weeks to hit it anyway and burns out. That's not reliability. That's quietly absorbing a planning failure and calling it professionalism.

Pushing back well means being specific: not 'this is too much' but 'we can ship X and Y by the deadline if we move Z to the next cycle, here's why Z is the one to defer.' You're not saying no: you're doing the prioritisation work that probably wasn't done upstream.

What Actually Gets Harder

The technical problems mostly get easier. You've seen more patterns, you have better instincts, you know which shortcuts will cost you later.

What gets harder: saying unpopular things with enough conviction that people take them seriously, without being the person who always rains on the parade. Knowing when to let a suboptimal decision through because the cost of the argument isn't worth it. Mentoring someone without just doing it for them. Keeping your own work moving when most of your energy is going into other people's problems.

None of that shows up in a job description.

Moving Forward

The clearest sign that someone's made the jump isn't their code quality or their system design, it's whether the team around them is better. Do the people they work with make fewer avoidable mistakes? Do problems get caught earlier? Is knowledge spreading or concentrating?

That's the job. The coding is almost incidental.