Manage Systems, Lead People: How to Multiply Team Strengths and Delegate Rigorously

Aydin Mirzaee (Fellow.app)  01:26

Pat, welcome to the show. 

Pat Kua (Tech Lead Academy)  02:12

Thanks for having me. Great to be on. 

Aydin Mirzaee (Fellow.app)  02:14

Yeah, very excited to have you on. We were just chatting, you know, before this, about how we’ve been fans and been following your newsletter for a while. So it’s really great to have you on one of the things that I wanted to end, you know, we’re going to dig into the newsletter and so much more. But one of the things that I wanted to really start by asking you was, and this is mostly because of your leadership career, right? You’ve been at Oracle, thoughtworks and 26. And obviously, you have this newsletter. But before we dive into all of that, I wanted to ask you in your career from all the different companies that you’ve been at, who’s been the most memorable boss for you? And why?

Pat Kua (Tech Lead Academy)  02:55

Yeah, it’s a great question, I have to give a little bit of a, I guess, some context, because it’s a little bit funny as I was consulting, because I didn’t actually have a manager, Project Manager for a very long time. So I’ve got a large gap there. But I’m going to talk about, I think, sort of two people. So my very first manager when I left university, I was actually working at flight Central Australia, and my manager was a non technical person. And she was a really great manager. And the reason I remember this very well is, you know, she was very caring, she was clear that she couldn’t help me solve technical problems, right. You know, in my early career, I was looking for someone to grow from, but actually, I did appreciate the support that she could provide me. And so I remember, you know, we would meet once a week for breakfast, we’d have a chat about, you know, what things I’m struggling with, what things I wanted to do. And then she was always trying to work out how to sort of support me and try to help find those sorts of goals. And I think for me, that was a really great example of, I think, a really good manager of someone who recognizes you know, where they couldn’t actually help me but also providing that support and sort of nurturing around what they could help me with, particularly from an organizational perspective. So that was one manager that I think gave me a really good example of how you can be a successful manager, a leader without necessarily having the same background as the person you’re actually working with. The second person that I wanted to talk about was actually my first manager article. And, you know, he was very technical. So it was almost the opposite. But I would say that he was probably earlier on the sort of management side. So I think we’re working on a sort of healthcare platform back in the day, it was very, very complex. And we were distributed across India, America and Australia, where shows were based. You know, he was on conference calls all the time. And he was very technical, but I think it was almost a little bit resentful that he never really got a chance to actually write code and things like this. You know, being an earlier sort of stage developer. You know, we Were using sort of waterfall type stuff back then. I was really itching to write code. But we’re on like three monthly kinds of telephone calls with people across different countries trying to talk about what we were actually going to build. I kept pestering my manager, I was like, when do I get to write code, when I get to write code? When do I actually get to do something, rather than just simply talking about the thing that we’re going to do. And it kind of got to a point where, you know, he realized that he wasn’t actually going to get a chance to do the things that he enjoyed doing, unless he went sort of overtime and sort of scripted and wrote stuff on his own time. And so he started to give me sort of his side projects of things that he always wanted to do to try to maybe improve the environment. So we were using a sort of continuous integration, which is like a tool for building software. And, you know, he wanted to script the tool that we’re using, so that it would actually work well, with Oracle internal systems, he never got the chance. And so he gave me the opportunity to kind of take his idea and sort of bring it to life. And so that was like a little mini side project. And I think over time, he grew comfortable that I could actually help him achieve his little side projects and gave me the sort of autonomy and freedom. And, you know, I could then go to him when I sort of didn’t quite understand how to approach something, or I encountered a challenge. And he would help me walk through that I couldn’t make the time. And so there’s your characteristics that I think that had a very strong sort of impression on me, which is, you know, making sure that you give people a interesting challenge that you may personally want to do. But actually, it helps the other person grow. I talked about that as multiplying the other person. And then the other side is, once again, that sort of support structure of you know, he was very technical, but he didn’t know exactly the problems that I was facing at the time. But he could at least help me walk through them, walk through my sort of thinking process and provide some, you know, alternatives or different opportunities. So I think those two people were really strong role models for me as managers early in my career.

