S2:E04 - What Puts the Senior in Senior Software Engineer?

Jeremy: Hi folks, welcome to The Retrospective.

This is a podcast for engineering managers and I'm your co host Jeremy

and alongside me, I have Peter,

Péter: Yeah, hi everyone, I'm Peter, what are we going to talk about today?

Jeremy: The topic I wanted to cover today was about senior software engineers

or rather what makes them senior?

What is the characteristic of a senior software engineer?

And the reason I wanted to talk about it is because I think a lot of people

focus on seniority and I don't think it's about years of experience,

but rather a kind of complex mix of behaviors that bring it all together.

Péter: Cool.

Okay.

If this is a quiz show or something, how do you define

senior engineer in one sentence?

Jeremy: Yeah so this is the, this bit I had to think about a lot and I tried

to come up with a single sentence.

I'm going to try and read it, but then I think we're going to unpack it a

little bit in the rest of the episode.

I would say that a senior engineer combines technical expertise with

business understanding and leadership skills, they improve code quality and

most importantly, the outcomes of a team.

In a way, I think of that as like a multiplier of the team, like a manager

is a multiplier of a team, but really focusing much more on the technical

and the results part of the team.

That's how I would summarize it.

Péter: Okay.

So just that I understand well.

You mean technical expertise, team impact, business awareness

and leadership behavior.

Jeremy: Leadership and behavior.

Yeah.

Péter: Yeah, yeah, those are those are the four main areas.

are in order?

Like, or or let's not get into

Jeremy: Ah, that's really interesting.

I think it's, I think I had the technical part because that is where everybody

focuses when it comes to the senior role.

I think the technical part is just, it's just a basic foundation.

And even that technical part, I would define it and we'll dive

into that in a second, but I would explode that apart a little bit more.

Another way to think about seniority of roles is the time horizon that they

operate on and think about or an analogy because we've been doing a little bit

of gardening this week and for the first time I'm living in a house with a garden

and I've done a year now in the same house is that as a gardener you take care

of the weeds but you're and, you think about when I'm going to be pruning the

plants and what season and everything else, but you're also needing to plan

several seasons ahead of how things are going to grow and grow in your garden.

And I think that's what, I think that's what a senior engineer does.

They're not just focused on the here and now and the tactical,

but they've got a part of how they operate and think is looking on a

time horizon that is further ahead.

In fact, I think that's actually when we look at engineering manager and a

manager of managers, and then the kind of managing a wider department, the

horizons or the levels that you zoom up and down on are also in that same kind

of way you're thinking less tactically and more strategically and in the future.

And I think that applies to the senior level.

It's that first level where you're thinking beyond just the immediate

tasks that the team need to do.

Péter: I really like this analogy it explains the time horizon really well.

I also like this analogy because it explains also the more holistic view

that I expect from a senior engineer.

In a garden, you don't just have grass or you don't just have vegetables

or you don't just have a fruit tree.

You have a lot of stuff that are interacting with each other

and have impact on others.

And I think this translates well to the engineering profession that

Jeremy: Yeah.

Péter: code that you're responsible for is not living in a vacuum, it's interacting

with other team's, products, or externally with third parties and users.

Yeah, this, this, this gardener attitude or analogy.

I think it works really well.

Jeremy: Yeah, like just to give an example in the house that we live in

at the moment, the people, I guess the landscaper that initially designed the

garden, designed it so that we always have some flowers or plants in bloom.

At every season of the year.

Péter: Wow.

That shows expertise.

Jeremy: And I think that's exactly and it's and in the way that each

plant the way that they're organized in the disposition of where the sun

hits at different seasons and so on.

So yeah, like right now we have a fejoa tree which is a kind of a guava from

South America, if I'm not mistaken.

And the fruit is now starting and it's it's delicious.

So yeah, that's what senior engineers do.

There's a bit of delight to it, I guess.

Péter: Oh yeah.

And I, I mean, I don't want to stick to this analogy too long, but it's also a

good, because the impact of a professional like the landscaper or a senior

engineer is not immediately obvious.

Like, and I think that's, that's, that's typical that when things just

seem to be going very smooth then maybe someone very senior, very experienced

was working behind the scenes on that.

