#94 - Engineering Manager Essentials - Patrick Kua

[00:01:57] Episode Introduction

Henry Suryawirawan: Hello to all of you, my friends and my listeners. Welcome again to the Tech Lead Journal 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 Tech Lead Journal, 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 techleadjournal.dev/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 to the others. A few of the Engineering Managers I know sometimes also ask 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 role, I’m happy to share this episode with all of you.

My guest for today’s episode is Patrick Kua, also known as Pat Kua. Pat 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 N26 and a Technical Principal Consultant at ThoughtWorks. Pat also writes a popular newsletter called “Level Up”, and offers an online training for tech leaders called “Tech Lead Academy”. This is Pat’s second appearance on Tech Lead Journal 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 9.

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 the common engineering career track these days, which is the manager versus individual contributor (IC) track. Pat then 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 end, Pat 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 its different archetypes, the success criteria, and some of the anti-patterns that an Engineering Manager should avoid. If you also enjoy 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.

[00:06:43] Introduction

Henry Suryawirawan: Hi, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today I have a repeat guest. He was part of the podcast journey in the single digit. Episode 9, in fact. Patrick Kua is back here again to talk with me about engineering manager. So last time we covered about technical leadership or tech lead per se, and it was one and a half years ago and one pandemic apart. So it’s been a while since I met Pat after that time. So really looking forward to have this conversation, Pat, and maybe talking more about engineering manager in general.

Patrick Kua: Yeah. Thanks again for having me, a repeat. A lot of things that 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.

[00:07:30] Pat’s Latest

Henry Suryawirawan: So maybe just a little bit background what have you been up to since last time we 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?

Patrick Kua: Yeah. So last time we spoke, I guess like everyone, was sort of adjusting to a full pandemic. At that time, it was about rebuilding training material to run technical leadership courses online. And since then, I’ve 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 at 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 all technical leaders 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 of upper echelons of the company. So CTOs, VPs of Engineering. Supporting them one-to-one through coaching and mentoring. It really helps me sort of stay in touch with the pulse of how tech companies are going. The challenges that all senior leadership people are facing. Since I’ve been running the technical leadership courses online, I’ve had a lot of requests on supporting engineering 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 engineering managers as well.

Henry Suryawirawan: Yeah. And not to mention your great newsletter, Level Up. I’m one of your subscribers. Every Sunday or Monday-ish, I think.

Patrick Kua: Yeah. It’s depending on time zone.

Henry Suryawirawan: So that is also one great resource, I think, for all the engineering managers or technical leads out there.

[00:09:25] Engineering Manager Essentials

Henry Suryawirawan: You mentioned you just published a new course, Engineering Manager Essentials. 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, a little bit, what kind of problem are you trying to solve?

Patrick Kua: Yeah, I think it’s interesting because like the technical lead role, the engineering manager role, I would say is relatively new to our industry. Probably over the last, say, 10 years, that name and title has become a lot more popular. Before that, you might’ve had things like team leader or delivery manager depending on if you’re in a project or a 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’ve 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 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 engineering 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 engineering management role. So, that’s kind of the intent behind the training, which was 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 engineering manager role.

[00:11:21] The Role of Engineering Manager

Henry Suryawirawan: 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 they should care about?

Patrick Kua: So I’m going to start with a typical consultant answer. It depends. But one of the articles I have on my blog was talking about five different archetypes of being an engineering manager. I think the role scope does depend because it kind of also relates to an organization. If they have other roles there. 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 in a full person. Not every company has this. So sometimes you have the pair. So sometimes you have an engineering manager and a tech lead, who are expected to partner with each other. One is focused, perhaps, around the team and delivery and people management side. And then the other of side is really focused on technical leadership, in terms 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 the tech lead engineering manager works in one.

And then if you split them, then that engineering manager starts to look a little bit more like what I call the team lead engineering 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 technologist on that particular team as such. There’s five different types of archetypes and we aren’t going through 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 project centered work. So either in an enterprise where people run projects, or if you work for consultancy, where you’re working for external clients and you’re effectively not really a product team, or you’re an extension to somebody else’s product team, but you’re there for a project for a certain amount of time to help a product team achieve a certain type of goal. The engineering manager isn’t necessarily always responsible for the people. They’re more, a little bit more focused on the delivery to make sure that client expectations are met, that the team is productive, connected in with whatever, client or a customer that they’re sort of engaging with, and 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. You might call it bureaucracy or other types of cultural things to make sure that you work smoothly as a single unified team.

