S2: E03 - Engineering Manager Gets a New Team

Péter: Welcome everyone to the Retrospective, the engineering leadership

podcast with Jeremy and myself, Peter.

we are in the second season of our podcast and, we are adapting the format a bit to

be a bit more concentrated on one topic.

So , let's get into it.

Hey, Jeremy.

Jeremy: Hey, Peter, it's, really great, to be with you here.

And I have to say, I am loving the new format.

This is our, second episode.

And today we're going to be focusing on an engineering manager,

that's starting with a new team.

So Peter walk, walk me through, at a high level, how do you see this?

Can you give me a short summary of the whole thing?

Péter: definitely.

Yeah.

And I, I want to talk a bit about the context because the topic can be very big.

So I made a few limitations.

I'm focusing on an engineering manager staying within the same organization,

just moving to a different team.

I don't want to talk about onboarding to a new company cause

that's a whole other subject.

And also during the discussions, I think we should.

Stick to the happy path.

Like, let's not talk too much about the extremes, or niche edge cases

and just focus on the main areas.

So with these in mind, let's talk about engineering manager getting a new team.

When I think about this process, I like to refresh the role of the engineering

manager just briefly, because I will use this structure when I'm explaining

what you need to pay attention to.

I think the main role of the engineering manager is threefold.

It's.

Delivery aligned with company goals, team health and supporting individual

growth of the members of the teams.

You can argue that there are some other aspects, but I think most of

the roles of the EM can be added to one of these three groups.

So that's one of the foundations I wanted to make to kick off my thinking i'm

taking a concept from this book the First 90 days, I don't remember who wrote it.

Unfortunately but we will put it in the show notes.

But uh, yeah, there you are.

Jeremy has it

Jeremy: Michael D.

Watkins.

Péter: Thank you, Jeremy.

the first 90 days, it's a great book.

If you're onboarding to a new organization, especially if you're

joining on an executive level or manager of managers level,

because it's very strategic.

There is a concept in this book that, when somebody's going to a new organization,

the net value, the value they're providing minus their cost is going to be negative.

And their job is to move this value to the positive area as soon as possible.

So with this in mind, While you're focusing on long term impact, there are

some actions you can take as a new EM.

I will talk about assessment and challenging and everything, but

I want to say out first that it's important to focus on some quick wins.

And you can align with your manager, you can align with the team, what

these are, but the goal of these early actions is to move your value,

net value to the positive aspect.

Jeremy: I find the concept of that kind of negative value really, important

for people to understand because when you come in, the short version

is you know, unless you build trust with people and, that delivering

value into the context in your role, You're going to stay in the negative.

In fact, your stock will probably go further down.

it's super important to, have kind of early set of wins.

Péter: let's let's talk about the transition to a new team.

I think maybe the step zero is communication.

there was a decision by leadership that you're moving to lead this new team.

How do we communicate this?

I think the announcement.

If possible, there are edge cases, but if possible, I think the original

announcement should come from the original engineering manager of

the team, the previous one, the one who's leading the team now

. Obviously there can be exceptions if they needed to be fired for performance

reasons or something then, but we are sticking to the happy path.

So previous engineering manager should make the announcement to the team.

The reason is because this person has the most trust with the team currently.

And this is a highly stressful situation.

Like every change is stressful, but the change in your direct management

line can be super stressful.

And the person who has the most trust from the team can make

this stress go away quicker.

so current engineering manager, maybe if there is a, joint point in management

lines, then I can imagine a skip level like a VP of engineering CTO or

domain lead or something like this.

But, eventually, the new EM should join these talks and

just take care of the team.

when I was preparing for this, Podcast.

and this topic, I, jotted down three stages of a transition.

I'm thinking that you start with assessments, you look at how

things are, and you're trying to stay back a bit without jumping

to conclusions too quickly.

Because obviously you have a lot of context that you're missing.

Even though you were in the same organization, you don't

know a lot of the team context.

The second stage is identifying high impact, uh, efforts

where to focus on first.

And then the third stage is the actual change and operation of the team.

Jeremy: Yeah,

I think