Jeremy: Yeah.

I have a good example where I really saw this senior kind of role stand

I was on a project at Accenture.

It was when I was early in my career.

There was like over a hundred people on the project.

It's probably like 40 engineers or developers working on it.

And the project seemed to be okay.

But there was a guy that I worked with and for who started to see that

the architecture that we had wasn't really going to work and as and we

were actually quite far into the coding stage and it was amazing to see how he

started to identify that then I mean I worked very closely with him I actually

built a model to mathematically prove that the architecture wouldn't work

is before I knew it was it actually was relates to theory of constraints.

And how we were trying to process events essentially.

And I loved how he was able to very smoothly coordinate a very big pivot in

the architecture without actually much impact to the overall project delivery.

And we just.

It's just really interesting how that smooth leadership of someone senior

who really knows what they're doing.

And he was able to coach me and mentor me in all of that to enable me to grow

so that I think I can, I could learn from that and be able to do that in the future.

It's really, that's what I think someone does.

They just de risk the whole operation of what you're doing.

Like they take out the risk.

Péter: That's a great example.

And that's a great summary of, of de risking.

But let's jump, start to jump into these four aspects that we mentioned in

the beginning and start with the, the most obvious, the technical expertise.

I would even say that maybe this is the easiest for someone to gain experience in.

Can you explain briefly, what do you think, what technical

qualities define a senior engineer?

Jeremy: Yeah, I think this is the easy one, right?

This is the one that everyone's focused on.

Maintainable code making good architectural choices not over building

things, which is a trap at the same time, not under building things.

You know, it's like a, there's a double edged sword to that having

a deep, systems understanding of how the systems hang together.

In fact, this is goes along with jumping into a new code base and very quickly

being able to navigate and understand it.

I think the two go well together.

When you have a difficult problem to solve, usually the first solutions

tend to be quite complex and hard for people to understand and you have

to iterate through that to get to something simple that brings clarity.

And I think I think that's what that's another key part that an engineer who's

senior can do is they can take you to the other side to that simple solution.

Péter: Yeah, I love this summary.

I would add one word, pragmatic.

I really like this word because it shows that you get something

done, but it rules out all the over engineering or under engineering options.

So I, really like the pragmatic word and

Jeremy: I love it.

Péter: people when they

Jeremy: Yeah.

Péter: when they want to grow or what is what they expecting.

Good.

Okay.

So this is the easy one.

Let's, I, I would say, let's move on to the second one, which is team impact.

Do senior engineers improve their teams?

Mm-Hmm.

Jeremy: Yeah.

So this is the bit where I think.

You're not just brilliant individually, but you're a multiplier, like we

expect managers to be multipliers of their team, you're a multiplier

of your team's productivity unit.

That means, I think let's start with the basic where people start

on the senior and they focus on, which is teaching and mentoring.

That's, that is something that I expect senior people to be able to do.

And in fact we need to create an environment where they have

a mix of people in the team so that you can do that, right?

Otherwise maybe folks kind of stagnate.

But it goes beyond that.

It's focusing on the bottlenecks.

I think modeling how to do things as well.

Writing clear documentation.

I think that, that is, again, I think this is still like focusing

a lot on the basics, which we mostly cover in what a senior does.

I have a story of an anti pattern.

Um,

Péter: this.

Yeah.

Hmm.

Jeremy: Yeah.

I mean, very early in my career, I worked with, in a team where I

worked with one of the most brilliant in terms of technically competent

engineers I've ever worked with.

But he was somewhere on the spectrum.

I don't know exactly.

So he was the technical lead for the team.

Basically he worked mostly on his own, criticized everyone

else rewrote your code.

Like you would do something and he would rewrite it.

Everything was way more complicated.

And honestly, I never really learned from him.

I learned from other people in the team.

I learned from my manager and how they coached me.

But I just really found that when he explained things to me, I, it was

hard for me to access a lot of the kind of it was just too complicated.

And actually, other people found simpler ways.

And it's funny because from that experience, I ended up.

Take it was, I was working on Symbian OS, which is a very complicated operating

system, embedded operating system.

And because I learned how to do the simple concepts, I actually built