Aydin Mirzaee (Fellow.app)  06:54

Yeah, what an incredible way to start your career like getting, I think those are two ends of the spectrum. And what’s interesting is, especially with the first manager that you were talking about, it sounds like they were just very self aware. And they knew that and they were upfront about it, and they also even had a solution for like, how to cover for the things that they knew that they lacked, and it’s very interesting for you to like, look back on that. And understand. I mean, in this case, it’s them being technical or not, but I feel like we all have things that we know we’re not good at. And it’s okay to be authentic about that. Absolutely. And I think that’s the thing is that, you know, when I was at Oracle, I did see a couple of other technical managers where they tried to always pretend that they knew everything, and you can see where they are, right. And it comes through as this inauthenticity, and people are smart, they’ll see us for these kinds of, I wouldn’t say lies, but like, you know, truths that are sort of coming up. And so it’s better just to be authentic, I think and be clear about how you can help people and how you can’t help people. You know, I want to dig in on this phrase that you use, it just sounded so interesting to me. So you said you refer to it as like multiplying the other person? Could you tell me more about that? What does that mean to multiply another person? Yeah, I often talk about sort of two modes, particularly for early stage leaders of that make of us multiplayer mode. A book that I read early on in my leadership journey was The Multipliers book by Liz, I forget her last name. But for me, that was a really great example of, you know, taking a mindset as a leader or multiplying not just yourself, but the people that you’re responsible for the team or organization or department that you’re responsible for, you know, I see this challenge, particularly, you know, with software engineer, so individual contributors, because they’re so deep into that personal creation. And I think when people transition into that leadership mode, one of the things is that mindset of not moving to thinking like multiplayer, by thinking like, Oh, I have to do more, I have to have the best answer, I have to take the most complex problems, which is very much the sort of maker mode. And I think in order to successfully transition to that leadership sort of mentality, I think the question then starts to, you know, turn to how, what can I do to help multiply everyone else. And sometimes that means giving up a little bit about the things that you personally enjoyed creating or making. And so that’s a really internal interesting struggle. And I mean, I still recognize that as well. Everyone gets their fun from doing particular things that they enjoy doing. But sometimes the right thing to do is to give that to somebody else in your team because they can grow as an opportunity and multiply. And so I think that’s the interesting sort of insight I’ve been sort of learning teaching and arrived at as what is a good way to lead is to think about how you multiply all the people who are responsible for Yeah, that’s super interesting. I love that phrase. It’s just, it’s so instructive. I have to ask you, so as it relates to basically delegating, and And you mentioned like, it might be fun for you. But sometimes it’s important to delegate. What happens is, as you scale as a leader, does it mean that you never get to do the fun things that maybe you enjoyed once before? Is that a sacrifice that people need to make? Or can they still do some of those things?

Pat Kua (Tech Lead Academy)  10:18

Honestly, it is a little bit of a sacrifice. I mean, I think one of the things is, it’s more of a question of how much of your time do you get to spend or doing the thing that you really enjoy? So, you know, I started off as a developer, and so most of my time was writing code, right. So I mean, even developers don’t write code 100% of the time, they should be, you know, talking to users and showing their work. But you’re going to spend less of that when you’re working in a leadership role. Because your value add is, you know, working on the environment, and helping people in this sort of growth path. So I think naturally going to be spending less time doing the thing that perhaps you originally started doing. But then it’s also the awareness that you’re also adding value in a very different way. And recognizing that is more impactful, that maybe nobody’s taking care of is that, you know, that’s great that you have lots of people that are creating and making, but somebody also needs to think about how well is everyone working together, you know, taking care of things that may be outside of the reach of a team, often, you know, I talk about managers taking care of organizational bureaucracy. And that itself is a great way to multiply by removing obstacles and removing dependencies or enabling dependencies so that people can focus on, you know, doing the most when they get to that point, and they need those dependencies. And part of that is, unfortunately, you’re gonna have to give up a little bit of your time around doing some of the things you enjoy doing. I know some technical leaders, still managed to make some time for that. And I think it’s a question about how much sort of free time can you whip up in your schedule? But also, how well is it related to the work that you’re actually doing? So for instance, technical directors I’ve worked with, for instance, might be very heavily involved in a technical strategy. And I sort of need to have a hands on awareness of what’s the current performance or quality of their infrastructure, and so they need to get quite hands on and that can be a research topic of being quite hands on and sort of making, but it’s probably not always the best case where you’re on the critical path for some work, because leaders and managers are always going to be the people who are interrupted. And you’re gonna have to deal with emergencies. And so you know, if you do take on something that you do, like doing Try not to be on that critical path would be my