I would add in these phases is trust.

and I would say that's like the highest priority in that initial,

especially in that assessment phase.

using it to also build trust.

So getting to know people, and we're going to talk about that in a little

bit, that is the key way, to build it.

And then, I think trust comes not only then from building up a relationship

with people and kind of, I get to know you and so on, but then trust in your

competence to do your job, trust in, you know, Your ability, and that comes also

from what we talked about, that quick win,

Péter: Yeah,

Jeremy: some kind of getting out of the negative, zone and into the

adding positive value to the team.

Péter: that's a very interesting aspect that you mentioned.

if I understood well, you mentioned one of the trust is trusting yourself

that you're competent enough to do this and this can touch on this.

did I understand you correctly?

Cause that's super interesting.

Jeremy: members in your competence.

Péter: Yeah, but it can what I understood first is that it has this self reflection

area and it touches an important subject that we're probably not going to talk

much about, but every kind of change can come with impostor syndrome and that

You're just, the challenge seems so big.

Maybe it's the first time you're taking over a new team and it's important yet

to, as you said, to understand what good looks like, have these quick early wins so

you can provide feedback to yourself also.

And through your manager that you're actually doing a

decent job and you got this.

But the more important point you mentioned was trust.

And actually this makes me reconsider the order of, items I want to talk about.

Cause my plan was to look at these stages, the assessment challenge

change, and look at the three roles of an engineering manager, the

execution team and individual level.

Instead of this order, actually, I want to start with the individuals

first because as you said, the most important part is to build trust And

to build trust you need to have the trust of the individuals in the team.

So assessment of individuals just like with other points, there is a

big advantage if you have access to the previous engineering manager.

If the person is leaving in circumstances where it makes it available for you to

have a discussion, then definitely take that opportunity and start with that.

That being said, take it with a grain of salt, because maybe

they have a different context.

Maybe they have a different assessment of the people or the team.

And, you need to draw your own conclusions and not be impacted too

much by the previous entering manager.

Jeremy: that bias, you know, like avoiding the bias in the handover

especially where you get in some kind of handover, you have some level

of question mark about somebody.

I think it's really important to use actual facts to validate what you were

told because so often I've found that can dramatically change the outlook on someone

when you truly assess their, you know, and, and, or even have the conversation.

it's super important to not just carry over a bias about somebody.

Péter: Lemme jump to an example 'cause I think it helps understand the situation.

Let's imagine that you're taking over a team and the engineering manager is

saying that, oh, there is this Mark guy.

He is always complaining about, tech depth.

He just wants to do refactor everything and doesn't wanna work

on product features, et cetera.

and this is a stereotype, like some not very senior engineer that often

happens that they are focusing on doing everything perfectly.

So you have this gut feeling, you have it confirmed by the

previous engineering manager, but if you spend some time with Mark.

Maybe it turns out that actually he's not wrong.

Maybe the code state is bad, and we are just very close to a catastrophic incident

that can jeopardize the entire product security wise or any other aspects.

This previous engineering manager didn't have a good assessment of what

needs to be done and where needs to be paid attention and maybe actually

Mark has a better view on these things.

So it's just an illustration, have a grain of salt with whatever

you hear from everyone because

Jeremy: Exactly,

Péter: part of the puzzle.

Jeremy: and just for me, the really important thing is when you get told

stuff, don't just accept it verbatim, validate it for yourself, write down

to validate this, to validate that.

And that means you need to dive into the code.

You need to dive into lots of things that go on.

assessment phase, you're going to come on to some of the other areas

of it, It's got to be hands on in the details, seeing stuff for real.

Péter: Yeah, I totally agree.

And just as you can be biased by others opinion, you can be biased

by your own internal biases also.

And if you're aware of those, that can be very helpful.

But moving on to the transition of an engineering manager and talking about the

individuals, thinking how best to assess an individual when you're taking over, I

would Say that managing people, leading people, it's built on personal trust.

And in order to have personal trust, you need to have some kind of

personal connection with the people.

So while it's tempting to jump onto the actual cases, code health, career

paths, everything I would advise.