some training courses for Symbian that I ended up teaching, um, from

it, but honestly it wasn't from him.

And that's a shame because it's probably like one of the best engineers on Symbian.

Péter: yeah, I really love this story.

I have a quote which I'm going to paraphrase is that, and I don't remember

who is it from, I'm sorry, that superstar engineers, they think they are creating

a culture of excellence, but in reality, they create a culture of fear, and I

think this is coming through from your story also, which is a great anti pattern.

If you have a very experienced engineer who is going in and writing, fixing your

code instead of you, not teaching you how to do stuff, it just stifles all kind of

innovation and all kind of work because everyone is paralyzed that they're just

going to make a mistake and they're going to get humiliated and corrected.

So the team impact is what matters at the end of the day

and not not individual impact.

So if somebody can positively impact the team, that's a senior behavior, I think

Jeremy: Yeah, I think so.

At least for me, the scope of senior sits mostly within the team and

into the boundaries of other teams.

And when we look at maybe more senior roles like staff and so on, we're looking

at a wider radius of influence and impact but maybe that's a separate, a

whole separate episode of the podcast.

Péter: That's a rabbit hole, we're not walking into today.

Cool.

Okay.

being mindful of that.

I think explained really well what we mean by team impact and why it's important.

Let's move on to the the third aspect business awareness.

What, how, how, how do senior engineers.

handle the business side.

Do they even have to?

Jeremy: Yeah.

Some so called senior people I've worked with really are still in the mode of

feed me to the product manager, feed me the stories and then and what you want

and your requirements and then I'll turn that into the technical implementation.

And I think that really great senior and or, I think for me, my

personal bar for senior is that they are very close to the user.

They are seeking and pushing to be seeing the user using their software.

They're modeling that to the team and they understand the business context.

If it's financial software, they understand it deeply or they learn

how to to learn the business context.

And often, I mean, you, over your career, you might work in different fields,

but you should be able to quickly come up to speed with the business problem.

And then it's about converting it.

The business Problems into solutions.

And I really think the criteria for making a decision is based on the

impact you can have on the business and always linking that back.

And personally, I like to equate that to outcomes, which is a

change in human behavior that is, linked to business results.

So it's thinking about that human.

Always.

And the behavior change, sometimes that means smaller, simpler solutions.

And and I think this is about business value and always having your milestones

and your deliverables focused on that and not just on not just on a kind of like

an endless implementation and actually the great senior people are willing to

stop, even though they know that they could go keep going because they reached

the outcome that we were aiming for the value we're aiming for, and they don't

let these projects run forever and forever

Péter: yeah.

I mean, they are pragmatic.

Uh,

Jeremy: Pragmatic, exactly yeah.

Péter: I have a story also for, for this being aware of the product that you're

working on and using this information in your architectural decisions.

Back when I was working at Gawker, we were working on an in house CMS

and in a startup phase, you know, features are frequently changing.

We were trying to figure out how.

commenting should work, what kind of metadata we should store on posts.

And this resulted in frequent database structure changes,

which is a very costly operation.

So that was the idea from an engineer to all this metadata,

especially new experimental stuff, which is just Serialize

it and store in protocol buffers.

So we just didn't care about all the structure.

We just serialized whatever data we

Yeah.

So this is the

Okay.

Yeah,

store it like that.

And this this requires a very strong collaboration between product and

Jeremy: This, that, what, that example couples this technical expertise and

understanding what is possible with technology and being on top of all the

other potential technical tools that are out there and then picking the

right tool for this particular context.

It's a real skill.

Yeah.

Péter: what makes it really hard is that you need to sacrifice something.

In our case, we needed to sacrifice some kind of search performance, because if you

have serialized data, you need to create and maintain indexes, or you just give

up being able to search on some of these.

But we realized it's okay.

Like, like this was not a critical feature.

And and what we gained was more important.

Oftentimes, less senior engineers, they got stuck at this point,

and they cannot sacrifice one of the features of their systems

Jeremy: Exactly.

Yeah.

Péter: Let's, let's move on to the final aspect, which is maybe the most ambiguous.

And, and was that I found that people struggle with often is leadership.

What, what, what, what, what, what is leadership and what