[00:14:19] Difference With Tech Lead

Henry Suryawirawan: Thanks for sharing these five archetypes. So I think for people who want to refer more, you can check it out in Pat’s blog. No wonder that people are sometimes not clear, right? 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 or people management. You mentioned a lot of times about tech lead in this conversation 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?

Patrick Kua: If you split them, let’s say, you have a tech lead plus a team lead engineering manager archetype, then 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 that they’re building is working towards to make sure that the team is using good tools and paying back technical debt so they can 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 engineering manager in 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 should an engineering 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 hands on. Because they have somebody who was guiding and making sure that people are making good decisions, to make sure that technical decisions are tie-breaked through that tech lead. But if you don’t have that tech lead role, that kind of gets absorbed by the engineering manager. And so, you do need somebody to do that and they’re playing both hats from that perspective.

[00:16:28] Manager and IC Paths

Henry Suryawirawan: 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 path, which is probably tech lead, staff 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 the company?

Patrick Kua: So it’s a popular way of structuring engineering manager roles, particularly in the US, 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 technologist 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 IC versus management track though, because I think people do see higher level roles, like a tech lead, staff, or a principal engineer on the IC 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 staff and principal engineer, they need to have very strong leadership skills. And so, I actually prefer to, what I describe, 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 path. So they’re not necessarily responsible for managing people. So they’re not in the management responsibilities. But they should be leading technical topics.

So let’s give you an 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 product 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 Kafka, a common messaging interface to raise events and communicate between different points. Now, what can quite happen if a tech lead and 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 are not really agreed.

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 staff or 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 to create alignment across that. And that’s not about individual contribution at all. That person is not writing the spec and the contract that everyone needs to follow. They’re not going to really get a lot of buy in very quickly from that perspective. They need to be able to lead. And this is where I think the IC 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 you’re 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 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.

Henry Suryawirawan: Thanks for sharing that scenario. Because I do agree that sometimes these staff software engineer, principal, they think that their focus is actually to solve one particular problem without actually aligning with different teams. So I think I like the trident model that you mentioned. I think that kind of like 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.

[00:21:02] EM Is Not a Promotion

Henry Suryawirawan: One common phrase that I always hear about engineering manager. It’s not a promotion. Because sometimes what happened is that as you go along in your career journey, after five, six to 10 years, you get promoted as an engineering manager. But people refer 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 thoughts on this? If it’s not a promotion, then when should we nurture people to go into this engineering management role?

Patrick Kua: My conceptual model with roles is it’s like a container. There’re things that you 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 break that problem down. You know how to design code and modularise that code. You know how to apply good patterns 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 engineer should 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 engineering manager are 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 can sort of 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 kinds of things that go with warrior class. But actually, the engineering 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 magics or a safety type of magics 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 the tech lead engineering manager. But there’s a whole bunch of new skills and responsibilities that you may not have built skills and experience in.

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 it in a way such that they are 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 the other person is reacting badly. But that example of a skill is something that engineering 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 engineering 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 will 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 as well. So there’s a good reason to be able to do that if you want to move in that direction.

Henry Suryawirawan: By the way, I like your RPG analogy. I think that kind of like resonates well with gamers, I guess. If this is the case where 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 about trying out to be this engineering manager? Or when should the company decide, okay, this person should actually become an engineering manager or should this person continue along with that individual contributor track?

Patrick Kua: Yeah, it’s a great question. I think what I tend to see is very common in career growth 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 land, you have somebody that’s been working in technology who’s there for like a year, and then they get pushed into an engineering 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, unless 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 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 in 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 an associate 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 is 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 is facing. 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 same scenarios that you can know how to solve it.

I think the other perspective is, you know, as an individual contributor, sometimes you get to work with really bad engineering managers. And this is actually, I think, what helps form good engineering managers, because people go, “Oh, I don’t want to have to work in a team environment like that.” If I’m in that role, I can avoid that. I can intentionally think about these people that I’ve had to work with and go, “Oh, this is really painful.” I can actually create a great environment for my team, so they can imprint the opposite pattern and therefore be a lot more effective. If you’ve never experienced the bad engineering manager, that’s going to be really hard to do.

Henry Suryawirawan: For me, one way that I always advise for people who are thinking of becoming engineering manager is, the first test will be, do you like working with people? Because sometimes yeah, managing people is different than managing code bases.

[00:28:08] EM Success Criteria

Henry Suryawirawan: You mentioned about bad 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 of 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, how should we, as an engineering manager, assess the success of our role?