Aydin Mirzaee (Fellow.app)  12:29

You’re right, like, you don’t want to be the bottleneck or the critical path, like you said. [AD BREAK BEGINS] Hey, there. Just a quick note, before we move on to the next part, if you’re listening to this podcast, you’re probably already doing one on one meetings. But here’s the thing, we all know that one on one meetings are the most powerful, but at the same time, the most misunderstood concept in practice and management. That’s why we’ve spent over a year compiling the best information, the best expert advice into this beautifully designed 90 Plus page ebook. Now, don’t worry, it’s not a single spaced font, you know, lots of text, there’s a lot of pictures, it’s nice, easily consumable information, we spent so much time building it. And the great news is that it’s completely free. So head on over to Fellow dot app slash blog to download the definitive guide on one on ones. It’s there for you. We hope you enjoy it. And let us know what you think. And with that said, let’s go back to the interview. [ AD BREAK ENDS] Let’s talk about when you first started managing and leading teams, you know, obviously today, I mean, people look to you for leadership lessons and management advice. But when you started out, what were some of the mistakes that you tended to make?

Pat Kua (Tech Lead Academy)  13:51

Yeah, um, a lot. You know, I can think about one of the times that I was leading a team very early on. It was my first time as a technical leader, I was responsible for a pretty large team, I think we had about eight devs. A couple of QAs, business analysts back then a project manager, and I was responsible for everyone. And so I felt like there was a lot of weight on my shoulders if I didn’t do the right thing. I was, you know, gonna disappoint a lot of people. And so, you know, I think that one of the mistakes I made was that, you know, I’d kind of work on problems by myself, because I didn’t want to disappoint everyone on my team. I wanted to make sure I was doing everything as best as I could, and leading as best as I could. But of course, it was my first time or one of the earlier times and so I didn’t know how to do certain things. And I figured, well, I don’t want to unnecessarily ask people about the team because that would maybe show that I’m not really doing the role that I should be doing. And it kind of led into this situation where I put so much pressure on myself, you know, I wasn’t ready to ask for help. And I kind of started to feel a lot of stress. Now that stress would come out in a couple of different ways is that, you know, I think, when I get interrupted, I get a little bit snappy sometimes, and particularly under stress that sort of gets amplified. You know, I think everyone reacts differently to stress. But I think for me, for instance, I know that I start to raise my voice a little bit more. And that was indeed some feedback I got from that sort of project manager and a couple of people at the team, they like, hey, Pat, everything’s okay. It’s like, you’re not really feeling very well, or, you know, you’re responding very strongly to things that aren’t really a big deal. And a lot of that was like talking through that stress. And I think for me, the lesson there was like learning when you’re starting to struggle, but also having to find a support network. Sometimes it might be people in your team, and sometimes it might be people outside of the team, but don’t try to tackle things by yourself. And so I think that’s definitely one of those kinds of cases. You know, another example that comes to mind was kind of a similar situation is that we’re growing a team relatively large. And this is actually to a point where we ended up with a team that we wanted to split into two teams, but at the time, I was sort of leading both teams. So a group of about 15 people. And, you know, I was trying to, you know, ask for help and support. But once again, I felt like there were a lot of things I had to take care of. And so I started putting in extra hours. So sort of, you know, deal with all the things that the team needed to take care of, and then I would get to my to do list of things. And so I was kind of working really long days, and at some point, like my body just gave out. And so, I wasn’t sleeping very well. And I literally, I fell really sick with a cold. And I was out for like three days, right? I just needed to sleep, I just needed to get some rest. And it was actually during that sort of off time that I sort of reflected on. Okay, why did I get into this role? Why did I find myself in this position? And what can I do to make it more sustainable? At that point, I realized I was once again, maybe taking on too much. And I needed to start delegating a lot more rigorously, because I was already delegating, but not to match the pace of the size of the team was growing. And so as more people kind of kept getting added in, I kind of didn’t want to add more burden to the other existing people on the team. And I just kind of kept taking more and more. And so I ended up coming up with this practice of feature leads, which was, you know, I didn’t want to give away all responsibility, particularly because some people, you know, were very early on in their career journey. But if I could give them a certain area to take care of, that gave me less worries about taking care of everything, it was less complex for somebody to focus on leading. And depending on that person I could support them differently. So for more experienced engineers that could go off lead that area, they knew how to scope out work, design, work, work with this, and stakeholders, for people who were much much earlier, I would probably sit down with them and walk through them step by step and try to understand how they would approach it and to try to work out gaps. And so for me, that was a real, like, great learning of realizing I was on a path to burnout, like I literally physically reacted to that. And I also needed to change that environment. Otherwise, you know, I would just end up in the same position probably a couple of months later.

