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.