What makes someone a senior engineer?

This is a question my colleagues and I have been debating this year, all stemming from a desire to more fairly recognise the people within our teams. While the answer is potentially a case of it kinda depends, this post is me wrapping my thoughts around something that feels concrete and would potentially stand up to scrutiny from someone wanting to be called a senior engineer.

I’m fortunate to see this question being approached from two perspectives in my role as Powerco’s Operational Technology Manager.

1. In our electricity business, the focus is on good, robust asset management for a fleet of poles, wires, transformers and switchgear that is expected to last for decades. In this space, being called senior typically means you are a senior electrical engineer, with clear technical depth and experience in managing the full asset lifecycle.
2. In our digital (IT) business, the focus is on the continuous evolution of the organisation’s digital ecosystem, particularly as Powerco transitions toward becoming a Distribution System Operator (DSO). In this space, the definition of senior feels far less rigid. This is the area where I want to build a more robust definition of someone who is a senior IT Engineer.

So what does make someone a senior engineer?

Today I read a really interesting blog post by Matheus Lima over on Terrible Software. Matheus’ post was titled ‘What actually makes you senior’. Because his thinking aligns with my own (and I want to maintain a record of his thoughts), I’m going to copy many of the points he’s made below…

Excerpt from Terrible Software

People love to describe senior engineers with a big checklist: architecture, communication, ownership, leadership, etc. But if you strip away the title, the salary, and the years of experience, there’s one core skill that separates senior engineers from everyone else: reducing ambiguity. Everything else flows from that.

Here’s what I mean. A mid-level engineer can absolutely crush a well-defined problem. Give them a clear spec, some reasonable constraints, and they’ll deliver solid work. Don’t get me wrong, that is valuable.

The moment you hand them something fuzzy, though, like ”we need to improve performance”, ”users are complaining about the onboarding flow“ or ”we should probably think about scaling”, that’s when you see the difference. Not because mid-level engineers are bad at their jobs, but because ambiguous problems require something more.

Senior engineers look at the big, messy, abstract thing and start digging:

1. They ask questions nobody else thought to ask.
2. They separate what matters from noise.
3. They identify what should be done now vs. what to punt.

It’s one of the reasons why senior engineers are worth their salaries. Not just because they write good code (which they often do!), but because they derisk projects. They turn ”I don’t even know what this is“ into ”there are two small projects and one thing we should cut”.

Just a few questions, as an example, that senior engineers ask:

1. What problem are we actually trying to solve? (Not what solution do we want, but what’s the underlying problem?)
2. Who’s the user here and what’s painful for them? (They try to be specific. “Users” isn’t an answer.)
3. What are we assuming that might be wrong? (Every plan has hidden assumptions.)
4. What happens if we’re wrong and ship this anyway? (How bad is the downside?)

In other words, they first make the problem clear. Then, and only then, they go to solve it.

Excerpt from Terrible Software ends

My thoughts on seniority

I genuinely like the idea of using reducing ambiguity as a starting point to assess what seniority in the IT engineering space should represent, noting that this will mean different things for different organisations. My engineering colleagues will want to see a level of objectivity injected into the process, so a good, old-fashioned checklist is going to be essential.

To expand on Matheus’ points… Along with their deep technical knowledge, a senior engineer is someone who reduces ambiguity, and does so by:

1. Being curious and asking the right questions
2. Bringing the right people together to ask the right questions
3. Viewing problems holistically to identify how a single change here affects something over there
4. Removing noise to focus on what truly matters
5. Maintaining a vision of what lies beyond the immediate task or horizon
6. Bridging the gap between technology and strategy, particularly for non-technical stakeholders
7. Coaching others to help them understand the why alongside the how

I’d love to hear how other organisations have drawn the line between an engineer and a senior engineer. How did you avoid going overboard and creating a Google-style levelling system for a relatively small IT group? Was there some practical middle ground that you found worked for your team? Fire me an email if you have any thoughts (or links) on the subject.

Engineer: Why are you so senior? Senior Engineer: Simple, because I’ve been here the longest.

Hopefully, this is something that is not often ushered in your organisation.