kind of behaviors stand out from senior engineers in your point

Jeremy: Yeah, I think there's actually two parts to this.

One is your kind of general behavior and then there's the leadership aspect.

So for me, the general behavior is about ownership, taking ownership and

responsibility for your projects, having like a learning mindset and actually,

More than anything else, and this is when you take responsibility of projects,

it's not micromanaging other people, but it's fostering that growth mindset and

other people is finding that balance.

Going back to that point about mentoring, growing others but I

do think ultimately The ownership goes beyond I'm the lead on this to

that de risking of the whole thing.

It's about knowing when to ask for help, knowing how to ask for help.

I think like it's the first thing like towards your senior journey

is like knowing how to ask for help and knowing and not being stuck.

The worst is that getting out of what you see junior people doing is

being stuck and not asking for help.

Senior people don't do that.

That there's a whole aspect of tech debt managing legacy code, like having

like a way of doing that, which isn't super religious and we need to get

rid of all of this, but having this going back to your pragmatic word,

having a pragmatic way to do it.

And I think also.

Look, honestly, it's when we talk about behavior, there's conflicts

and how you manage conflict, picking battles and not just going after every

little point, because, you know, these are smart people and you can have

like religious debates about lots of things, but it's really picking what is

important and what's important for the business or, the ability to deliver a,

de risking the system rather than just being on a crusade over everything.

Essentially someone who's really refreshingly positive in the

environment rather than constantly negative and dragging you down.

Péter: Interesting.

Yeah, yeah, I agree with the positivity aspect, but I think

it can be a controversial one.

I see some of the engineers saying that I'm not negative, I'm just

realistic and paints the most gloomy picture of the future possible.

Yeah, but I agree that this is major professional behavior.

What you just described.

what about the other part of this point?

The leadership skills that that you mentioned?

Jeremy: Yeah.

So, for me, leadership is influencing and bringing other people along with you

and or one aspect of leadership, maybe,

Péter: No, Actually, there is a definition saying that leadership

is influencing without the title.

And I really like that because a lot of people are insisting

on the title before they start.

They think the title comes first, but actually I think is the other way around.

Jeremy: I always think you need to be showing it before you, you get the title.

So I think it's obviously, I've mentioned this before, but you model the right

things like you lead by example.

I think figuring out how to get agreement within a team which, isn't

always consensus, but it is managing the disagreement and managing that.

All of this is tied to communication skills.

I think this is just so crucial in leadership is clarity communication.

How can you bring people along with you and influence people

if you can't communicate?

Frankly, for me I think that's also, isn't just about spoken communication, but

also about how you write, how you message on slack or chat, you know, that your

written communication, the documents you produce, not overly verbose, whatever, but

really, like very bringing people along with you and another aspect of it is just

the way that you communicate technical topics, both to the team, but also to

the stakeholders and the, the engineering manager the product manager who may be

less technical, but really the ability to express complicated things in clear

and simple ways that people understand.

So that when you say, going back to your point earlier about our platform

is in trouble and it has these issues, people understand why you're saying it

and they, they can make, and you can create space to actually address those

topics and not just be, doom and gloom.

Péter: Okay.

So that's, that's, that's a good summary.

Maybe before we summarize everything on the topic, cause we are,

we are running long as usual.

What would you advise to an engineering manager?

Arguably our target audience who has someone on their team who's on nearing

the senior level, how, how should they approach this this challenge?

Jeremy: The first thing I would say is that a lot of people in that situation

think about it in terms of time.

And I think we need to adjust junior people's expectations on the time.

Secondly, I think there's obviously an evaluation that you need to

do between yourself and them should be really driven by them.

And all of this is driven by them.

They're not.

It's not like you're going to make them do this.

It's a key thing is that they need to know, you need to help

them know what they need to do.

And then they need to act and own their own career.

You and I, Peter, I think are both deeply aligned on the strengths based approach,

which is, Focus on your strengths.

No matter your personality, I think you can achieve what we described

here through your strengths.

There's very little return focusing on someone's weakness.

So find the compensating strength.

Also, time is needed simply to be able to have enough situations to try and

learn and build out that experience.

And obviously that's the main thing for me is just then as a manager, if you're