Aydin Mirzaee (Fellow.app)  18:18

Yeah, no, I think those are his many good lessons there. And I really liked, you know, subtly what, what I heard especially as your team started to get large was you obviously started to trust the team more for different aspects. So that it was all on your shoulders, but I really liked the you used a nuanced approach and understood that, you know, people have different seniority levels and different strengths. And, and each Yeah, and the way that each person was managed was also different. So I thought that was really cool, too. Yeah, I mean, it was the only sustainable way. It makes a lot of sense. You know, one of the questions that I think a lot of people always ask us is, how do you know if someone’s a successful leader? And like, you know, part of that is, you know, how do you know if someone is, how do you know if you are a successful leader? Like, how do you evaluate yourself? So what are your thoughts on that? Like, if someone were to ask you what makes a successful leader? What would you say?

Pat Kua (Tech Lead Academy)  19:14

Yeah, um, there’s a couple of things I tend to think about with this, I have what I call as the holiday test, right? So can you go away for a holiday? For a week or two? And does everything keep running without you? So for me, that’s a really great test, because, you know, I’m based here in Europe, and it’s very common that people take two to three weeks out. I think if you’re in the North American continent, people still check emails on holidays, you know, they’re not really on holiday. And so for me, the holiday test is can you sort of disengage from everything? And that means that you’ve built what I consider a self empowered team. So you know, if there’s an emergency, then people don’t wait for you or they don’t have to escalate it to you is that people feel empowered to say okay, This is a surprise, but we couldn’t try to deal with this until you know, packets back or something like that, right. So they can kind of take care of surprises. And actually things keep moving on. It also means that you’ve probably delegated and you know, devolved enough responsibilities such that you will no longer have this sort of bottleneck in decision making or in planning processes. So I think that’s definitely one set of tests that I tend to think about the holiday test. Yeah, can you take some time out, the other one is really thinking about, you know, how well are people sort of growing. And so this is really coming back to that multiplying. So the mindset is that, you know, you have some people that are very strong leaders, but they’re very direct with the people that they’re working with. And sometimes that means that people don’t actually get an opportunity to grow and apply their skills and also, you know, have an opportunity to grow. And particularly in a market, like we are with technology today, where everyone has so many job opportunities all the time, if somebody gets an opportunity that’s aligned with their own personal growth, opportunity, you know, often it’s more compelling for them to move to that company, or a different team with that can go live that out. And so I think that’s the other aspect, which is, if you’re leading Well, I should be seeing that, you know, people in your team are actually growing as well. So sometimes that means growing new skills, sometimes it’s actually about leaving your team to go lead another team, because they’ve grown as a leader and therefore capable of also leading as well. So they’re kind of three characteristics, how we tend to be thinking about, and then, of course, that your team is actually delivering value, right. So we all work for businesses, mostly, you know, or if you’re a government or a nonprofit, there’s a purpose to a team. And I think it’s very important that, you know, teams don’t just go around playing with things that everyone’s happy that they’re growing, but not actually delivering value. And so I think that’s the other tests, which is to make sure that people actually feel that they’re moving the company mission forward, or their product mission forward. And that considers connecting to their daily day to day work with progress on whatever that mission may be.