Patrick Kua: That’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 engineering manager is to make sure it’s aligned with whatever the organizational 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 engineering manager, and because they are a little bit more biased towards the technology, they just basically use their team as an excuse to play around with technology. Like, “Oh, let’s use a graph database. Let’s do this sort of thing here.” At some point, their manager came in and was saying, “What are you actually delivering? 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 engineering manager. Engineering 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 the organizations, smoothing out the pain points for the teams. Most people will probably be on a product team. And then, it’s the 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, a customer registration and working on the growth channel there?

You know, I think there are good concrete goals, depending on which part of the business you work 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 manager. But then also that the team has enough capacity to do this sustainably over time. Sometimes this means enough time to pay back technical debt, time to invest in learning and development. You know, sort of sustainable approach.

So I think any extreme is really bad where, if a team is always just being pushed to produce features after features, and they don’t get a chance to actually work on some technical infrastructure, then at some point their productivity really is slowed down or the quality will be affected. And whenever they make a change, you get explosions of bugs in production. And so, that’s going to be a long-term consequence. So the engineering manager, I think, is thinking about, are you delivering value in a sustainable way? And that’s for me, a nice little heuristic.

[00:30:48] Multiplier Instead of Maker

Henry Suryawirawan: I still remember last time when you mentioned about one of the characteristics of a good technical lead is actually to become a 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 or peers within the company.

Patrick Kua: Yeah, absolutely. So I think all leadership roles need a multiplier type of idea or mindset. And I think in this case, the engineering 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, and then, that helps multiply the technical knowledge.

I think one of the key responsibilities that almost always falls onto the engineering manager is people development. And so, the way that an engineering manager multiplies their people is probably a little bit different. Because, for instance, one of the traits that I would expect from a good engineering manager is they have regular one-to-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? Do you wanna be an engineering manager? 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 a tech lead can actually support somebody. But often, it’s more about thinking about opportunities. It might be about a specific project that a person might be able to join at some point that pops up. Or a rotation onto a different team, which requires the 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 satisfy somebody’s needs. It might be about working with somebody to find external training to support somebody 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 sorts of skills, or maybe it’s a completely new skill set that nobody has in your teams so they need to go externally to do that. And so, that’s some of the multiplier sort of side that I see engineering managers take, which is a little bit more broader and less focused on technical solutions in order to help multiply people.

Henry Suryawirawan: Yeah. And 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.

[00:33:21] Course Structure

Henry Suryawirawan: So, maybe let’s go a little bit on what you offer in your course, Engineering Manager Essentials. Tell us more, what will people learn from this course? How do you structure it?

Patrick Kua: So there are four parts of the course here. One which is really focused on exploring the engineering manager role. This is really about trying to make sure that people have a good understanding about where it may vary, the different sort of ideas around this. A very common key responsibility, and I’ll tell you, it’s like clear in, say, 90% of the cases, the engineering manager is managing people. So they’re responsible for people and line management. So we do touch upon managing people. But I tend not to focus on it too much because there are 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’re also a lot of resources out there. I think one failing for a lot of engineering 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, and there are also systems in working with teams that are less productive, which means you’re probably maybe working as a bunch of individuals rather than as a team. This is a very key engineering management responsibility.

If you have that delivery manager engineering manager archetype, it’s explicitly there. But for the other ones you should be considering what’s the environment of 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. 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, who are engineering managers, 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 struggle 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 enough of the sleep, right? These are all very normal human reactions. Maybe as a tech lead, you can avoid some of the more difficult people management topics. But as an engineering manager, you can’t. It’s part of your role, but you’re 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 is because you’re going to be accountable for it is, 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 their behavior. You can’t simply skirt around the issue. It’s not going to be 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 a really key part to the course. It’s a four-hour course, and it covers a lot of these light touch, but hopefully, it gives people a good sentence about a good balance or things that they can focus on, and lots of practical things they can do.

Henry Suryawirawan: I like the three different categories that you mentioned just now. Managing people, of course, that’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 looks like at the moment. They just go into the motion and think that this is always how we do it. So, I think, managing system, I agree, it’s really important. And the last one, of course, don’t forget to manage yourself. Maybe do 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.

Patrick Kua: Absolutely agree.

[00:37:20] Interviewing EM

Henry Suryawirawan: So I think this kind of course will definitely help a lot of people to upskill their engineering manager management skill. I know that this role itself is currently in demand in the tech industry. Hiring engineering managers is actually very hard. From your views, maybe last time when you work in startups before as well, how do you actually gauge someone who is a good engineering manager vs someone who is just maybe as a title only, right?

