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,