If you take over, I think just spend some time to get to

know the person a little bit.

What do they like to do?

How do they like to work?

There are a lot of.

important, almost bureaucratic aspects that you need to go through.

But in order to be efficient in this transition process, you need

to have a personal connection.

So I would say a first introductory meeting that's not very structured, just

break the ice, get to know each other.

It helps if you already work together because you're in the same organization,

but even in that case The whole relationship is changing because now

you're going to manage that person So yeah, you need to have a good

personal connection, and then you can move on to the more professional

parts of the discussion I don't want to go too much into details.

I think A few things that can help look at the previous, feedback cycle document.

Like if the person receives some feedback, get access to it, and

even before you start to talk with them, get a high level overview

try to find some external feedback.

If they had, try to find if they were on pip before, if

they were recently promoted.

Anything that can shape your understanding.

And when you start talking, your goal should be to figure out.

The strengths of this person.

I recently wrote on my site about the yearly feedback cycle.

And I had the chance to explain that I'm a strong believer

in strengths based feedback.

I think the best way to motivate people to do amazing stuff is

understanding their strengths and showing them how they can use them.

So naturally, I think when you're taking over the leadership or management

of a person, you need to be aware of their strengths very quickly.

Jeremy: Yeah.

And this is the kind of thing where you end up finding out about maybe some

of the challenges they have at home or whatever, that it can impact their work.

Péter: Yeah, or professionally also, that's, yeah,

Jeremy: Yeah.

Péter: what are, where are they in their career?

do they have a near ambition to get promoted?

Have they just recently been promoted?

Are they just happy where they are, which is also fine.

you don't need to keep on getting promoted every second year.

just, get a feeling of what the work with this person be like, and also.

with every area, figure out if there are immediate fires, like if the

person has a horrible relationship with someone like the product manager,

for example, somebody key on the team, make sure you're aware if there is

something that you need to prioritize to solve first before other areas,

Jeremy: Okay.

Péter: being said, Unlike other areas, I don't think you should change many

things within individual management.

I think you should just show support and almost take their context without

validating, but accept that this is their context and that's how they are feeling.

The reason is that it's a new situation, it's very stressful for them.

you really don't want to come in as the new manager who changes something

immediately because that makes the trust building goal very difficult.

So the order is build trust first.

And once you have the trust of the person, Then you can suggest some

things to change, like how they approach prioritization, what is

their communication style in merge requests or all kinds of things

that you are burning to do quickly because they seem like quick wins.

hold yourself back a bit, show some restraint because the first goal with

the individual is to build trust.

Everything goes after that.

Jeremy: yeah, just, you know, small anecdote.

I recently started a new, job as CTO and all of my first meetings with

people were pure, personal introduction,

Péter: Great.

Jeremy: on just getting to know each other.

Only a little bit in that first meeting was really focused on the

wider part of the company or so on.

It was really focused very much on, their, you know, journey in

the company so far and, and so on.

And,

we had maybe a little bit at the end of that first, meeting

about the company context itself.

But, I think it's, it's, this is the, if you, if, if you skip this, you are

probably going to have some real issues.

Péter: yeah, definitely.

It's everything you want to do is going to be much harder and it's just

going to get easier if you manage to build trust somehow later, I would even

advise that if you're not working in a distributed company, go out for a

lunch, for coffee or something, move the context of the discussion a bit

away from the professional setting.

You don't need to overstep boundaries and have overly prying questions, but.

Sharing a meal with someone is a great way to connect and

start to get to know someone.

Jeremy: Yeah, this starts to touch into the team aspect that you're going to

Péter: that's exactly what I wanted to do.

Jeremy: thing I was going to say is that social thing can also be

as a team and some kind of early

Péter: It's a very good idea.

Jeremy: The other thing to say is that obviously these individual.

Conversations are going to lead into the second two big areas of the

assessment that you're going to talk about, because some of these individual

conversations are going to pop up topics about the, how the team is

operating or the company and so on.

Péter: Yeah, definitely.

and this,

you lead to my point.

Cause, in the wider context, I believe that the smallest piece

