S3:E02 - Should Engineering Managers Code?

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.

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.