[Best of 2022] #94 - Engineering Manager Essentials - Patrick Kua

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.