Aydin Mirzaee (Fellow.app)  21:57

Yeah. And it’s really interesting, just on the point around the impact of the team, you know, especially within larger organizations, teams do have reputations. So you know, that’s the team that, oh, let’s let’s have that team work on that. We know it’s going to get, you know, it’s going to be done, and we won’t have to worry about it. So, yeah, it’s super interesting. All those things that you said make a lot of sense. I think the holiday test is brilliant. You know, I’ve heard it also put in, in terms of your job is to constantly look to put yourself out of a job, and really work on the system. And so actually, that’s another thing that you tend to talk about as well, right, which is you want to manage the system and not the people. Could you talk to us a little bit about what the difference is?

Pat Kua (Tech Lead Academy)  22:45

Yeah. So this is actually a quote that I borrowed from Grace Hopper. So she talks about how you manage things, and you lead people. And when I think about things, you know, the things that don’t really have a personality, like people or temperament. And often those things, people feel like they can’t really influence them. Right. So I think when people step into a management leadership role for the first time, I think my role is to manage the people in the team. But often, the sort of productivity of a team isn’t really dictated by what an individual does, it’s really determined by the process or the team structure of how they work with each other. So I’ll give you an example. I remember consulting for a bank, and we had, you know, two teams, one development team and one testing team. The testers were sort of measured by how many bugs they could find and the developers were tested by how quickly they could actually resolve features. And now when I joined this team, there was a lot of I turned to the development team, there was a lot of contention and sort of conflict across both of those things, because developers would sort of claim a sort of story or feature was completed. And then testers would almost like to celebrate when they found bugs, because that’s what they were being measured for. Right. And so he almost ended up with this, like, very heated sort of culture and very defensive culture of developers saying, no, that’s not a bug. That’s, you know, that’s, that’s a new feature request or modification. And it was so much energy into like that sort of debating about whether something was a feature or not, that people lost sight of the bigger picture of, are we actually delivering value, right? Like, what’s, what is it that, you know, the user needs? What’s the trade off for that? And can we get to those people faster. And that is the system that some managers had set up. We call it a less than optimal system. And in order to change that, you know, you couldn’t really talk to a tester or a developer to say, Hey, you know, like, we need to change the way that you’ve measured that set up by other people in the business. So I think that’s something that I see managers responsible for, which is looking at the incentives and processes and structure that are often the things that get in people’s way. If managers listen to people in a team. You know, like The little bell here, what frustrates them, but they just step back to ask themselves what in the environment is contributing to that. And so in this example, you know, like by changing the sort of metrics and the measurements away from individual goals, or individual sort of functional goals, to a shared team goal of shipping a valuable good quality feature quick, you know, that changes it away from an individual target to actually shoot a target, which then incentivizes more teamwork, rather than sort of,I’m done with my part, now go off and do your part as well. And so that’s what I think of when I think about managing things and managing the system. 

Aydin Mirzaee (Fellow.app)  25:36

That’s the best example. I love that example. And it’s so it’s so true. And I feel like especially between cross departmental initiatives, you know, you could see things just like what you said also between, say, marketing and sales, you know, like, there’s not enough leads, or the leads are not good quality, or, you know, our close rate is down. And, you know, it’s just, it’s very interesting, right? Like, you see these sorts of things. And I love your approach of saying, Well, actually, these are not bad people. It’s just like, the system is rigged in a way that they’re going to have, there’s gonna be contention. And yeah, I think it also takes a certain level of like, skill to be able to, like, take a step back and take a holistic view like that.

