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.