Patrick Kua: Good question. So if you’re hiring for an engineering manager, the first thing you need to ask yourself is what type of engineering manager do I need. I think that’s the first thing is that you don’t want to just go on title alone. For instance, if you’re hiring a tech lead engineering manager, you probably need to test how well can I actually make architectural decisions? That’s where some of the hands-on stuff comes in. But if you’re not hiring a tech lead engineering manager, so you’re focusing on the team lead 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 on you to work out what type of engineering manager do you need for your organization or your context? And then, like with everything, once you know what sort of type of engineering manager you want, then I would be posing questions to test some of those particular elements. Trying to 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 an 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 focused on how do they run products? What do they think about when they’re building products? What is their product prioritization process been in the past? How have 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 of a 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 engineering manager type. So you’re trying to look for concrete examples where maybe they 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 would interview for them.

Henry Suryawirawan: So, again, it’s a 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 variations here. Look for concrete examples and behaviors or past experience that they have done. So thanks for the tips, Pat, for people who are hiring engineering manager. So maybe you can improve your interview process.

[00:39:58] Antipattern 1: Continuing as a Maker

Henry Suryawirawan: So you wrote a number of blog posts lately as part of maybe this launch of the course. The title is like “Anti-patterns for Engineering Managers”. Maybe if you can cover a few of those anti-patterns for people who probably are stuck in this anti-pattern so that they realize and they change. So maybe let’s cover the first one. Continuing as a maker, instead of becoming a multiplayer. What kind of a anti-pattern is this? How do people actually identify if they are being in this mode?

Patrick Kua: So I think one example of this is I can think of an engineering manager who had transitioned into this role from being an individual contributor. They still spent a majority at their time writing features and code. They saw their role as, you know, I now get to tell people what 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 here’s a task. That’s not a 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 break 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 they actually do.

When people fall into this trap because they’re spending so much time still being very hands on, they tend to neglect a number of the other engineering management responsibilities. This is very common for the tech lead engineering manager, because they need to be typically a little bit more hands-on than a number of the other archetypes. They are a little bit of hands on just continues to be very hands on to the point where, “Oh yeah, their one-on-ones like, let’s do that next week, or let’s do that the week after.” They just kind of keep postponing all of this other things that do need to be done as an engineering 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, you’re 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 is 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 autonomy 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 in 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 are 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 micromanaged. That’s another sort of extreme. I hope that you, as an engineering manager, if you’re in that role, also get some direct feedback, either from a peer or from your manager which can also be neglected sometimes, that you’re maybe not doing the right thing as an engineering manager.

Henry Suryawirawan: I mean, not only neglecting responsibilities. Sometimes if you are involved in developing features, you become the bottleneck where people rely on you finishing the work while you actually have to deal with some other things. Maybe people management or aligning with different teams.

[00:43:01] Antipattern 2: Assuming Everyone Knows What You Do

Henry Suryawirawan: Another thing that you mentioned as the anti-pattern is that assuming everyone knows what you do. This is interesting to me because first of all, how do people know what you are doing? Because your time, if you look at calendar, sometimes engineering manager can be very full, right? You have meetings all over the places. So can tell us more about this anti-pattern?

Patrick Kua: Yeah. There’s quite an old book, but it’s still kind of useful. It’s called “Behind Closed Doors” by Esther Derby and I think Johanna Rothman. It’s a little bit about more management, IT management. So it feels a little bit maybe out of place because it’s a different generation of examples they’re talking about. But it’s still relevant. Because I think this is a 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, when you do one-to-ones, it shouldn’t be one-to-one and the rest of the team hearing. That would be inappropriate and nobody would want to talk about anything that’s very sensitive. You might be doing one-to-one with people which eat up a whole day for your team. But the other people who might be thinking, “Oh, you’re just not there.” So people don’t really know what you’re doing. A different type of example is if you were trying to work with internal bureaucracy. I like to describe it as smoothing internal bureaucracy. So you have to work out which team or department is responsible for some environment because you want to change it. Once you work out that team, what that process is to try to get the change that you need, it’s a little bit about navigating things that maybe aren’t so 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 core team. You’re trying to do some things that are helpful for your team, so that maybe when they work on particular work, that dependency is available. So they’re not suddenly sitting around waiting for all of this internal stuff to happen. You were trying to work head on and deal with this. But once again, it’s kind of behind closed doors. People don’t know what you’re actually doing.