Pat Kua (Tech Lead Academy)  26:23

Absolutely. I mean, as you said, you see this in many other departments that are very common, what everyone’s probably suffered as a result is typical customer service, right. So there are many sorts of systems set up where customer services are set up to resolve as many calls as they can, within a certain amount of time. And a great way that people can gain that system is simply just canceling a call with somebody, right? As a user, you get really frustrated, because you have to then call back, or from their side that dealt with a ticket. And then

Aydin Mirzaee (Fellow.app)  26:51

Yeah, it’s, it’s so interesting, I love that that’s such a good example, in terms of so we’ve talked about now a little bit about goals. And, you know, one of the things that you talk a lot about is just the importance of constraints. And, you know, when you do have goals, and you know, like, as a manager or leader, you go to a team and you give them this goal or a task. What are the things that people usually get wrong when doing that? Or what are some common mistakes?

Pat Kua (Tech Lead Academy)  27:26

Yeah, so I think one common mistake because I, when I think about this, are sort of new constraints. And a classic example is go off and do something without actually a time constraint, right. And so I think it’s Parkinson’s Law, which is like, you know, a work item will feel whatever available time that you have, and I see this with engineers all the time, in particular, who will go off and then they’ll find something else to work on that it’s kind of related to that, and they’ll just kind of keep digging, and then you’re all the time is going by and they’ve gone. Okay, this is the thing that I was supposed to actually work on first. And so one constraint I would often think about is sort of imposing a time constraint. That’s why I like things like, sort of extreme programming and Scrum is that there’s a built in review point, like once a week, or once every fortnight or two weeks, to sort of ask, you know, did we set out to do the things that we did? And how did we do based on what we planned for that time period? To me, it’s less important, if people are hitting them, it’s more of a question of, Okay, if they didn’t do that, why or why not? What is it about the system? Is it about clarity? Is it about information, what can we do to help unlock that, but you get some feedback and information. And so I think if you don’t have any constraints, particularly with time, then, you know, you often end up with very divergent expectations. And that leads to a lot of conflict a lot later. You know, without the time constraint as well, I think it also means that people don’t get an opportunity to learn. So they get that delayed feedback, which means that they can’t really adjust this sort of behavior. Another common example of forgetting about constraints, and I think a lot of this comes down to, you know, the wanting to give more autonomy to people is, you know, using your best judgment. And the problem with, you know, something so broad like this is everyone has a different sort of perception about what best means in that context. And so I can tend to think about this factually. So you know, you have your best judgment based on you as a person. But you know, you and the people that you’re working with in your team may have very different perceptions. I’ll see this quite frequently, if people are doing code reviews, you know, that people might give feedback quite differently, because they have a different perception of best. And then there’s a lot of conflict over whether they should address that comment in a code review or not, because you know, people have different standards. And I think one thing that managers can do here, which I have often done is to sort of help agree on a team approach. So make the sort of constraint agreed and visible, so that you all have at least a shared vocabulary around maybe What, you know, good quality looks like for this particular team. So I think there are a couple of mistakes that a lot of managers make.

Aydin Mirzaee (Fellow.app)  30:08

Yeah, you know, it’s really interesting as it relates to developers, at least I know there’s also this term called Yak shaving, which is, which is very similar. It’s, you do all these other things, and you don’t get to the main thing, because, you know, because of the lack of constraint, I like that a lot. I feel like, especially when you’re managing or leading a team, like there are so many different ways that you could spend your time like it. And there isn’t necessarily the super defined playbook, maybe there’s things like, well, we need to do one on ones and Okay, so that that’s a few hours a week. But it’s not like there’s this like, super defined playbook. So how do you decide what to prioritize? And what to work on?

Pat Kua (Tech Lead Academy)  30:52

