Hey, a quick message, for those of you who are listening to this
episode on Spotify, I have a small favor to ask Spotify.
Now allows mobile users to rate podcast, I would really
appreciate it. If you can take a quick pass to
go to the technique Journal podcast page, and leave your
favorite show, your best rating on Spotify.
It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot.
Today's clip is from technology, you know, episode 94.
With Patrick qua in this clip we discussed Pat's latest course.
Engineering manager Essentials, we discussed what an engineering
manager role is how it differs from a tech lead role and the
common manager forces, I see career track pad, also, shared
his view on why being an engineering manager is not a
promotion. You mentioned, you just publish
a new course, engineering manager.
Essential, tell us more a little bit.
How do you come up with this course itself?
You mentioned that many people asking about it, is it in the
tech industry these days at people, having very short amount
of resources, available to be a good engineering manager, or
maybe tell us more little bit. What kind of problem are you
trying to solve? Yeah, I think it's interesting
because like the technical lead role.
The interim manager role, I would say is relatively new to
our industry. Probably over the last Ten years
that name and title has become a lot more popular before that you
might have had things like team leader or delivery manager
depending on. If you were to project or
Consulting type of world line, manager or people manager is
another type of title that comes through.
But this engineering manager role has sort of surfaced over
the last, I guess, decade with anything.
That's new. I think everyone always
struggles to answer the question of what is expected of me.
In this particular role, the wonderful blurriness that comes
along with any sort of roll and Who have not done it before.
I've been studying this, over the last five years to try to
explore. What does this mean?
How do organizations support engineering managers?
Or maybe not support the engineering managers, depending
on the type of company. And also, how does it differ
from perhaps other technical leadership roles in general?
I've been running the course for technical leaders who may or may
not be doing say people management.
And sometimes there's some overlap and sometimes there's
not I really wanted to provide some complimentary training for
entering managers to help them and Answer this question around.
What might be expected of me? How do I know I'm doing a really
great job? How do I prepare for this?
Particularly if I'm thinking about maybe stepping into this
injury management role. So that's kind of the intent
behind the training, which is really to provide support to
relatively either new people or people who are considering
stepping into this role in the future.
So they have some opportunity to actually prepare and practice
some of the skills before they find themselves in that interim
manager role. So you mentioned that people are
not clear what is expected of them.
Maybe if you can give a little bit of clarity, what is the
definition of engineering manager role and what kind of
job scope of responsibilities that they should care about.
So I'm going to start with a typical consultant answer, if it
depends but one of the articles I have my blog was talking about
five different archetypes of being an engineering manager.
I think the role scope does it depend because it kind of also
relates to an organization if they Have other roles.
They're also in terms of timing, so sometimes teams lose a
particular role. So the shape of your role splits
and then there's also just general expectations and
associations with what do they mean?
So concretely, one of the archetypes that I talk about is
like the tech lead engineering manager archetype, this is kind
of combining the technical leadership role with the people
and team leadership management responsibilities.
So, you're kind of merging those two things into the same role
and therefore, person not every company.
She has. This is sometimes you have the
pair, so sometimes you have an injury manager and a tech lead
who are expected to partner with each.
Other one is focus, perhaps around the team and delivery and
people management side. And then the other side is
really focused on technical leadership terms of making sure
that the team is using good up-to-date technology paying
down technical debt. Choosing good architectural
design patterns to meet and accomplish whatever business
system that they're trying to build, but one type of
archetype. So the tech lead entering
manager words in one and then if split them then that injuring
manager starts to look a little bit more.
Like what I call the team lead and hiring manager where they
can focus a little bit more on the people management working as
a team because they have somebody they can partner with.
So somebody where they don't necessarily need to be the
expert. Technologists on that particular
team of such, there's five different times archetypes.
I won't go into all of them, but another one, which I think is
very useful because I know a lot of Technologies for find
themselves in this place is companies who tend to do a
little bit more projects in What so either in an Enterprise where
people run projects, or if you work for consultancy where nor
working for external clients and you're effectively not really a
product team or an extension to somebody else's product team,
but you're there for a project. So no matter of time to help a
project team, achieve a certain type of goal.
They entering a manager isn't necessarily always responsible
for the people. There are more a little bit more
focus on the delivery to make sure that client expectations
are met that the team is, Is productive connected in, with
whatever client or customer that they're sort of engaging, with
to make sure that things are smooth because you're often
working with two different organizational cultures one,
which is your consulting or Contracting type of culture, but
then, obviously, you have to adapt and work smoothly with the
client organization processes might call it bureaucracy or
other type of cultural things to make sure that you work smoothly
as a single unified team, thanks for sharing this 5 archetypes.
I think, for people who want to refer more, you can check it out
in pads block. Now, wonder that people are
sometimes, not clear. I because there are so many
variants of the engineering manager role.
The responsibilities can be quite different as well, you
mentioned, just now, maybe one is more project-driven.
One is a mix of both Technical and people management.
One is predominantly team of people management.
You mentioned, a lot of times about tech lead in this
competition so far for people who may not have heard our first
episode. Maybe, can you give us a little
bit of brief? Description.
What is a tech lead? And how should it be different
with the engineering manager role?
If you split them, let's say you have a tech lead plus a team
lead entering manager archetype that in classically.
I would be thinking that the tech lead role probably isn't
going to be doing people or line management.
Some of the other responsibilities for Tech, lead
are effectively about aligning and guiding the team around the
technical direction to make sure they're all working in the same
direction. So this means that they
understand what the system architecture.
Show that they're building is working towards to make sure
that the team are using wood tools and paying back technical
debt. So they could continue to evolve
that sort of system, the tech lead in that sort of scenario
tends to be a lot more Hands-On as such.
So you need to be able to understand and mitigate
technical risk and that's kind of impossible to do.
If you're like, literally not looking at any code that people
are producing. So the tech lead tends to be a
little bit more Hands-On and probably a lot more aware in
terms of Industry Trends in terms of tools libraries
Frameworks and element practices the interim manager and that
sort of role can effectively delegate or partner with the
tech lead and they don't have to be as Hands-On as a result.
So that's one of those interesting debates that
everyone always asked about how technical shouldn't injuring
manager be like, how Hands-On. Well, once again, it depends if
you have a tech lead, that means that the engineering manager can
be less handle because they have somebody who is guiding and
making sure that people are making good decisions to make
sure that technical decisions are tie break through that Tech
lead. But if you don't have that, Lead
role that kind of gets absorbed by the entry manager and so you
do need somebody to do that, and they playing both hats from that
perspective, these days in the technology world or at least in
the startups. What I have seen, the most is
that we will have these two tracks within engineering.
One is people management part, the engineering manager path,
and also the individual contributor part which is
probably Tech lead, stop software, engineer principal
engineer. So maybe you can give us a
little bit of guide. Here is this the proper way of
structuring the engine. During roles within a company.
So it's a popular way of structuring entering a manager
roles, particularly in the u.s. to have two tracks.
Firstly, I think it's important to have more senior tracks or at
least roles supported from the technical perspective because
let's be fair, not every technologists wants to have to
deal with people topics, right? So to have hard performance
review conversations to be responsible for driving
improvements in their recruiting process, going through all your
HR paperwork when it comes to performance reviews and
promotions and appraisals. These are difficult things to
do, somebody needs to do them. And not everyone wants to do
them because some people like to be a little bit more Hands-On.
I do have an issue with kind of the, I see verse management
track though because I think people do see higher level roles
like a tech lead stuff or a principal engineer on the icy
track or individual contributor track.
But I think that is a really bad name, right?
Because it emphasizes individual contribution and in my
experience, Higher level roles like a tech lead and stuff and
principal engineer. They need to have very strong
leadership skills. And so I actually prefer to what
I described a trident model of career development.
And this is what I think is a healthy thing for organizations
where you have roles at higher levels but on the technical
leadership /. So they're not necessarily
responsible for managing people, so not the management
responsibilities, but they should be leading technical
topics. So, Give you example, let's say
you have a company, let's say that there are five or six
independent product teams. What is very common is?
You probably have a tech lead on each product team, trying to
make sure that whatever application or system or
products that team is producing is well aligned.
But if you're in the same company, you're probably going
to be sharing interfaces to penance.
He's a very common thing here. Today might be using something
like Africa. A common messaging interface to
raise events and communicate between different points.
Now, what can quite happen In if tech leads on all the teams
don't necessarily get along very well together.
Is you end up with a very messy messaging infrastructure, many
different ways of raising events.
People are just very confused about what style and things,
get, lost contracts and utterly greed.
This is where you need somebody or a role that's typically,
trying to align technical decisions across multiple teams
in a lot of organizations that might be either a show for a
principal engineer. They need to be quite technical
because they need to understand the different needs.
Technical details of the technology, some of the
trade-offs, some different options, but they really need
leadership skills because they need to be able to influence and
get buy-in and get agreement with say.
In this example, six tech leads who may or may not get along and
so you need somebody who could help facilitate and mediate and
basically the create alignment across that and that's not about
individual contribution at all. That person is not writing the
speck in the contract that everyone needs to follow,
they're not going to really get a lot of buy-in very quickly
from that perspective. Effective.
They need to be able to lead, and this is where I think the I
see is a really bad name, which is why I prefer to talk about
technical leadership tracks. There are some places where you
do need some specialist individual contributors most
companies, don't need them. Like if your Facebook or Google,
you need somebody who can rewrite the PHP compiler, like
you need somebody who can write a new programming language, most
companies don't need that level of specialization and so that
deep expertise what? I would really consider it very
much on the individual contributor line.
Most organizations don't need people in that role but you do
need strong technical leadership.
Particularly when you're trying to align across other strong,
technical leaders to make sure that there's some alignment from
an organizational perspective. Thanks for sharing that scenario
because they are. You do agree that sometimes this
stuff software engineer principal, they think that their
focus is actually to solve one particular problem with that
actually aligning with different teams.
So, I think I like the Trident model that you mentioned.
I think, That kind of gives a framework that people at that
particular level even though it's individual contributor,
they still need to kind of like have leadership and influence
among the other Engineers within different teams.
One common phrase that I always hear about engineering manager.
It's not a promotion, because sometimes what happens is that,
as you go along in your career, Journey after five, six to ten
years, you get promoted as an engineering manager but people
refers to it as a not a promotion that is just a
different role. So can you give us a little bit
more about your thoughts? On this if it's not a promotion.
Then when should we nurture people to go into this
Engineering Management role? My conceptual model with Rawls
is it's like a container. There's things that your group
together in a container and these are simply a set of
responsibilities. So I think this is interesting
because if we think about, let's say a developer, a senior
developer is kind of doing more of the same type of
responsibilities. So a lot of the skills and
experiences translate into the next level of Of scope, you take
a problem, you know, how to break that problem down.
You know, how to design code and modularize that code, you know
how to apply good humming so you can break it up.
Keep it maintainable, have some good tests and deploy a really
nice product that's working. So a senior engineers and to be
able to take a slightly more complex problem, do more of that
and apply a lot of the same sort of skills.
The reason why I think a lot of people describe this as not a
promotion, is because fundamentally a lot of the
responsibilities in this new container of being an interim.
A fundamentally different type of activities and so, you may
not have built many of the skills and experience necessary
to fulfill the responsibilities that come associated with that
particular role, a good mental model.
I also like to use here is a bit like role playing games.
So a very common thing in RPGs is you get like skill points
that you consider allocate across stuff, maybe as a
developer, let's call them. The warrior class is that you
are cleaning all your points to attack.
And all these kind of things that go with worry class, but
actually the interim manager role is a bit more, like a
priest kind of class, right? It's like a support class whose
job is to help support all the team.
You've not allocated any points to Healing type of Magic's, or a
safety type of, Magic's, or mediation, very important, as a
result, when you step into that new role.
You're basically starting again from scratch.
I think kind of a big thing is that there's not a lot of
overlap sometimes. There is, if you're that Tech
lead entering manager, but there's a whole bunch Some new
skills and responsibilities that you may not have built skills
and experience it. As a concrete example as an
engineer, it's quite common. That many people might get by in
their career without having to deliver very difficult feedback
like to tell somebody about their behavior to deliver in a
way such that they're receptive to this and that they
acknowledge perhaps the impact that their behavior is having so
that they have an option to actually change that behavior.
If you've never practiced that, of course, the first time you do
that, Is probably going to be bad and awful, right?
It's going to be not great for the person, receiving it, and
not great for you because probably you're going to also
react badly to how that other person is reacting badly.
But that example of a skill is something that interim managers
need to be able to do all the time.
Maybe you're lucky, you work in a team where somebody else has
taught you how to give effective feedback.
It's a very common thing that you swap and exchange feedback
to other team members in my experience, that's not
necessarily a key responsibility that you see on a job
description for developers. So, A lot of people might go in
their career without having to go through that experience.
And therefore, when they fall into that interview manager
role, they maybe haven't built up that skill and experience.
I think this is one of the things with that, not a
promotion, but a role change because you probably be building
a lot of new skills and responsibilities to fulfill them
very well. Now I think a lot of people
might feel a bit scared about this but I like to also view it
as it's a good growth opportunity.
I think if you're a developer you've built a certain type.
Of system at some point. You kind of going well, all I'm
doing is really like moving data from one place to another.
That's all I'm really ultimately doing.
This is actually an interesting challenge of dealing with some
new skills and a good learning opportunity and growth
opportunities. Well.
So there's a good reason to be able to do that if you want to
move in that direction. By the way, I like your RPD
analogy. I think that kind of like
resonates well with Gamers, I guess.
If this is the case, right, there are so many new
responsibilities that you need to be aware of and maybe Master
along the way when you H+ a assume that someone who just
graduated becomes an engineer. When should they think about
trying out to be this engineering manager or when
should the company decides, okay?
This person should actually become an engineering manager or
should this person continue along with that?
Individual contributor track. Yeah, it's a great question.
I think what I tend to see is very common in careers worth
Frameworks. Is you kind of need some
experience building software in different types of teams and so
this Is where I think sometimes instead of plans, you have
somebody that's been working in technology, is there for like a
year and then they get pushed into an interim manager role?
I think that's a little bit too early and I think part of that,
is because it's difficult to understand the complexity of
software list. You've seen a number of
different. Scenarios worked with different
types of teams, you can do, okay?
But you're probably going to struggle to really understand
the variance and the difficulty of nature of that.
What I do see quite commonly is spending some good time, being
an individual contributor. So, you're a team member, you've
Maybe In different types of teams worked on different types
of systems. So you get a good flavor to
understand what possible scenarios people might find
themselves. And so, if I think about this
growth path from that side, let's say, you start off as
being a socio software engineer moving into a software engineer
into a senior engineer. And that's typically the sort of
movement path, where you might decide to go more into technical
leadership so stay more Hands-On.
Guiding architecture. Technology choice, or maybe to
move into an engineering manager.
Particular role focusing a little bit more on the people.
Element and team development and the environment.
I think that's a good level because it means that you can
better empathize with the challenges that your team.
We're going to have, I think it's very difficult if you move
too quickly into the engineering manager role, to really
understand the problems that your team of face.
Of course, empathy is like something.
Some of you might be really really good at but I think it's
a lot easier if you've actually lived through some of those
scenarios and when people come to you about these situations
you just instantly know exactly what challenge they're sort of
facing. There's something about having
Some of those same scenarios that you could know how to solve
that, I think the other suspected is, you know, as an
individual contributor. Sometimes you get to work with
really bad and training managers.
And this is actually I think what helps form, good
engineering managers because people go, oh, I don't want to
ever work in a team environment like that.
If I'm that role, I can avoid that.
I can intentionally thinking about these people that I've had
to work with and go. Ah, this is really painful.
I can actually create a great environment for that team so
they can imprint the opposite pattern and therefore be a lot
more effective. If you've never experienced a
bad injury manager, that's going to be really hard to do balmy.
One way that I always advise for people who are thinking of
becoming injury manager, is the first test will be, do you like
working with people? Because sometimes, yeah,
managing people is different than managing could basis.
I hope you enjoyed this short clip from technology, you know,
favorite playlist. If you find this episode useful,
please help. Share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you want to listen more
from this conversation, please go back and listen to the
original full conversation with my guest, stay tuned for the
next technology, you know, episode.
And until then goodbye.