And so, I think this is quite important for engineering managers. It’s to create some visibility and transparency around what’s going on. To talk about some of the things you’re doing. How it relates to the work? Because the other sort of perspective is other people might have different alternatives or 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, are 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.

Henry Suryawirawan: And when you mentioned about light, creating more visibility, is it something like you have to write something like newsletter, status report or presentation? Maybe you can tell us more concrete examples, how do you do that?

Patrick Kua: Yeah. So each engineering 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 and outcomes or discussions so that people have some context about what’s going on. You might include it as part of, as you mentioned, status report of 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, cause you’re part of the team, about what you’ve been working on as 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 engineering manager I was working with. Their company was being acquired. 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 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 ahead, it made sense to talk about whether they’ve been 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 practiced, which is deliberately communicating.

This is the hard thing with being an engineering manager. It’s you’re trying to work out the right level of information. There’s no right science or formula 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 then everyone’s just constantly distracted. And then everyone’s thinking about the worst-case scenario, which erupts into more conversations about scenarios that will never ever happen. That doesn’t really help your team as well.

And this is one of the tricky parts of being an engineering 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 is no need. There was just more distraction. But for highly uncertain events that could be really significant, 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 one-to-one, very personal. Other people, “Ah. I don’t want another meeting. 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.

[00:48:34] Antipattern 3: Optimizing Parts Instead of The Whole

Henry Suryawirawan: If we can cover one last anti-pattern, which I find very interesting and related to managing system that you mentioned. It’s 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?

Patrick Kua: Let me give you an example, a recent example, actually. So I remember in one of my courses, somebody was saying, they were first time engineering managers, and they were saying, “I want every person on my team to be as productive as possible.” That was kind of their mission. It’s very well-meaning, which is fine. The way that kind of ended up happening is basically, 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 he forgets that they’re working as a team. I was actually working on a team very early on, similar to this, which is like we had an individual developer velocity. It was awful. I actually got allocated higher developer velocity. So I actually had to be more productive than some other people at the team. It kind of creates a bad incentive system. Because it often means, okay, I’m being measured individually. So I will make sure I hit my targets, and that’s going to be a tradeoff with helping people in your team. 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 really want to focus on making sure that they hit their goals and targets first. They don’t want to diminish their ends of the 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 too much. That’s a really good example that happens quite frequently where engineering 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 there was a certain amount of slack. The team can dynamically adjust their slack 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, “Oh, 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 versus the system.

Henry Suryawirawan: For people, before you institute a process, although you might have a good intention behind, right? Think whether you’re actually optimizing the parts versus the whole? So the idea here is that you need to see the interrelation between people within the team. It’s not just individuals. And I like one phrase that I found in the blog post itself. You mentioned that, “hour loss at the bottleneck is an hour loss for the entire system.” So it’s not just one small thing that is lost, but actually it affects the whole systems altogether.

Patrick Kua: Absolutely. I can’t take credit for that quote because this is coming from Eliyahu Goldratt’s, “The Goal”. And if you want to learn more, you should go and study the theory of constraints. That’s where that quote comes from. I don’t want to take credit for that because that comes from him.

Henry Suryawirawan: The book, “The Goal”, itself. I think many mentioned in the DevOps world. How do you optimize your systems?

[00:51:30] 3 Tech Lead Wisdom

Henry Suryawirawan: So thanks for your time, Pat. Due to time, I think we need to wrap up soon. But if you still remember last time in our first chat, I asked 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 time. So maybe if you can share, what will be your three technical leadership wisdom?

Patrick Kua: So, again, considering that we’re talking about the engineering manager role, I probably will have different advice here. The first one is if you were 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 got to 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 a peer. Make sure that you have somebody to go to, maybe external to your company as well, to talk about challenging situations that you’re going to be in. You’re going to be in many as an engineering manager. And it’s helpful to bounce ideas off with other people around that.

Finally, the other bit of advice here is engineering 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 B, you can have so much of a positive impact as a multiplier if you can do it really well.

Henry Suryawirawan: Thanks for the message. So for people who listen, and if you’re thinking about becoming an 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 Pat, for people who would like to explore about your course, or maybe join your course, or maybe find out more about you, is there a place where they can find you online?

Patrick Kua: Yeah. You can follow me on Twitter. It’s PatKua, K U A, on Twitter. And then also PatKua.com, 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 sometime.

Henry Suryawirawan: Thanks again. Good luck for your course, Pat. Thank you for this time.

Patrick Kua: Thank you very much. Pleasure speaking to you again, Henry.

– End –