A really great question. And it’s a very common sort of example, I think it’s kind of interesting, because I’ve been running some training with some early stage leaders. And one interesting feedback I got recently was like, Pat, you need to tell us where we should prioritize our time, right? Like, that’s a struggle that everyone always talks with. The challenge is that it depends, but I’ll talk about why it depends. You know, I think ultimately, for me, the guiding, answer, or how to answer this question is really contextual. And so you need to understand a lot about, you know, what are constraints in the system, or things that the team is struggling with, you know, the things that if you do something may actually have not so much impact in one situation versus more impact in another. And so in order to sort of answer this question, I asked a slightly different question, which is, if I was to do one action, what one action would have the most impact? Right? So it’s very easy to sort of take lots of action, but you don’t sort of think about it like, Okay, how much effect is that going to have? That’s one of the reasons I sort of think about that sort of system is that, you know, a good example is, you know, one way of dealing with an emergency is okay, I’m going to get my hands involved, and I’m going to take care of that emergency, right? mergency, solved, done, you know, what may happen is, if you haven’t actually sort of treated where that comes from, you may find yourself solving that emergency again and again. And so the thing that I will be always thinking about is, am I sort of multiplying and improving sort of the system? And what action would I take to actually improve that? And so that’s a real, situational, contextual sort of question, because it’ll depend on the people that you’re working with, it’ll depend on what problems your team are currently facing. If you’re dealing with a very junior team, you know, the most impactful thing that you might be able to do, which I’ve done a lot is, you know, to take the team aside, and actually to train them like to walk them through best practices of how to do work together, you know, about either designing code writing code, or or, you know, using good design patterns. For a more experienced team, that same action has much, much less impact, right. So, you know, taking them aside and teaching them basic principles, they’ll be like, what are you doing, I already know this. And so in that case, we’re more senior team, the most impactful action that you might have is helping them maybe with once again, the typically organizational bureaucracy, it might be about influencing the team and getting buy in about some sort of work that needs to get done at the same time, or about trying to get, you know, an investment in dealing with technical quality or, you know, some sort of investment. But, you know, I think that’s the question that everyone has to answer for themselves in their situation, which is, you know, if we have a limited amount of time, the question is, what can you do to have the most impact from that time. And so, you know, a good way to do that is to sort of brainstorm all the possible problems that you have. And then to think about which of those problems is the most constraining. And so this is kind of taking a little bit of that period constraints. And if you relieve that constraint a little bit, you can actually have the most impact from that side. So you can think about it from that side, if you feel that you’re in a really great place. So you feel like you’ve built a really high performing team, then what I would do is sort of brainstorm a list of sorts of experiments. So things that we might try doing that have the potential for, you know, high impact. The thing is, if you’re already in a pretty good place, you don’t really know what the impact is going to be, unlike dealing with a very large constraint, where you can sort of say, okay, that’s slowing us down. Well, that’s distracting the slot. But you know, if you’re in a good place, then you can think about experimenting. And I think that’s a nice way to sort of prioritize those two worlds.

Aydin Mirzaee (Fellow.app)  34:37

Yeah, I think that makes a lot of sense. And it’s very interesting that you just call out again, just going back to the system approach because I’m spending my time, you know, hopefully, like there aren’t these recurring problems or like the system gets better. So like, I don’t have to spend the same amount of time doing you know, the same thing next week or next month. Yeah, it’s just, it’s just a really, really good way to approach things. You know, another topic I wanted to chat with you about is, and it kind of relates to systems again, here is you have this quote where you say, Tell me how you measure me, and I’ll tell you how I behave. ” And we had an example of this where you were talking about, you know, the developers and, and the QA folks, are there other examples where, you know, policies can really shape the culture of the team?

Pat Kua (Tech Lead Academy)  35:33