that you can judge the performance of in an organization is not the

individual, but the team and the engineering manager is part of the team.

As long as you don't have this trust from all the individuals, you cannot

really be a fully part of the team, and you cannot really start to address

the performance issues from the team.

So let's talk about the team a bit and how you can do the assessment of the team's

workings and how they are as a team.

you, as you mentioned, definitely do some interviews, talk with all the

individuals and start to get assessment of the team workings once you have some

level of trust with everyone on the team.

Things you can look at is the software development life cycle processes, how they

are managing tasks, how are they doing planning, what issue management tools are

you using and how they are using it, how the code repository is built up, etcetera.

What kind of ceremonies they have, bug triage processes, everything you need to

Understand what they are doing currently before you try to change anything.

it's fairly typical to come into a new team and, start to say, but

we should do bug triage this way.

first understand how they are doing it and go a step farther, understand

why they are doing it like that.

What were their problems that this kind of operation is solving?

again, this is the happy path.

So if some processes are.

clearly not functioning and the team is also fed up with what

they have to do every week, then definitely a challenge and change

can come sooner than other cases.

Jeremy: Yeah, I would say here when you're kind of assessing and looking

at how the team is working, emotional intelligence, is super important to

sort of try and understand the dynamics of the team, who is speaking all the

time, do you have a tech lead or a couple of strong tech people how are

they, Interacting with the others, are they micromanaging them is everyone in

a level playing field inside the team, you know, all of the different little

subtleties of that little mini ecosystem

Is super, super important.

Péter: yeah, it's very important and it's not easy, because a lot

of these stuff are not explicit and they are not written anywhere.

You just see that, for example, to your point, like if there is a new

pull request in the team, who is the one who's always jumping on it first

or frequently jumping on it first?

Who who receives a lot of back and forth in their comments and whose feedback

is just hanging in the air all this kind of little information can point

to some kind of team dysfunction that you're going to need to address when

you're fully transitioned to an EM role.

Yes, yes.

Jeremy: you're a manager in an organization going to a new team

in the same organization, because you understand what's going on.

The dynamics of the org and how the history of many things in

the org and how we do things.

Whereas if you're a brand new manager joining a new company, you should be extra

cautious, Of how that team works and not just try and say, Oh, we should work this

other way that you've seen somewhere else.

You should take a lot of extra time to understand.

Is this specific to the team?

Is it the org does it a certain way?

And really, Yeah, you know, just try and parse through

that and be sensitive to that.

So, yeah, because if you're, if you're, if you've been in another team in

the same org, you can come in and you can say, Oh, that's different.

might be able to make a change that's easier because of that or not, or you,

you know, whatever it's, it's just being sensitive of the differences of that.

I think I've seen a lot of new managers to a new org in with a lot

of changes that actually go against how we're trying to do things, in the

org, because there's a logic to, to the particular way that we do things.

Péter: Exactly.

And you need to understand this logic first.

You need to understand what motivated the previous person who set up

these processes, to work like this.

I would take it to the extreme.

even if you come in as new and start to have new ceremonies and new processes,

everything, Even if you are right and this is the right thing to do, I would

say that you have a high chance of failure because you didn't have this trust level.

You didn't have this understanding.

You don't know what was the context.

and it's going to be just really hard to implement something new

without all these fundamentals first.

So hold yourself back a bit and understand what's going on and why are they

doing things that seemingly weird way.

Jeremy: Yeah, so we move on to this sort of the third pillar

that you talked about and

Péter: I wanted to mention just something because I thought about this

a bit this quick wins topic, you know, that we talked about that this is

the exception and there are some good typical first candidates that you can

look at that has a potential of winning.

Doing a quick positive impact.

I listed a few stuff like the number of work in progress this is a typical Sign

of a struggling team when they are working on too many things at the same time If

you can confirm this quickly and that's something that's fairly easy to confirm

because you see how many Tickets are being worked on people are complaining

about it You're the new manager.

You can make a decision and say, okay, I help you prioritize.

Don't work on this.

Only work on that one little thing now.

And once you're done, we'll move on to the next . So this is one