helping them is help them have more of those opportunities to demonstrate

what to give them that big project, and have a mentor that goes along with them

and use that task relevance maturity kind of scale on the, in different

parts of what they're doing to adjust your level of coaching, I would say.

Péter: Okay, I like this approach and staying on the time aspect because as

you said, a lot of people focus on that.

How do you react if you're, you're a manager of someone who's very

ambitious saying that, look, there are these four aspects that

you mentioned half a year ago.

I, these are three examples for every aspects that I've been

displaying the expected behavior in the last three months.

When is my promotion coming?

What do you say to that?

Jeremy: If they're really so, I'm assuming in your scenario

they're not like fully there yet.

Péter: I mean, arguably they, let's, let's just say they

are there since the last week.

So

Jeremy: Yeah.

Péter: stretching this example is, is the point that there is

some time aspect that's necessary.

As you were saying, not enough opportunities maybe, but

where, where is that timeline?

What, what, what is realistic for, for someone to get promoted to the senior.

Jeremy: So that's the important part.

I think about what we just described.

It's not a one one off demonstration.

I think you need to demonstrate a sustained period of time.

All of these characteristics.

And so it does take time to get to what I call a true senior level.

Now, in some companies, they might've already called you senior, but

you're not ticking all these boxes.

And that's just how some companies do things.

But personally, for me, it needs to be sustained over a

significant period of time.

And and that's the expectation we should set.

We should be very encouraging of that person and say, you're starting to

show everything that we talked about.

This is brilliant.

Now let's try and find you more examples so you can really nail

this down over the next year.

Péter: Yeah, I I love this kind of messaging because it focuses on the

on what good looks like and giving positive Reinforcing feedback about

the behavior we want to see and at the same time Paints a good picture for the

future about how to how to get there.

Awesome

Jeremy: I mean, it's a balancing act Peter, right?

In some situations you might be this is someone who you can

really see their trajectory.

It's just one way it's going brilliantly.

I think in some of those scenarios you, and depending on the, a lot of things

in the environment and so on, it may be okay to put them up for a promotion at

that point, especially if the promotion is a few months away and you have to

whole prepare a whole bunch of things.

But in some other cases it's not like the key thing to avoid is if you're, if

the person you're managing is in a kind of like a quick fix, I want, like they

just, they're I don't know if they've just ticked it and you're a bit, they're

a bit shaky or whatever, just don't just, you need to readjust their expectations.

Péter: I like to, I like to say in these cases is to make sure that the

person is aware that once they get the promotion, they are level two in

the game, like the expectations are much higher for them on everyday work.

So even if they had a very successful few weeks or something, they need

to know that this is going to be the baseline in the future in the next level.

Jeremy: Exactly.

And if they're struggling or if it's a major effort for them, then

they could soon find themselves on a performance improvement plan,

which is terrifying because you have one person who was projecting

themselves forward, promotion, and then suddenly they're not performing well.

So that is why we, and this is what good performance management requires,

Péter: Yeah.

They should be comfortably performing on this level before they get promoted.

Jeremy: exactly.

Péter: Awesome.

I think we did a very good short overview of this topic.

So just to summarize, I get your points.

Well, that being a senior engineer, it's really not just about time, it requires

technical expertise, team impact, business awareness, and the leadership and behavior

requirements we were talking about, so

Jeremy: Exactly.

Péter: that put together senior engineering.

Jeremy: Yeah, they make their teams better, they reduce

complexity, they de risk things.

And they're able to dive on to complex topics.

Yeah, I think, so much more to talk about.

I would love to hear people's feedback on this format on, on the topic.

Is there something that, that you feel strongly about on a senior?

Péter: Or if you have a topic that you think we should cover in, in one

of our shows, then reach out to us.

Jeremy: Exactly.

Well, folks, thank you very much for listening to us and to the retrospective.

If this is useful the best thing that you can do is to Just share it.

And if you like it, I don't know, the podcasting is a little bit

harder to do likes and all the rest, but the biggest thing for us

is literally share it, or tell us, honestly, tell us that you liked it.

Péter: Yeah.

Jeremy: and with that, you know, thank you.

Yeah.

Have a great

Péter: See you in two weeks.