Yeah, absolutely. Um, another common one that I see a lot, which you see less of these days, is typically when you have a very different department or organization dealing with operations, that infrastructure, and you have a team that’s producing software. And so you know, I see this more classically, in large organizations that have been around for a long time, just because that’s how their organizational structure evolves. So remember, one client where, you know, you had a head of operations, infrastructure, and then you had a head of development, they had large teams responsible, you know, development teams on one side, and then people who are responsible for networks, servers, all these other sort of things. They’re now the people in operations and infrastructure, if you sort of think of them separately, one common goal or target they typically have is stability and resilience, right. So no downtime, lack of breakages. You know, that’s kind of one sort of goal. And then development, that often you get a lot of pressure from the rest of business around new product development, new features, you know, and this creates like this interesting tension, because a really great way of ensuring good uptime and resilience is by not making any changes, right? Like, you kind of set up a system and a conflict where from an operations infrastructure side, a great way of, you know, maintaining resilience is to make sure that anything that development teams produce are bulletproof, right? Like go through every single checklist that proves every single test case. And you kind of have this sort of opposing sort of set of motions where development teams want to release quickly. But now they feel these constraints from operations infrastructure, saying they have to go through all these rigorous checklists, they have to get reviews, they have to go through all these sign off processes. And it feels like a slow process. And this is one of the reasons why I think DevOps as a culture as a way of working has been so popular and so essential, is that that is an organizational conflict set up by these opposing sort of measurement structures. And in order to sort of address that, then there’s better ways of doing that. And the book, if you want to learn more about this, is from the accelerate. So this is by Dr. Nicole Forsgren, plus a number of other authors. And it kind of shows some of the other metrics, which are a lot more holistic. So not necessarily thinking about departmental goals about parts in a value chain, but actually optimizing for the entire value chain as well.

Aydin Mirzaee (Fellow.app)  38:00

I think that’s awesome. In your book, you mentioned something called the Fixler rule. What is that? 

Pat Kua (Tech Lead Academy)  38:08

No, I think, um, this came from a different organization. So this is really interesting, a lot of people spend a lot of time in meetings. But I think a lot of meetings are poorly conducted. I mean, I think, sort of the reasons why your tool exists to help people produce better meetings. And so that rule Yeah, is, you know, if a meeting isn’t providing any value, having more people in a meeting tends to slow down. And so the theory of leaving the meeting, if you feel that it’s no longer offering any value from you, is that something that, culturally, you encourage in your teams, for people to just come in and go out? When does it make sense? I do encourage it. But I think it’s very hard for people to do that. Because I think human norms, or maybe other company norms tend to override that, which is like people join a meeting and then leave the meeting when it’s officially announced.

Aydin Mirzaee (Fellow.app)  38:57

No, it’s interesting. And then, of course, there’s this concept of like, dynamic agendas to where, if you know that you’re going to be going for a period of time and really, like you really need a certain person’s input for a portion of it, like maybe they can come in for that part. And then, you know, obviously, like, and then after that 20 minute period or something, then they can then make an exit. So yeah, like you said, there’s probably ways that one one could encourage that even more. So Pat, this has been incredibly valuable. So many great insights, so many great examples, so much learning about systems in general. One question that we ask all of the guests that we have on the show is for all the managers and leaders out there looking to constantly get better at their craft of managing and leading teams, what words of wisdom just tips or trick resources or just parting advice would you leave them with?

Pat Kua (Tech Lead Academy)  39:54

Yeah, I think um, if I select one final tip is that I think as an industry, we’ve got a lot better at providing information and resources to support people, I think everyone is at a different point in their leadership training. So some people might have picked up, you know, better communication skills, other people better mediation or conflict management skills. But we have so much opportunity to always improve. And so like with a lot of things in life, it’s a sort of journey, not an end. And I think it’s very helpful to join a community to look out explicitly for resources to continually hone and improve your particular skills. So you know, join, listen to these podcasts that give you more tips about being a great manager, join communities, read a lot more books, and I think you’ll be a much better and stronger leader and manager as a result.

Aydin Mirzaee (Fellow.app)  40:41

And that’s great advice and a great place to end it. Pat, thanks so much for doing this. 

Pat Kua (Tech Lead Academy)  40:46

Thanks very much for having me. Nice chatting to you.