Definitely is the top International software
development conference with an emphasis on coding architecture
and Tech leadership skills. The lineup for this year is
truly stellar and features many Legends in software development
names, such as Robert Uncle Bob. Martin can back Scott Hanselman
Franca subramanium, Carolyn honey, Alan.
Hello. Mary poppendieck and many other
prominent names including some of those who have also appeared
in this podcast before the conference.
Ernst takes place online so you can enjoy it from the comfort of
your couch. We spoke to the definitey
organizers, and I'm happy to share that technology.
You know, has got the 10% discount code for you.
Enter the promo code, awsm underscore tlj.
When you purchase the ticket on definite e.com, here's the promo
code. One more time awsm underscore,
tlj. Depending on the time when you
purchase a ticket, early price is still available.
See you there. One purpose of the interim
manager is to make sure it's aligned with whatever.
The organizational goal is an injury manager should be.
Making sure that whatever the team is working on.
Has a good balance of delivering things that the business needs.
But they're also that the team has enough capacity to do the
sustainably over time. Sometimes this means enough time
to pay back technical debt, time to invest in Learning and
Development, you know, a sort of sustainable approach.
Hey everyone. My name is Henry Surya, we
Robin. And you're listening to the
technology, you know, podcast the show where I'll be bringing
you the greatest technical leaders practitioners and
thought leaders in the industry to discuss about their Journey
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our Journal.
Hello, to all of you. My friends and my Semester,
welcome again to the technology. Now, podcast the show where you
can learn about technical leadership and Excellence from
my conversations, with great thought, leaders out there.
And today's episode is the episode number 94.
Thank you for tuning in and listening to this episode.
If this is your first time listening to technology, you
know, make sure to subscribe and follow the show on your podcast
app and social media on LinkedIn, Twitter, and
Instagram. And for those of you who enjoy
this podcast, And wanting to contribute to the creation of
the future. Episodes support me by
subscribing as a patron at technology, not Dev slash
Patron. The engineering manager role is
relatively new in the tech industry, probably over the last
10 years. The role and title have become a
lot more popular especially in the startup world and from my
experience the engineering manager roles and
responsibilities are not clearly.
Well defined and can be very different between one company.
The others, a few of the engineering managers.
I know sometimes also asked me how to assess, whether they have
done their job properly, and what are the success criteria in
order to help us get more clarity about the engineering
manager, robe. I'm happy to share this episode
with all of you. My guest for today's episode is
Patrick qua, also known as Pat Kwa path.
Is a seasoned technology leader with almost 20 years of
experience with a personal passion to accelerate the
growth. And success of tech
organizations and Technical leaders.
He was previously the CTO and chief scientist of M26 and the
technical principal consultant at thoughtworks pad.
Also writes a popular newsletter called level up and offers an
online training for Tech leaders called tekhelet Academy.
This is Pets, second appearance on technology, not podcast, and
in his previous episode 9. We discussed in depth about the
tech lead role. So, if you're also interested to
learn, More about the tech lead role make sure to also check out
episode number nine in this episode.
We discussed Pat's latest course offering called engineering
manager Essentials which covers all the building blocks required
to Be an Effective engineering manager.
We first discussed what an engineering manager role is how
it differs from the tech lead role and a common engineering
career track these days, which is the manager versus individual
contributor or icy track pad. And shared his view on why being
an engineering manager is not a promotion.
And what are some of the success criteria of a good engineering
manager towards the en pad also shared a number of anti patterns
that an engineering manager should avoid to become
successful. I really enjoyed my conversation
with Pat learning about the engineering manager role.
And it's different archetypes, the success criteria and some of
the anti patterns that an engineering manager should
avoid. If you also enjoyed this
episode, Please share it with your friends and colleagues who
can also benefit from listening to this episode.
Leave a rating and review on your podcast app and share your
comments or feedback about this episode on social media.
It is my ultimate mission to make this podcast available to
more people. And I need your help to support
me towards fulfilling my mission.
Before we continue to the conversation.
Let's hear some words from our sponsor.
Today's episode is proudly sponsored by skills matter the
global At the end events platform, with more than 100,000
software professionals here members, can organize their
learning experiences around the technology topics.
They care about most you get on-demand access to their latest
content thought, leadership insights, as well, as the
exciting schedule of tech events running across all time zones.
So whether devops our data science is your bus or you are
fan of functional programming or all things Cloud, you can make
real connections with people. People who share your interests
head on over to skills method of calm to become part of the tech
community that matters most to you.
It's free to join and you will find it easy to keep up with the
latest tech Trends. Are you looking for a new cool
swag taglit Journal? Now offers you some swags that
you can purchase online? These wax are printed on demand
based on your preference and will be delivered safely to you
all over the world where shipping is available.
Check out all the cool tracks available.
Visiting technology, one of the death / shop and don't forget to
break yourself. Once you receive any of those
Rags? Hi everyone.
Welcome back to the new episode of the package, you know,
podcast today I have a repeat, guess he was part of the podcast
journey in the single-digit, episode 9.
In fact that requires back here again to talk with me about
engineering manager. So last time we covered about
technical leadership or Tech lead per se and And it was one
and a half years ago, and one pandemic apart.
So it's been a while since I met pads after that time.
So really looking forward to have this conversation, Pat and
may be talking more about engineering manager in general.
Yeah, thanks again for having me.
I repeat a lot of things have happened since last time we
spoke both globally as well as personally.
So, I am also excited to share updates and talk a little bit
about a different topic than we talked about last time.
So maybe just a little bit background.
What have you been up to since last time?
Spoke last time you were predominantly focusing.
A lot on technical leadership. Now, you have gone into multiple
areas. So tell us more.
What are you up to these days? Yeah, so last time we spoke, I
guess like everyone was sort of adjusting to full pandemic.
At that time, it was about rebuilding training material to
run technical leadership courses online and since then I've it
sort of expanded this a little bit more.
So I've now sort of produced some self-driven courses on the
tech lead Academy. These Are aimed deeper, dive
single topics. So a very common topic for
instance is time management. So getting people to find out
how to be more productive with their own time.
Another one around learning how to communicate like a CTO.
Something that will technically does know that they need to do,
but haven't necessarily been supported and another topic
around systems thinking I've been since then.
Also working with many different, technical leaders at
the sort, upper echelons of a company.
So, ciccio's VPS of engineering. Watching them 121 through
coaching and mentoring. It really helps me sort of stay
in touch with a pulse of how tech companies are going.
The challenges that all senior leadership people are facing
since. I've been running these
technical leadership courses online.
I've had a lot of requests on supporting entering managers in
particular and that's kind of one of the reasons I've ended up
building specific material around this and trying to
compliment other training programs out there.
So there's General people management or leadership type
courses out there really Great sort of resources, but really
trying to fill the gap between technical leaders, General
people, and Leadership management, and in training
managers, as well. Yeah, and not to mention your
great newsletter level up, think one of your subscriber every
Sunday or Monday ish, I think, yeah, depending on time zone.
So that is also one great resource.
I think for all the engineering managers or technical leads out
there, 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 that
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 toy industry, probably over the last
say 10 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 role and people 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?
And Managers or maybe not support, 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
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 or responsibilities
that 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 entering 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, what are the
archetypes that I talked 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 has this. So sometimes you have the power.
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 focus 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.
That's one type of archetype. So, let's set lead entry manager
words in one. And then if you 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 people management working as a
team because they They have somebody, they can partner with
so somebody where they don't necessarily need to be the
expert technologist for that particular team as 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 technologists will find themselves in this.
Place is companies who tend to do a little bit more projects
entered work. 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. We are an extension to somebody
else's product team but you're there for a project, a certain
amount of time to help a product team.
Achieve a certain type of goal. They entering a manager isn't
necessarily always responsible for the people.
They're more a little bit more focus on the delivery.
To make sure that client expectations are met that the
team 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 don't 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 these five archetypes.
So I think, for people who want to refer more, you can check it
out in pets, block. Now, wonder that people are
sometimes not clear eye because they 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 you can you give us a little bit of a 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 attacked.
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 that they're
building is working towards to make sure that the team are
using wood tools and That 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 development
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 entering
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 hand off 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 Tech
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. 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 engineering
roles within a company. So it's a popular way of
structuring and hearing about Social 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. It's already history them and
not everyone wants to do them to because some people like to be a
little bit more Hands-On. I do have an issue with kind of
the icy 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. Poor 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 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, let's give you example.
Let's say you have a company. Let's say that there are five or
six independent product team. 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 dependencies 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, 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 the
technical details of the technology, some of the
trade-offs, and 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 can 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 little back in very quickly
from that perspective, they need to be able to leap 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 Do you
need strong technical leadership particularly, when you are
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 but it's just a
different role. So can you give us a little bit
more about your thought 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 scope.
You take a problem, you know, how to park that problem down.
You know, how to design code and modularized.
Is that code, you know how to apply good having 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 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 entering manager, 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 allocating.
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 of new skills and responsibilities that
you may not have built skills and experience it as a Kurt
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 behave. 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, In
that interview manager of all, 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 go. 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 switch, let's say assume that someone
who just graduated becomes an engineer.
When should they think? 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 in startup lands, you have somebody that's been
working in technology, is there for like a year and then the 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 less 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 seen different types of
teams. Worked on different types of
systems so you get a good flavor to understand what possible.
Areas 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
development 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, engineering manager
role to really understand the problems that your team are
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
lived some of those themes scenarios that you could know
how to solve it. I think the other perspective is
you know as 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 think 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 Mac 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. Well me, 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 code.
Bases, you mention about Bap engineering manager.
A lot of engineering managers that I know especially people
who asked me for feedback advice and all that, they actually
don't know whether they are performing well or they are
performing bad. So this is sometimes, the
abstract things are becoming an engineering manager where you
are being spread into multiple areas, right?
Sometimes you juggle between multiple things, maybe from your
point of view as a tip, should we as an engineering manager,
assess the success of our role, It's a good question.
So I think one indicator of this is making sure that the team is
delivering value. So, one purpose of the interim
manager is to make sure it's aligned with whatever the
organization goal is. Let's give you a counter
example. I remember observing a team that
was nearby when I was in Consulting.
They had a tech lead entering manager and because there are a
little bit more biased. What's the technology?
They just basically use their team as an excuse to play around
with technology. Like let's use a graph database.
Let's do this one. Here at some point.
Then manager came in and was saying what are you actually
deliver? We don't really see any output.
Yeah but we just need some more time to play around with
whatever. That's not a great ensuring
manager and ensuring manager is trying to make sure that it's
aligned with whatever the organization needs.
Now, of course, it depends on your team so you might be part
of your platform, team serving other teams.
So it's about then perhaps developer productivity across
your organization. Smoothing out the pain points
for the team's. Most people will probably be on
a product team. And then it's a question of
like, what product area are you working on?
Are you helping to smooth out customer issues?
So you reduce the number of repeated types of customer
issues that pop up. Are you working on?
Say customer registration and working on the growth Channel
there, you know, I think there are good concrete goals
depending on which part of a business, you're working in an
engineering manager should be making sure that whatever the
team is working on. Has a good balance of delivering
things that the business needs. It's naturally going to be
biased towards product if you have a strong product.
A jar. But they're also that the team
has enough capacity to do the sustainably over time.
Sometimes this means enough time to pay back technical debt, time
to invest in Learning and Development, you know, a sort of
sustainable approach. So I think any extreme is really
bad. Where if a team is always just
being pushed to produce features of the features and they don't
get a chance to actually work on some technical infrastructure.
Then at some point, their productivity really slow down or
the quality will be affected whenever they make a change.
You get Explosions bugs in production and so that's going
to be a long-term consequence. So the injury Mentor, I think is
thinking about, Are you delivering value in a
sustainable way? And that's for me a nice little
rest. I still remember last time when
you mention about one of the characteristics of a good
technical lead is actually to become more multiplier instead
of maker. Is it still the same case where
engineering manager has to be a multiplier for the individual
team members and also maybe other engineering teams maybe as
a sister team of people. As within the company.
Yeah, absolutely. So I think all leadership roles
need a multiplayer type of idea or mindset and I think in this
case, the injury manager and the tech lead might be doing it
differently. So the tech lead might be able
to say, teach people Concrete technical skills to help
multiply people. They can spot, perhaps design
errors, early and help people learn from them.
Rather than having to respond to an incident, outage can then
that helps multiply the technical knowledge.
I think What are the key responsibilities that almost
always falls onto the engineering manager is people
development. And so the way that an interim
manager multipliers their people is probably a little bit
different because for instance, one of the traits that I would
expect from a good engineering manager as they have regular one
ones with people in their team very early on.
They should be working with that person to build a personal
development plan. Where do you want to be in a
year or two years time? Do you want to be a tech lead?
You want to be detrimental to do?
You want to do something very different?
Let's start working. On a plan to start building new
skills to get there. Now some of those things on that
personal development plan might align very well with how we're
technically can actually support somebody.
But often it's more about thinking about junie's.
It might be about a specific project that a person might be
able to join at some points that pops up or a rotation on to a
different team. Which requires a manager to work
with other managers to plan a good rotation cycle.
So that no team is suddenly stopping in productivity and it
helps to set satisfy some of these needs.
It might be about working with somebody to find external
training to support someone in building new skills because you
may not necessarily have the opportunity in your team.
Environment to allow somebody to immediately practice or learn
those sort of skills, or maybe it's a completely new skill, set
that nobody has any real team, so they need to go externally to
do that. And so, that's a some of the
multiplier sort of side that I see interim managers take, which
is a little bit more broader and less focus on Technical
Solutions in order. Help multiply people?
Yeah, it makes it slightly more difficult as well in my view
because again it's more abstract and there's no clear definition.
It's like in technology. There's a test that you can do
whether it passes or not. But this time is really not the
case where it's not binary. So maybe let's go a little bit
on what you offer in your course, engineering managers and
sell us more. What will people learn from this
course? How do you structure it?
So, there are four parts. The course here, one, which is
really focused on exploring. The interim manager role.
This is really about trying to make sure that people have a
good understanding about where my very the different sort of
ideas around this. A very common key
responsibilities. I tell you, it's like clear and
say, 90% of the cases, the interim manager is managing
people. So they're responsible for
people in line management. So we do touch upon managing
people but I tend not to focus on it too much because there is
a lot more resources about General people management out
there. So any manager from any
Department should Share some level of people management
skills. Now once again a lot of
technical people may not have had the chance to build some of
the skills or allocate those skill points.
So it's important to invest in it but there's also a lot of
resources out there. I think one failing for a lot of
entering managers that I see is that they do Focus only on
managing people and so the next part that I include is talking
about managing the system. What I think about this is there
are systems of how people work as a team in software that are
more productive. It and there are also systems in
working with teams that are less productive, which means you will
probably be maybe working as a bunch of individuals rather than
as a team, this is a very key entering management
responsibilities. If you have that delivery
manager, interim manager archetype is explicitly there.
But for the other ones, you should be considering what's the
environment or how do people collaborate?
This is where, if you've worked as an individual contributor,
you should have a better sense about what practices and setups
work really well for you. You, we talk about managing the
system and this is really about, you know, if we think about
people working as a team, the engineering manager is
responsible for effectively the team process and to make sure
that you're continually improving that as well.
And so, I think a lot of people were enjoying my - forget about
that and they just focus on people management but actually
the system produces the results and so it's useful to focus on
managing the system. Deliberately the final section
that I Do cover is personal and this is really about managing
yourself. This is a very common Ogle that
everyone goes through, which is I'm new to this, or like time.
How do I deal with all of this stress?
You know, I'm having tough conversations with people, I'm
not getting out of this sleep, right?
These are all very normal. Human reactions may be as a
templating to avoid some of the more difficult people management
topics, but as an interim manager, you can't.
It's part of your respect your accountable and so you can't
really avoid some of these tough conversations.
A really key part here I think which is more important as a
manager. It's because you're going to be
accountable for it. As you can't give this to
somebody else. You have to have these
conversations. So if somebody is not performing
on your team, you need to be able to give them some radically
candid feedback to give them opportunities, to change that
behavior, you can't simply skirt around the issue.
It's going to be not great for that person and it's not great
for your team, but that's going to add to a certain level of
stress. So learning how to manage
yourself, is also really key part to the course.
It's a four-hour course, and it covers a lot of these light
touch, but hopefully gives people a good sense about a good
balance or things that they can. Focus on a lot of practical
things they can do. I like the three different
categories that you mentioned, just now managing people.
Of course, there's the first and foremost, you will have direct
reports that you will be managing and then you will need
to manage system, which I agree that many managers probably
don't think so hard in improving the systems or even visualizing
how the system look at the moment, they just go into the
motion and think that, this is always how we do.
It starting managing system agrees to really important.
And the last one, of course, don't forget to manage yourself.
Maybe. More mindful, exercise have more
coaches to help you guide you along, maybe read books,
training, whatever that is I think managing yourself is so
critical as a manager because if the manager actually is in bad
shape, all the people will get affected as well until it later.
So I think this kind of course will definitely help a lot of
people to upskill the engineering manager management
skill. I know that this role is self is
currently in demand in the tech industry.
Hiring engineering managers is actually very hard from your
views maybe last time and you work inside out.
Before as well. How do you actually gauge
someone who is good engineering manager for someone who is just
maybe as a title, only? Right?
Good question. So if you're hiring for the
engineering manager, the first thing you need to ask yourself
is what type of injury manager, do I need?
I think that's the first thing is that you don't want to just
go and title alone, for instance.
If you're hiring a tech lead entering manager, you probably
need to test how well can actually make architectural
decisions. That's where some of the
Hands-On stuff comes. But if you're not hiring a tech
lead in Ruidoso, you're focusing on the team leader, engineering
manager, you're going to attract the wrong sort of people, or
you're going to probably waste people's time by giving people
technical tests and they're like, why am I doing this?
Because you want me to manage people and the system not
necessarily about making technical decisions.
So I think the first thing is unusual, work out what type of
entering manager? Do you need for your
organization or your context? And then like with everything
once, you know, what sort of hyper venturing manager you
want. Then I will be posing questions
to test some of those particular elements training, ask for
concrete examples of scenarios. They've dealt with.
Based on the types of characteristics, you're trying
to test one of the topics that I didn't quite cover as a
archetype was the product manager, engineering manager
type. So if they're expected to do the
product planning type processes, you might have some questions.
Particularly focus on how do they run product?
What do they think about when they're building product for
others, their product? Our relation process been in the
parts. However they said no to
stakeholders when you've got 12 different people saying this
thing needs to be built tomorrow.
You know. It's testing a little bit more.
The product management type and trying to get an understanding
about how they think about product priorities but that's
very different. If you're trying to focus on
that team lead entering manager type.
So try to look for concrete examples where maybe the
transformed a low performing team to a high performing team
by trying to get a sense about what their experience is and if
it's matching to what you're actually looking for as well.
So yeah, that's how I interview for the.
So again, is the case of it depends, right?
The first is actually, to understand what kind of
archetype that you are looking for in the engineering manager,
there are plenty of various yet, look for concrete examples and
behaviors or past experience that they have done.
So, thanks for the tip. Sad for people who are hiring
engineering manager, so maybe you can improve your interview
process. So you wrote a number of blog
posts lately. As part of maybe, this launch of
a course. The title is like anti patterns
for engineering managers. You can cover a few of those
anti patterns for people who probably are stuck in the center
button so that they realize and they change.
So maybe let's cover the first one continuing as maker instead
of becoming a multiplier. What kind of anti-pattern is
this? How do people actually identify
if they are being in this mode? So, I think one example of this
is, I can think of an interim manager who had transitioned
into this role from being an individual contributor.
They still spend the majority of their time I'm writing features
and code. They saw their role as you know,
I now get to tell people to do so, I will first, take the
story. I will break this up or this
feature into tasks and I will give these tasks to people in my
team. Nobody really wants to be told
he's a task, that's not very creative problem, solving type
of process. I think some of this stems from
a little bit of insecurity about not quite sure how to maybe
create an environment where people can pull work or maybe
I'm worried about the quality of that work and so they default to
their original mode of wanting to Write things down, so they're
very comfortable. It's how they would do it.
They're not really thinking with that multiplier mindset around.
What can I actually do when people fall into this trap?
Because they're spending so much time still being very Hands-On,
they tend to neglect number of the other injury management
responsibilities. This is very common for the tech
lead entering manager because they need to be typically a
little bit more Hands-On than a number of the other archetypes.
They're a little bit of Hands-On, just continues to be
very Hands-On to the point where I and everyone's like, let's do
that next. What we call, let's do that week
after. They just kind of keep
postponing all of the other things that do need to be done
as an entry manager, because it gives them a lot of
satisfaction. As it's what you're used to,
it's where you feel comfortable. It feels like you're adding
value. But also, your kind of
neglecting a whole bunch of responsibilities that is
associated with your role and you probably don't realize it.
And I think that's the danger with these leadership roles as
it's a little bit harder to get feedback.
It's a little bit longer. People expect you to do the
right thing. That's where the Comes from as a
leader, but the flip side is you get less feedback because you're
expected to know what you should be doing.
I think the challenge here is this will surface in a couple of
different ways. I think if you're too much of a
maker, maybe if you do something like culture engagement surveys,
you might find that people on your team are less engaged
because they don't really get to exercise a lot of autonomy.
Or they're a little bit bored, just simply doing tasks, they're
not very satisfied to an extreme degree.
You might actually have people start to leave your team because
they don't like to be micromanage.
That's another it sort of Extreme.
I hope that you as an injury manager, if you're in that role,
also, get some direct feedback either from a peer or from your
manager, which can also be neglecting sometimes that you're
maybe not doing the right thing as an engineering manager.
I mean, not only neglecting responsibilities.
Sometimes if you are involved in developing feature, you become
the bottleneck where people rely on using the work while you
actually have to deal with some other things.
Maybe people management or aligning with different teams.
Another thing that you mentioned as the anti-pattern is that
assuming everyone Also what you do this is interesting to me
because first of all, how do people know what you're doing?
Because your time if you look at calendar sometimes injuring
magic can be very full right you have meetings all over the
places so can tell us more about this anti pattern.
Yeah, Tuscan old book but still kind of useful.
It's called Behind Closed Doors by Esther Derby.
And I think China Ruffman it's a little bit about more
management, it manager, so feels a little bit, maybe out of place
because it's a different generation of examples.
It Talking about, but it's still relevant because I think this is
the thing as an engineering manager.
A lot of what you do is literally behind closed doors.
You're not in a team meeting where everyone hears and sees
what you're doing. For example, we do want ones, it
shouldn't be 1 to 1 and the rest of the team here in that would
be an appropriate and nobody would want to talk about
anything. That's very sensitive.
You might be doing 12 ones with people, which eat up the whole
day for your team, but the other people might be thinking, oh,
you're just not there, so people don't really know.
You're doing a different type of example, is fuel trying to work
with internal bureaucracy. Often described as smoothing
internal bureaucracy so you have to work out which team our
department is responsible for some environment because you
want to change to it. Once you work out that team what
that process is to forget the change that you need.
So little bit about navigating things that maybe answer
documented or trying to find out who is the decision maker around
that what your team sees is probably?
Once again, you're away from called team.
You're trying to do something. Things that are helpful for your
team. So that maybe when they work on
particular work that dependency is available.
So they're not to lose sitting around waiting for all of this
internal stuff to happen. You are trying to work ahead and
deal with this. But once again is kind of behind
closed doors people don't know what you're actually doing.
And so I think this is quite important for entering managers
is to create some visibility and transparency around.
What's going to talk about some of the things you doing, how it
relates to the work because the other sort of perspective is
other people. I have different Alternatives
ways that can actually also meet those outcomes.
Just as quickly, I think the intention for a good engineering
manager is that idea of to a certain degree servant
leadership of serving the team and helping them meet their
needs. But you also probably need to
talk to them about our you actually meeting the needs or is
there a different way to solve it?
So I think it's very useful to create some light on some of the
things that you're doing where you're spending your time
because people will wonder because they're doing different
activities from you. And so it's easy for people to
create a false picture of you just because you're not spending
time with the team because you haven't provided some context
about why you're spending time away from the team.
And when you mention about light creating more visibility, is it
something like you have to write something like newsletter status
report or presentation? Maybe they can tell us more
concrete examples. How do you do that?
Yeah, so each entry manager does it in a different way.
It might be as simple as if you have a daily stand-up.
You also create some visibility about what you've been doing,
maybe some of the meetings. Outcomes or discussion so that
people have some context about what's going on.
You might include it as part of. As you mentioned status reports
your team saying here's a weekly summary of how the team's going.
It's not just the activities of what the team has been working
on. But also what you because you're
part of the team about what you've been working on a part of
that, you know it kind of depends on also your style is
that depending on the topic, maybe it makes sense to call a
special meeting to provide some context around stuff.
So as an example, I can think of one situation where One entering
manager. I was working with their company
was being a quiet. And so there was this whole
thing behind the scenes of them trying to work through a due
diligence process. They didn't want to necessarily
A create some tension by going through this sort of stuff
that's a once-off event. Once it was very clear that this
process was going to head, it made sense to talk about whether
being spending time, why we're continually being pulled away
and the types of information just to provide a little bit
more context, this is another key.
Skill and responsibility. A lot of people maybe haven't
practice, which is deliberately communicating.
This is the hard thing with being an interim manager, is
you're trying to work out the right level of information.
There's no right science or formulas to this, but you're
trying to provide enough context so people can be aware of things
going on. I think it's dangerous to, like
not provide any information because then when something
comes up, people are often very surprised.
But you're also trying to balance out with too much
information like literally no filters.
Because they never ends just constantly distracted.
And then everyone's the key about the worst case scenario,
which erupts into more conversations about scenarios
that will never happen. That doesn't really help your
team as well. And this is one of the tricky
parts of being an interim manager, which is that Judgment
of, what's the right level of information to help the team.
There are some things where you probably don't want to talk
about stuff because if that situation ever happens, then
there was no need. There was just more distraction
but for highly uncertain events, that could be really Maybe it
makes sense. These are some of the challenges
of practicing how to communicate.
I think one other perspective here is that you'll often have
people in your team that have different preferences of how
they would like to hear messages.
So some people would like to hear it and want one's very
personal other people. I don't want another beating,
like just write it down. So this is where you also have
to adapt, your communication style, which takes practice, and
it's another one of those skills definitely worth investing in,
but most people have not invested in this before they
find themselves in these roles, if we can cover.
One last and d-pad in which I find very interesting and
related to managing system that you measure is optimizing the
parts instead of the whole. Maybe if you can touch on a
little bit on, what do you mean by optimizing the parts?
Let me give you an example. Recent example, actually.
So I remember in one of my courses.
Somebody was saying there were first time injury manager and
there were saying I want every person my team to be as
productive as possible. I was kind of their mission.
It's very well meaning which is fine the way that kind of ended
up happening is A clay. Each person had their own ticket
queue and then basically, they wanted to make sure that each
person was running through as many tickets as possible.
So, that's one way, that's definitely about.
Managing the parts each individual to be as productive
as possible. But if it gets like they're
working as a team, I was actually working on a team very
early on similar to this, which is like we had individual
developer velocity. I was awful.
I actually got allocated higher developer velocity.
So I actually had to be more productive than some of the
people at the team. It kind of creates a bad
incentive system because Is it often means.
Okay, I'm being measured individually.
So I will make sure I hit my Target and that's going to be a
trade-off with helping people in your tip.
So in that sort of system, what you tend to find is if somebody
is blocked, other people will do the minimum amount of work to
kind of support them because they're really want to focus on
making sure that they hit their goals and targets.
First, they don't want to diminish their own server
things. This is the optimizing the parts
rather than the whole is you can actually diminish the overall
team because you're trying to push individuals Much.
That's a really good example that happens quite frequently
where injury manager is like literally trying to manage each
single person and their work to try to make sure that everyone
is as busy as possible. And actually a healthy sign of a
good functioning team is that this is a certain amount of
slack, the team can dynamically adjust their slat to focus on
where that team bottleneck is and help each other.
So that you're actually moving work through the entire system
of the team rather than having to play like all that person's
waiting around. So let's give them more work and
that person is suddenly overloaded, you know, we have to
do something there. But people are waiting around,
that's the big difference between managing individuals
versus Parts first. The system will be bow before
you in seated a process. Although you might have a good
intention behind, right? Think whether you're actually
optimizing a parts versus the whole.
So the idea here is that you need to see the interrelation
between people within the team is not just individuals.
And I like one phrase that I found in the blog post itself,
you mentioned at our loss at the bottleneck is an hour loss.
Entire system, so it's not just one small things that is lost,
but actually, it affects the whole system's all together.
So they, I can't take credit for that quote because this is
coming from eliyahu goldratt, the goal and if you want to
learn more, you should go and study theory of constraints
that's where that quote comes from.
I don't want to take credit for that because that's comes from
him, the book, The Goal itself, I think many mention in the
devops world, how do you optimize the, our systems?
So thanks for your time at due to time.
I think we need to wrap up soon but If you still remember last
time in our first chat, I ask you this question called the
three technical leadership wisdom.
So I would ask the same question to you again this time.
Not sure whether you have the same answer this side.
So maybe if you can share, what will be your tree technical
leadership wisdom? So against it really was talking
about the engineering manager role.
I probably will have different advice here.
The first one is, if you're going down this path as an
engineering manager, and you've never done this before,
recognize that you do need to build different skills.
This means that you're going to be Learning and studying.
It also kind of means you can be making mistakes very early on
which is okay, it feels more severe because you're dealing
with people. Maybe that feels less
comfortable than when dealing with a computer or a test
failing, but it's going to be a natural part of that.
The second part would be to make sure that you have a support
network. Make sure that you talk to web
here, make sure that you have somebody to go to may be
external to your company as well, to talk about challenging
situations that you're gonna be in it going to be in many as a
entering manager, and it's helpful to bounce ideas.
Has off with other people around that.
Finally, the other bit of advice here is Andrew managers can have
such a powerful impact because we have so many bad examples of
engineering managers out there. There is a good reason to go
down this path because dealing with people creating a system
where people can be productive as a team, not as individuals is
hard, but it can be really fulfilling.
I think if you can sort of lean into that, there's a lot of good
reasons to want to go down the management track because a, we
have a need as an industry for that, but be you can have so
much fun. The Deep Impact, the
multipliers. You can do it really well,
thanks for the message, so for people who listen, and if you're
thinking about becoming engineering manager, think about
the impact that you will make, if you can transform different
people within your team or maybe even the organization itself.
So the kind of impact that you make will be great.
So bad for people who would like to explore what your course, or
maybe join. Your course, or maybe find out
more about you, is there a place where they can find you online?
Yeah, you can follow me on Twitter, it's Pat, Kwa Kua on
Twitter and then also pack quad-cam the website.
And then from that website you can get a link to the
engineering manager Essentials link and hopefully I might see
some of you online some time. Thanks again, good luck for your
course pad. Thank you for this time.
Thank you very much. So I just speaking to you again,
Henry Thank you for listening to this episode and for staying,
right until the end if you highly enjoyed it.
I would appreciate if you share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you are new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot.
In order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page, at Tech Legion o.f website, including the full
transcript enter, I think words and links to the resources
mentioned from the conversation. And lastly make sure to
subscribe to the show's mailing list on pack leader dot f to get
notified for any future episodes.
Stay tuned for the next technology, another episode.
And until then goodbye,