of the quick actions you can take.

You can increase the amount of pair work.

That's usually helpful in a team.

Also, you can look at how bugs are handled, Cut some unnecessary meetings.

We are veering into the area where it's maybe not a good idea to do it quickly,

but these can be candidates in quick wins.

, Jeremy: Absolutely.

Yeah.

Um, and you know, if you're gonna do anything, introduce

it as an experiment first.

Péter: Oh, thanks for mentioning that.

Jeremy: to do it.

It's just, you know, you discuss it, have a hypothesis.

You present the idea.

if people kind of onboard, just run it for a short period

of time, then revisit it and

Péter: I love it.

Jeremy: of thing.

Péter: Yeah.

I love it for so many reasons.

So at first, the obvious is that if you're wrong, then it's easier to backtrack.

But the other thing is that it promotes this safety to fail mindset.

And promotes the focusing on the learnings instead of what

we are actually outputting.

So yeah, I really like this framework.

Like this is an experiment.

Let's try working on one thing for this one person, one thing for this weekend,

see in a week, how it worked or less try you to working together all the

way to this week and see the results.

And if you frame it as an experiment, you can increase the trust of the team.

Jeremy: Yeah, and don't do 10 experiments at the same time.

Basic scientific

Péter: Exactly.

You have no idea what worked and what didn't.

Yeah, only change one thing at a time.

Jeremy: Yeah,

Péter: Okay, let's talk about delivery.

Actually, sorry, I had one more thing that I remember the theme that I really like.

I didn't use it personally, but I saw you using it.

This, social contract or team contract.

I, can you explain it briefly?

Cause I saw it working and I was amazed at how strong it can be.

Jeremy: Yes, I think fundamental to any team working well together is a

written down social agreement of how you actually plan to work together.

I think it's actually foundational for every team to have a

social agreement in place.

And I think you can call that a social contract.

I've seen some others, but basically this working agreement of you do things

that covers, maybe times of when you do meetings, how you turn up to meetings,

how you handle being late, common working hours of the teams, what's expected

in terms of responding on a chat.

it's a living document,

Péter: Mm hmm.

Jeremy: document that you should revisit during the team's

retrospectives and update over time.

Péter: Yeah, I saw it working in one of my teams and I saw it being very powerful.

It even had some values and principles and that was just a very good

document to get back to in case of any conflicts or misagreements.

I really wanted to capture that because I think that's useful to close it.

Jeremy: on, the social

Péter: Maybe we should do a whole episode.

Yeah.

But let's move on to the delivery part.

this is where While in the assessment, you need to get a lot

of inputs, you need to get in the assessment of the team performance.

I think one of the most important points is getting the feedback from the

team, asking how productive they feel.

How do they feel about their performance?

What do they think are their strengths and what's holding

them back equally important is.

Doubling down on your relationship with the product manager, or if

you're working in a triad, UX design, leader, to understand really

the delivery context of the team.

And then you should focus on.

Not just the product scope, but in time also, like what was the latest

release, what problems you were trying to solve, what are we working on now?

How does our roadmap look like in the future?

what is our backlog look like?

And

just immersing yourself in the whole delivery and product aspects of the team.

Jeremy: Yeah, and I mean the first two areas we talked about understanding

individuals and having them be successful, understanding how the team is working.

If you have those working, but you don't have delivery, you are gonna fail.

You will fail.

And, you know, again, you know, you probably need those

two to do the delivery part.

Otherwise you could be a pretty tyrannical engineering manager that nobody

Péter: Yeah.

Jeremy: You'll get found out for that too.

Péter: Well, people are going to leave your team and your company.

Jeremy: yeah.

ultimately, if you see that happening a lot, as someone who manages other

managers, you want to understand why that turn is happening.

You should usually have exit interviews.

Péter: Hmm.

Jeremy: And yeah, so ultimately this is the bread and butter of the team.

And, as part of delivery, I would also say that you need to understand

are the internal stakeholders that your team interacts with the other,

Péter: Yeah,

Jeremy: those kinds of connections and relationships depending on,

your tenure with the company.

But, those are.

