Jeremy: Hey everybody.
Welcome to another episode of the retrospective Peter and I discuss all
things engineering, leadership, and as always, I have Peter here with me.
Péter: Hey everyone.
Jeremy: And Peter as we do these kind of these episodes, we take
turns talking about topics.
This week it's your turn.
So tell me a little bit about the topic that you want us to talk about today.
I.
Péter: Yeah, I, I think this is something that's very topical.
A lot of friends and colleagues talk about this.
The question is, should engineering managers code if you look at the job
market, you see almost all the EM positions, especially line managers.
But even on higher levels, they require some hands-on coding or some kind
of hands-on technical contributions.
I guess I. You can say this is the result of the high pressure era, the
wartime mode, if you will where companies are forced to be more efficient.
They're looking at performance, they're looking at efficiency.
And one of the solutions a lot of companies are implementing is.
Cutting some hierarchy and making managers code.
Sometimes again, 'cause that used to be the case a long time ago.
And the other reason for this era is AI getting popular or LLM assisted
coding where they're trying to set up organizations with less junior
developers, more senior developers who are utilizing the help of lms.
And the assumption is that the more senior an engineer is,
the less management they need.
'cause they, they're already senior, they know what to do.
I don't really agree with this part, but, but this is still happening in the world.
So all these point to the directions that, yeah, actually maybe
engineering managers should code.
So I thought this is a good topic to discuss.
Maybe there's gonna be something we can even disagree in.
And and yeah, I'm very curious of your opinion.
Jeremy: I definitely see this trend.
you know, when we were in the, high growth money was free era and the
kind of like in that startup bubble, or I think I would call it like the
VC bubble of like endless free money.
managers were definitely a critical part of hiring and growing and scaling, and
spent a lot of time doing that.
Whereas now we, in the, the post zero interest period
where there is no free money.
Péter: Yeah.
Jeremy: You need to perform.
It's all about results.
And now the focus for managers, as you call it, you know, it's this
wartime mode where it's, it's about delivery and results and, and now
we're saying everyone needs to code.
And yeah.
I wonder also, Peter, if you think that part of what's driving this is this
idea that if a manager is coding, then I have an extra developer, I have an
extra productivity in the organization.
Mm-hmm.
Péter: watching it like every week.
How it's getting closer, justifying a role.
That doesn't have immediate impact and immediate contribution.
It's really hard.
I can empathize with that.
I can really, really feel the pain that CTOs must have in this period
when they would advocate for a hands-off engineering manager.
Jeremy: Yeah.
Yeah, yeah.
Maybe it's worth then talking about what we think the role of
an engineering manager is first.
'cause I think that's a good way to like level set as we go into this as our
lens of what we see that manager just.
Péter: I agree and I will connect it to my point that I don't think
engineering managers should code, but, but that should be the outcome
of what I'm about to explain.
So I think an engineering manager has three main areas where they
can create value for a company.
The first and arguably the most important is.
Being responsible for the execution in the team to make sure that the
team is delivering outcomes that are aligned with business goals.
There's a lot to unpack here, but what I'm trying to say is that the EM is
responsible for the outcome of the team, from the technical outcome of the team.
And this includes also, inter-team connections discussions with
stakeholders, discussions with other functions other teams, et cetera.
So this is, this is the first main leg.
Like I, I just call it execution management, but
there's a lot of stuff in it.
The second big,
Jeremy: on that, I
the way it's framed in a book about management called When They Win You Win.
And I'm trying to remember the name of the the author, but I'll
Péter: We will put it in the show notes.
Yeah.
Jeremy: He, he, the way he articulates this is deliver a result in line
with what the business needs.
Péter: Yeah, that's, that's, the easiest way to say it.
Yeah.
And and this is good because it avoids a lot of traps.
Like this is not about what you as an engineer thinks is a good result.
This is not like, yeah, a lot of decisions can be extrapolated from this statement,
but that's like, that's one main lag.
The, the second main lag or the main area where a, an engineering
manager can provide value is.
Just paying attention to team health, building up and sustaining
a healthy, high performing team.
There are a lot of responsibilities and processes within this.
It can be about ceremonies.
It can be about work distribution.
It can be about a lot of stuff, but this is about team health.
And, and, and the third one is the personal development of the
individuals within the manager's team.
Helping them to, to grow in their role, to help them set goals, to hold them
accountable, give them support, just pay attention to the personal development.
So this team execution, team health, personal, personal level.
I think these are the three main areas if you think about everything
that belongs to these areas and the potential positive impact this can have
on the business at the end of the day.
I just don't think that coding can compare to that.
I think doing a good job on these three areas most of the time is a full-time job.
It requires your full attention.
You're still gonna have to make a lot of compromises and not pay as much attention
as you would like to, to some areas.
But if you bring in coding to the mix my point simply is that the, the first
main three main areas are gonna suffer.
Jeremy: Yeah.
I'm not sure I fully agree with that because I don't
think it's mutually exclusive.
I just think what we're talking about is I. The primary objective
as an engineering manager are these things, as you say, the three things.
But if there's space you to code as well.
I think it's not mutually exclusive, but I think the view that we're
coming at is you don't deliver those things, it doesn't matter how
much coding you do, you're failing.
Péter: That's a good point.
Exactly.
Yeah.
Thanks for framing it like this and, and there's another framing: I worked a
lot with first time engineering managers and developers who became managers.
In fact, this is what I'm doing now professionally and a frequent pattern
is that when times are becoming more chaotic, when pressure is increasing,
I often see them pulling back and increasing their technical output.
If there are some delays in delivery.
Instead of looking at why the team is not functioning optimally, who might
need some mentorship, what could I do to, optimize the processes to make
sure that we can keep on delivering.
Instead, what they do is, okay, I'm just gonna take a few tickets and implement
so we can get through this delivery.
And I think this is a fallacy, I think.
People who do this, they choose this because they are more comfortable
in technical contributions.
And I don't think this is helpful for their career or the company.
So I might be a bit biased because a more experienced, more senior engineering
manager, can better judge if they have time for coding or not, and what value
it creates and where they are needed.
But I would say that if you're early in the engineering manager
career, try to play down a bit your coding contributions because you
have a lot to grow in other areas.
Jeremy: Yeah.
I think there's a few way to frame it.
Oh, there's definitely one.
And you know, if you're a junior manager, maybe you need to spend more of your
time just doing this completely new job because it's a significant shift so you
need to spend more time just these things.
I think the other kind of scale on how much hands-on coding you
can do is basically the size of the team that you manage.
Péter: A good.
Jeremy: because I think, if you're managing a small team, two, three, maybe
four people, you could actually have some bandwidth to write code, significant
bandwidth in some cases, depending on the overhead of the organization and so on.
As you get to like 6, 7, 8, I think it's becomes almost impossible to
be writing code at the same time.
I think really you are basically full-time making the team work at that point.
Péter: Yeah.
No, I, I totally agree.
And thanks for expanding the perspective to include all kind
of organizations and teams.
You're totally right.
If it's a team of 2, 3, 4 people, then I can definitely
see, especially an experienced engineering manager to code more.
And I, I think.
This is a good point where I answer the question in the episode, like, I don't
think engineering managers should code, but I definitely think that they should
be technical and there is a big difference between coding and being technical.
Let me just argue a bit about what I mean by being technical or
the benefits of being technical.
And what I mean by technical is, is somebody who used to be a developer,
somebody who used to, I dunno, work in DevOps or anything like who has
an engineering understanding who can read code, who can write code,
who can understand architecture, create architecture also, but is
not practicing this anymore, or not to the level of a developer.
But if an engineering manager has this background and they are technical,
then it just enables them to be much more efficient in the areas that
really matter according to my beliefs.
The three legs that I was talking about, like if.
You are technical, you can build and maintain trust with engineers
in your team much easier.
This whole question of having to build trust without understanding
their day-to-day problems without really understanding their work
just goes away and you are starting from a higher level already.
It's building better mentorship context.
Also, like if, if somebody on your team is struggling with
something that's technical, you can just jump in and help them.
You can also better understand the technical challenges and all the tooling
challenges they are struggling with.
You can make better technical decisions if, if you're technical.
Also, you can represent a team better in technical discussions with, with other
teams or non-technical stakeholders.
Like if there is a, I don't know, product discussion, you don't need to involve
an experienced developer from the team.
You can represent the team technically also.
And I would say that's also I. An advantage is that if you remain
technical or if you're technical as an engineering manager, you have much
more career options in the future.
We see today that the role of an engineering manager, even the role of
a developer, is shifting every day.
If you have just, you know, more irons in the fire, I don't if this
expression works in English or not.
I, I took it from Hungarian, but if, if you have more options.
Jeremy: in English and
Péter: Oh, okay.
Yes.
So then, then you, you just have more options.
And you can see if this, if you have enough of management,
you can, you can continue.
So I, I think a good solution is some kind of middle ground
approach, like engineer managers.
I think they should be technical.
I don't think they should be coding.
What, what, what do you think about this statement?
Jeremy: I'm not subscribing as strongly to the statement that you
made saying they shouldn't code.
I. Because I don't agree with that.
But I do think that they need to be technical what, we see, and I think
there's been some research on this, maybe I'll try and dig it up and put
it in show notes, is the number one requirement that people have for their
manager is their manager understands their work and the work they need to do.
And if a manager does not understand what the team and how the team
need to work, they cannot set the standard for performance in the team.
And then they cannot make sure that things are being done in the right way.
they'll mainly focus on the people and the behavioral aspects, which
is an important part of the team.
But they, I think that they will miss.
The standard of perf setting, it doesn't mean they have to do it.
Like I'm not saying they need to be the one setting it, they
need to be able to know what good looks like and they need to be
and get it.
And that, that for me is like the important part.
Péter: Finally, we are arguing because I, I, I wanna inter interrupt you here
because yes, I think a manager should be able to set good expectations technically,
and they are accountable for that, but maybe they are not responsible.
There are staff engineers in the team.
There is a tech lead in the team.
They can rely on the expertise of other people in the team and
just, get some help from that area.
Jeremy: That's what I'm saying.
The manager is responsible for making sure that it happens.
don't necessarily be need to be the one that does it,
Péter: Okay.
Then we agree.
Jeremy: but in order to do that, you might need to be fairly
technical to, to be able to do it.
Now that, that's different though, because I think then on the coding part.
I think that managers can code and be successful as managers.
It's not mutually exclusive.
Péter: Hmm.
Jeremy: I think for me it's much more of an, it depends, whereas I felt
like you were, you are coming from the perspective of generally they shouldn't.
Péter: Okay.
No, I I, if you say it depends, I, I fully subscribe to that.
I, I guess my leadership career could be summarized in these
two verse like, it depends.
There are no silver bullets to, and, and any questions, so yeah, sure.
It depends, of course.
And, and we agreed in the small team scenario already.
All I'm saying is that my beliefs are strongest when I'm talking about first
time engineering managers coming from a developer background where I advise them
to dial down the coding contributions.
That's, I guess that's, that's a software way of saying
Jeremy: Yeah,
Péter: what, what I believe.
Jeremy: the, the basic trap that first time entry managers who have been
a developer in the team is they try and code at the same amount they put
far less attention on anything else.
So I agree with that.
And then it depends on the size of the team and all the rest.
Péter: And, and it's even worse.
Like there is the impact on the manager.
They have less time and less focus on the more impactful areas.
But also there's an impact on the team.
'cause usually the engineering manager, I. Most of the time or
very often is the most experienced technical person from the team who got
promoted into an engineering manager.
If they are, keep on monopolizing the hardest challenges, The hard coding tasks.
Everything.
It suffocates the team.
It doesn't give enough opportunity to grow for the rest of the team.
So I would say if you're an engineer manager and you were a tech lead before
maybe, or staff engineer, you are doing a service to people, less experienced
people on your team, if you leave them some problems to struggle with so
they don't get used to, I'm just gonna ask the manager what to do here and
he's gonna tell me and we are done.
Jeremy: So I have two thoughts for this.
one, the test for whether someone who comes from that background
is a good fit for the manager.
need to show an aptitude for people soft skills and a desire
to grow people in the team.
And secondly, if they have that if you are in a team, you've been the
tech lead, now you're the manager.
You may not be able to just drop coding immediately, but the way that you
code needs to be about enabling other people and helping and unblocking and
eventually removing from being in that, the critical path of the delivery.
And I think that's, we, we talk about a lot, but I think that the number one rule
here is managers cannot be in the critical path for delivery of their coding.
Péter: Percent agree.
Yeah.
In fact, this is what I wanted to guide the discussion towards.
Let's get concrete, let's talk about what we.
Suggests that in most scenarios, engineering managers should avoid and
then we can brainstorm a few activities.
So I listed a few, the first one being on the critical path, that's something
that's setting up for a catastrophe.
Don't do that as an engineering manager.
It can delay the team.
It can drop them off.
The feeling of success and growth and everything.
Remove yourself from the critical path, and you're gonna have much more
options also to fine tune how much you're gonna contribute technically.
I also listed don't monopolize technical decisions.
Don't make technical decisions alone.
Even if you have a very good idea about how you would approach an architecture
or some, some technical question.
Relying on others, involving others in these decisions is a good practice
because that also removes you from the, from the critical pass.
Very similar.
Don't become a team bottleneck neither.
Even if you're , not on the critical path, you shouldn't be a
bottleneck in the team execution.
And
Jeremy: No.
In
to unblock the execution of the team.
So
Péter: Yeah, that's a good way of saying it.
Yeah.
Jeremy: you're blocking the team, you know?
Péter: Yeah.
Jeremy: then you're also micromanaging people, which people hate.
And you probably don't like it.
So you don't like it when your manager does it to you.
Péter: Yeah.
Jeremy: those are all the no-nos.
Péter: Yeah, yeah.
Okay.
And it summarizes well, like, like you have to enable the team
and not, not risk blocking them.
Let's move on to what are some good activities?
'cause I think this is more, more interesting.
What are technical activities that an engineering manager could find
time to do and that can help them?
Jeremy: So the number one thing for me is since your role is now to be a
multiplier and to unblock the team, I think a lot of the activities that you do
relate also to process around the team.
How, how the team gets its work done, the process, the tools, and so on.
so where you can apply yourself on a technical level is to coding,
experimenting with ideas, configuring tooling creating a bot to do this thing.
You know, it's not in a critical path.
It unblocks a lot of productivity in the team.
Automation.
Diving in on the where you see an issue.
Liaising around the process, which may be quite technical of how you
code, you know, code is merged, reviewed, et cetera, et cetera.
And, you know, you might be refactoring the code owners
file or whatever it is, right?
There are things that you can do that are technical and hands-on, but they,
and they multiply the effect on the team, but they are not in a critical path.
Péter: I really like that.
I really like that because it's it's actually helping the team
aspect of, of the three main areas that I was talking about.
So arguably these are your responsibilities.
I saw another thing that was working really well in teams is that the manager
participates in the OnCore rotation.
It has a lot of benefits, like it, it shows that the manager is just one of them
and, and they, they carry their weight also, but also as a manager, if you.
Are thrown into an incident, you, you immediately see how good your
documentation is, how approachable your systems are, how good your processes are.
And yeah.
So it it's also very technical to, to be able to fix an incident.
Jeremy: Yeah.
Because you were like, wow, you know unless you're deeply
knowledgeable about this, you could encounter something on call and
you don't know how to fully do it.
Right.
Or another good example about oncall that I've seen recently is, you go
on call and then you realize, wow, there's a lot of alert fatigue here.
Like there are so many PagerDuty alerts
and none of them are actually, only this one was important, you know?
And why is the team not addressing this?
And then you can take action and you can be a multiplier there too.
So I think I agree about the onca.
I think it ties to this concept of, of gemba and you know, from lean, which
is you should be spending a significant amount of your time the actual work
that you people are doing and that you're asking people to do in the team.
I.
Péter: Yeah.
I would require all my managers working for me to participate
in their teams on rotation.
In fact, if they are not, that would be a red flag, to examine.
Just briefly, I listed pair programming also.
I don't want to get too deep on this, but I think it can be a good way to
stay technical as a manager, just.
Make sure you watch out that they don't consider you as a, you know, a boss who's
always right, like be an equal partner.
Jeremy: Yeah.
Just on this.
I think the other part of paraprogramming, and it goes back to the point about
gemba, is when you encounter an issue, don't just say, tell me about it.
Say show me.
You know,
Péter: hmm.
Jeremy: go, you, can
go and say, open up the id.
Show me the code.
Let's, let's look at it together as a non-threatening way
just to understand the issue.
And then you can represent the issue far better to the,
the rest of the organization.
Péter: Fully agree.
Yeah.
Okay.
Jeremy: So I have a question for you, Peter.
Right.
We've been
technical hands, people coming from hands-on, coding
background and all the rest, but
You think , that someone can be an engineering manager
who hasn't been a developer.
know, it seems like from everything we're saying it's a mutually
exclusive, you know, even the statement I made earlier, which
Péter: Yeah.
Jeremy: you know, people need a manager who understands what
they, what they do in their
Péter: Yeah.
I mean, if I have to answer in one word, I would say yes.
I want to acknowledge that this is definitely a disadvantage.
And, and actually I think the key to their success is how much can they live with
this disadvantage and work around it.
If you're an engineering manager who's coming from like a project manager or
product manager or, or whatever else background, and you are aware that.
You have this disadvantage that you don't understand the code.
But you are not afraid to ask questions.
You're not afraid to show vulnerability.
You are not afraid to rely on expertise in your teams.
I think you can be a very successful manager.
With all the nuances we discussed, I still think that the manager has the
biggest impact is in those three areas.
About execution and team and personal development, and sure, they, they
have a big disadvantage if they don't have this technical background.
But they can, if they're good managers, they can work around them successfully.
And second, everything is learnable.
Like if they are curious, if they have a learning mindset, they
can pick up enough to get by.
Jeremy: Yeah, I think the way I would see this is you need to offset the
lack of a deep technical background by being a truly exceptional people
manager truly exceptional people skills.
And you also need to learn and understand the domain of, you know, both the
technical domain and, and, and obviously the business domain and, and I think.
The further you go in your career, the less of a It could be that
you've been a hands-on coder, I think it will follow you the way
as, as being a recurring challenge.
There are many very well known, very senior leaders out there who weren't
coming from a developer background.
But I can tell you even today where I'm a CTO of a much bigger team.
The fact that I have been a developer and can still write some code is not a bonus.
It helps me do my job better, you know?
Péter: Yeah, that's a good way of saying it helps you do your job better.
And I, I just wanna reflect on what you said about, as somebody's progressing
in their careers, this I. Non-technical lack of, of developer background
is gonna keep on following them.
I think, especially at this stage.
The biggest enemy they have is within themselves.
These engineering managers or these managers who don't have this
background, they often struggle with a lot of impostor syndrome and
a lot of lack of self-confidence.
And if they can address those issues within themselves, if they can observe
themselves and ask for help and, work around these disadvantages,
they can be super successful.
But I often see that this is deeply internalized.
If you ask, someone on their teams, they would say that, oh yeah he doesn't
have a developer background, but he just understands abstractions and can
have great questions and everything.
So he's the best manager we ever had.
And still, if you an as the person, often they will say that, yeah, it's, it's
holding me back that I don't ever code.
So yeah, focus, focus on yourself if you're in this role.
Jeremy: What's interesting is I've seen some amazing people make the
leap and helped some amazing people make the leap into managing, entering
teams coming from non entering.
I. Background, they worked in engineering.
I've seen some people do this more from a qa, which is slightly adjacent depending
on what kind of QA you've been doing.
seen people coming at it from like an project manager, agile coach,
side, and yeah, it can work.
Say though that, the, there is a difference between men and women in this.
tend to be more overconfident of themselves and women tend to be
second guessing their capabilities a bit more and feel like they need
to know everything inside and out to, to say they can really do it.
I mean, we're all different, but that definitely means that it's
more likely that women coming from a non-tech background also have
more imposter syndrome, as you say.
And, and they're
impacted by, by this, yeah.
Péter: This is such a tragedy because oftentimes you see that they are,
they are stellar managers and, and all their soft dots and everything
just, it's really just within their heads.
So
Jeremy: because they bring a dimension of people management, people, leadership soft
Péter: empathy,
Jeremy: empathy,
on.
That's important for the organization.
So,
Péter: Yeah.
And sometimes even hardcore like project management skills, like I
saw a non-technical project manager, she was so efficient in breaking down
tasks, like very technical tasks to small pieces and, and just having
the right isolation points and.
Yeah.
So if you're a woman listening to us and you're in an engineering manager
role without a developer background, you, you can be super successful.
Like you can totally compensate for that.
Jeremy: Yeah.
One thing I think that's worth talking about here when we talk about engineering
managers and coding Peter the pendulum
Péter: Oh yeah.
Thanks for mentioning.
Yeah.
Jeremy: And like, what I, one thing I see is that managers who insist
on coding they do it because.
Coding and I miss coding all the time.
Coding is rewarding.
Péter: Yes.
Jeremy: are in flow.
You have more unbroken concentration, deep work time.
You have a feedback loop that's really fairly instant.
You know, you, you write something, you see the results.
You can make
Péter: that's big.
Jeremy: and with people.
It's not the same.
It's slower.
You know, you have politics, you have frustration.
You why can't this person not get it?
Why, why?
You know, why, you know, it's a battle of opinions.
It's all these things that kind of really drive you crazy.
Right.
Péter: Yeah.
Jeremy: and so some managers definitely default back to
coding to escape all of that.
I'm just curious your thoughts on, that and the, and the career
pendulum and, and all the rest.
Péter: Yeah, I think back, a long time ago in order to progress beyond the certain
point, you need to start managing people.
Like in, I'm talking about nineties, two thousands,
that that was the unfortunate case and then.
Dark on the realization that, oh, wait a minute.
No, you don't have to.
Like, there is something like a technical progression.
You can be a, a staff engineer, principal engineer distinguished fellow, whatever.
Like you can grow a lot in, in purely technical areas without managing people.
But still, I think up until now, people think that, okay,
so there are these two tracks.
But these are very distinct.
Like you need to make a choice and just stick with managing people
or just being a technical leader.
And that's not the case.
There are a lot of successful people who are doing a year or two or three of
one and then going back to the other.
Sometimes they just try out management for a year or two and they realize,
oh, actually this is not for me.
And they switch back to staff engineer, principle engineer.
But there are others who, who are keep on swinging, like the pendulum.
A few years here, a few years there.
If you spend some time in the other track, you picked up a lot of very
valuable skills that will make you successful in your current role.
If you're technical, if you managed people before, that can be a huge help for you
in your soft skills, in empathy, in in communication, everything, and wise versa.
If you're an engineering manager who's been a successful staff engineer.
We just talked about being technical, how much that can help you and enable
you in your engineering manager role.
And one more respect.
The current job market, as we said, everything is changing now.
There is a big need for developers, technical contributors, less need for
non-technical engineering managers if you are swinging back and forth.
And if you're keeping some technical lag as an engineering manager.
You have some carrier safety.
You're more future proof in your career.
Jeremy: Yeah, I agree.
I think one of the best staff engineers that I've worked with
was a for a long time and then
back.
And what I see a lot of where we're hiring for staff engineer right now
at Kit Guardian and I. There have been a number of very exceptional
candidates who've interviewed in past our technical interview with at least
with us, who were actually wanting to swing the pendulum back out of
management and into technical leadership.
So I would say you are spot on when you say that, when you're in that.
Sort of manager to senior manager range, and you're also
still keeping hands on skills.
You give yourself a lot of career options.
And it might be that, you know what in this kind of current environment,
I'd rather be an IC or in this company that I'm at, I think actually
I'd prefer to be an IC or, yeah, there's, there's lots of reasons why.
People are
Péter: Yeah.
Jeremy: And frankly, the other reason is there are less manager jobs out
there, as we talked about earlier.
And and people get laid off.
And so if you've created the optionality then you can apply for those senior roles.
Péter: Yeah.
Yeah.
But this, this, this is the point of what we are trying to say.
That this is very temporary now and nobody knows how the job market's gonna
look like in, in two years, five years.
And if you are keeping your options open and you're keeping experiences
in different areas, then you just naturally are gonna have more options.
And it's not just external, it's internal.
Maybe you think that management is really for you, you love the big impact.
You love to get stuff done through others.
But you try it for a year or two or three, and there are some layoffs and
there are some hard decisions to make and the burnout and you miss the code.
Maybe your preference, personally is to just, I, I, I don't want to, with
all this management things, and I just want sit down with an editorial code.
Jeremy: yeah, yeah.
Fully understand that.
Péter: Alright.
Can I have a question?
You're actually a CTO Now at git Guardian, are your managers coding
what does it look like in your company?
Jeremy: Yeah, question.
And so GI Guard is a highly technical company.
You know,
Péter: Hmm.
Jeremy: is still coding.
and the
Péter: Okay.
Is it good or bad
? Jeremy: I think it's really good.
Péter: Yeah.
Jeremy (2): He's not coding on the critical path, right?
But you know the more.
who are in, in senior roles that can code, that can have that
deeper technical understanding.
The better for an org.
I mean, we're not a huge company.
You know, we're a hundred and 130 person company, engineering and product and
engineering is about half of that.
So yeah.
And we have small teams, mostly small teams, some a little bit bigger.
Most of the very small teams, the NJ managers are hands-on.
I would call them hands-on NJ managers.
code part of their time.
and depending on the period of, of the quarter, they have less or more
time to do that if we're going through the planning for the next quarter,
setting goals, all of that stuff.
More meetings, more things to do.
If we're kind of in, in the thick of, reviews, performance reviews,
then again probably less time to go.
But yeah, our managers are mostly hands on.
When the teams are bigger, then the managers are hands off it's
just because they don't have the time to write code and, and manage.
Like we've talked about the senior managers.
The majority of the senior managers that I have that manage managers, two out of the
three are founding engineers essentially.
And they've grown up through the management side.
And so they are spending a significant amount of time still, I think,
close to the code or in the code,
Péter: okay.
Jeremy: unblocking people helping people.
They're not really coding stuff on the critical path or taking path projects,
but they definitely are able to unblock their team significantly because of
their technical ability and to coach.
Managers and so on.
So I see it as extremely valuable.
We, I. Treat the tech lead role and the hands-on engineer manager
role as two separate things, though they can be the same person, but
the tech tech lead within a team is very much of a, a, a role or a hat.
I. That someone
Péter: I see.
Jeremy: And yeah, we have some managers who were the tech lead who are in that
growth curve of growing someone else to do that and getting that knowledge out of
their head and into, in, you know, hiring and, and getting that into other people.
I think we, we are definitely on the side of mostly hands-on
engineering managers, very hands-on and on the levels above as well.
Yeah.
Péter: I never thought about this, but actually it makes total sense
that, as you mentioned, you, you have a very technical product.
Other companies where the product is not so technical, the engineering
managers might do a little bit instead of a little bit of coding.
Maybe they do a little bit of product work because the product is more approachable
for them than, I guess what I'm trying to say is that in your company being a
successful engineering manager, you need to understand the product very well.
And since this being a very technical product, I guess it would be magnitudes
harder for a non-technical engineering manager in your organization.
Jeremy: Yeah, because even for the product managers, they need to have
super strong technical background because essentially what we do is we, I. Scan
for Secrets, API, keys, passwords, and things like that in code base.
And we protect organizations from those leaking and we
highlight when they have leaked.
What we're doing now is we're actually, I. scanning where all your secrets
are, collecting the metadata about it and telling you where things are
badly configured or where you've got duplicates, and of these kind of things
related to managing the lifecycle of secrets is highly technical.
It
Péter: Yeah, like your customers are engineering teams and, and organizations.
Jeremy: teams, right?
And you need to know ci, you need to know what HashiCorp Vault is
and how it works and identity management and all these things.
I would say that the product managers even are highly technical.
Yeah.
Péter: Cool.
Okay.
Well thanks for this perspective and I think it's time to summarize, right?
Like so to answer the questions.
Jeremy: Peter?
Péter: Yeah, yeah, yeah.
Let, let, lemme try to make something that doesn't make you wanna fight with it.
Jeremy: Good.
Péter: So to answer the question, should engineering managers code,
I would say with a hundred percent confidence that it depends.
I would say that should probably not we can agree that they should be.
Technical or to include the non-technical ems?
I would say that being technical as an EM is a tremendous advantage
compared to non being technical.
And it makes everything you do easier.
You can still do it if you're not technical, it's just gonna be harder.
In order to stay technical, you should enable your team, multiply
your team and not block them.
So choose all the actions you're doing.
Coding refactoring whatever with this in mind, like, whatever you do, it
should enable and, and multiply the team's output and not block them.
Don't be on the critical path, be on the onca rotation, et cetera.
Yeah, I think that's how I would answer this question.
Jeremy: Yeah, and
I.
think if you're in, in the audience, you're listening to
this, this can be controversial.
I would love to hear people's thoughts comment on whatever
platform you're listening to this on or on the retrospective website.
Péter: Yeah.
Jeremy: but we would love to hear from you because as, as, as you said, Peter, it.
It depends.
It's not, there's no like hard and fast rule on this one.
Context matters, you know?
Péter: Yeah.
Yeah.
But there are a few principles that we strongly believe in.
Jeremy: We don't disagree on the principles.
Péter: Yeah.
Yeah.
Alright, cool.
Well that was our episode about engineering managers being
technical or coding or not.
We are gonna be back in two weeks and if you liked it, the best you can do
for us is just share it with someone who you think would be interested in
this content because that's the biggest help you can do do for us to get known.
Jeremy: Yeah, help us grow, feed the algorithms, all that stuff.
But thanks folks.
Thanks for listening.
Thanks to all of our loyal listeners that we see coming back season.
And hope you have a great week.
Péter: see you in two weeks.
Bye.