Really, really important.

I just see that there's a, your role as an engineer manager is to manage the

internal stakeholders of a company for your team, whereas a product manager

sphere goes to the external stakeholders.

There's an overlap.

but

Péter: Thanks for mentioning the external stakeholders because that's what I wanted

to get at that while traditionally it's not really the role of the engineering

manager and the engineering organization to have a strong relationship with the

customer, the external stakeholders.

What I would urge every engineering manager to deeply understand who their

customer is, who they are working for, what are their problems, what

solutions we are trying to give them.

Even if you're not going to be the person who has the last word on this

area, if you know the exact context, you're going to make much better

decisions in your own engineering scope.

Jeremy: Exactly.

And that's because it's not about making sure the buses run on time.

it's about making sure the buses go to the right places, on the right bus routes.

and that means you need to deliver a result that's aligned

with what the business needs.

And so you need to understand the business and, and

critical, absolutely critical.

Péter: yeah, I totally agree.

that's gonna be one of the foundations, how your work is going to be judged,

how good of a job you did, how well was it aligned with business goals.

just quickly a few more stuff that I noted that technically, you should

get also familiar with the delivery, what the team is working on, you

should get familiar with the code base a little bit, infrastructure,

health, deployments, CI CD pipelines.

Just understand the whole software delivery lifecycle process,

how, these are building up and what condition they are in.

And finally, any kind of organization wide metrics the company's using

Dora metrics, for example, just get a bit familiar where you are.

you can look at how you compare to other teams.

You can look at how you compare to industry standards, but also look at

tendencies, if you can, like how did this number change in the last year?

what trajectory is it looking at?

All this kind of information can help you get more comfortable in your

role and also can give information to your prioritization about what

areas you're going to need to look at.

And finally, typical first candidates that you can maybe look at.

there are two areas that I really like.

The first is the work balance between tech dept work and product work.

if your team is already measuring where they spend their time, that's a

great start because that's something you can monitor when you're taking

some changes and the other one is just take a look at the backlog

together with the product manager

If you can find a few stuff, like there is a saying, at least in Hungarian, that the

new sweep is, sweeping well, I'm pretty sure there's something similar in English.

You can easily get away with saying a few things like, we're

just not going to fix this.

this is a valid problem, but it's impact is so small and the work needed

to fix it is, we're just never going to have the time to prioritize it

Jeremy: Yeah.

Péter: and just clean up the backlog a bit.

Jeremy: When you're talking back again about starting in new with a

new team and you're in the negative, I think, that's very much the case

in delivery and communication.

And, one way to get to zero is just clarity of communication

to your stakeholders.

Péter: Hmm.

Jeremy: delivery and being really on top of the current work that the team

are doing reporting of the current work and, you can get into kind of

like a positive zone here by, just shaping the way the delivery comes

out into smaller, more regular, drops.

Péter: Yes.

Jeremy: a lot of things that help the team to tell the story of what

they're doing better and to give your stakeholders a feeling things are

under control that, we're working on the right priorities and so on.

But I think this is an area where, at least by just being quickly in

the first, few weeks being on top of delivery is already a, it just,

it gives your manager of security that you're doing the very basics.

Right.

Péter: Yeah, this is important that you touched on and maybe we can talk

a bit about this explicitly is that be very well aligned with what is the

mandate you're going into this team.

what does your manager think?

You should be doing here.

what does good look like in your role as a new engineering manager of this team?

Because you might discover that there are some subtle differences

between your understanding and your manager's understanding.

And you should bring these up and discuss because that's how your success

is going to be judged eventually.

yeah.

It's also hard, like every change is stressful, but it's even harder on the

engineering manager if this transition to a new team means also switching managers,

if your own manager is changing, because then you're on both ends of this process.

Like you need to build quickly a good working relationship

with your new manager.

And I can say, maybe this is another topic about managing up and everything,

but I think what we can say with confidence is that the foundation

of it is similar with the trust.

your manager needs to trust that you're going to do a good job in this team

and you need to trust your manager that they're going to have your back and

support you and communicate transparently.

to build that trust, it's between two people, uh, just be a bit

human, understand the other person a bit, have a relationship with

them and it's going to be easier.

Jeremy: Yeah.

Péter: Okay, what else did we leave out?

Jeremy: Well, a lot, because we're,

Péter: Yes, exactly.

Jeremy: happy path.

there's bumps in, all of this.

And again, that goes back to the human relationships, the trust

that will get you through it.

Yeah.

I think, you know, that, that's the critical part,

Péter: I think I have, there is one aspect that maybe is worth calling

out about managing individuals.

The biggest fear when somebody changes manager is that their career progress

was lost and they need to start from zero again with a new manager.

It's super frustrating if you've been working towards a promotion for,

Quarters and years and you just get a new manager when you already had a, maybe

not written, but you had an implicit or implied, alignment with your manager

that, next cycle, you're going to get there and then the manager leaves and in

comes you, what do you do in this case?

I think building trust also applies here, but part of that is just calling

out explicitly saying that you can even say that I talked to your previous

manager, I Start to get your context.

I'm going through all the formal feedbacks you received I'm going

through everything and based on this i'm going to make an assessment but

correct me if I see something wrong leave it open to interpretation and be

flexible because again, the first goal you should have with everyone is to get

their trust and to get their trust you need to Ensure them that you're going

to support them in their career journey.

Jeremy: Yeah, actually, this is one question I ask, every time of both the

outgoing manager and the person separately what kind of explicit, promises, existed,

between you and your manager, whether that relates to the way they work, maybe

some exceptions, to how the company's rules are, they could be, promotion stuff

like, Oh yeah, I'm going to promote you in six months, et cetera, or whatever

it is, get that out, in this process, I think that's part of, it's really critical

Péter: I agree, the fear of this work being lost is usually one of

the big sources of anxiety for people going through a manager change.

Jeremy: So Peter, we talked about, three stages, assess, challenge, change.

And then we had, the individual, the team and delivery dimensions to that.

Péter: Yes.

Jeremy: curious if you could give me a real world example of, where you, I

mean, it may not be perfect by the book in your framework, but I'd love to hear

a real world example of, these stages being played out in a team, either

you or you've seen someone else doing.

Péter: Um, yeah, in my, in my previous place, I supported some

managers going through this change and

It sounds so trivial to build trust with the people, but I'm telling you,

this is the hardest for a lot of folks.

Like, everyone is going in, with preconceptions.

Everyone is going in usually with a lot of ambition.

they want to prove that they're going to be a good manager.

and oftentimes they want to prove it to their manager and not to the team

where they should actually prove that they're going to be a good manager.

So this building trust phase is often non trivial for a lot of managers.

Jeremy: yeah.

And my counter example is exactly the flip opposite of that.

The

Péter: tell me.

Jeremy: had a new manager come in, that's not worked out, is absolutely

where they violate trust in, the difference between do and say, in like

very early on in the whole relationship.

And, they never recovered from it.

Péter: It's hard.

Jeremy: to rebuild.

Péter: Yeah.

And it's really hard because you don't know.

What exactly are people sensitive for?

For example, I really don't like if people are not, disciplined and

precise in their, like, if they keep their promises or if they're,

not late from meetings, et cetera.

Somebody who doesn't know me doesn't know that this is a big deal for me.

So, it's hard because you don't know what will trigger some people in your new team.

And, yeah, you need to be 200 percent in the first few weeks to figure out

what are the areas where you need to consistently be a hundred percent.

Jeremy: Exactly.

Yeah.

Well, I think that wraps up this episode on, how to, join a new

team as an engineering manager.

And Peter, I found, you know, like a really helpful advice in here.

I That you do as well in the audience.

Um, if you have questions, please, don't hesitate to ping us.

We’re still a fledgling young podcast with a new format,

trying to figure ourselves out.

So you know how to, feed the algorithms to give us a boost

hopefully actually just, you know, if you think this is helpful and this

can be helpful for someone else that, you know, please, share the word.

Péter: that's the biggest thing you can do to help us.

Thank you.

See you next time.

Jeremy: See you soon.