Amy Phillips 0:02
Welcome to the Humans+Tech podcast. I'm Amy Phillips. And this is Aaron Randall.
Aaron Randall 0:07
Hi.
Amy Phillips 0:08
Today we're so excited to be talking to the one and only Patrick Kua. Pat's an incredibly experienced tech leader, most recently as CTO and N26. He's also a regular keynote speaker, mentor, author of three books, and curator of the awesome Level Up newsletter. He's recently launched the Tech Lead Academy with his first course 'Time Management for Tech Leaders', so Pat, welcome to the show.
Pat Kua 0:32
Thank you for having me. It's a great pleasure to speak to both of you.
Amy Phillips 0:36
So to dive straight into possibly maybe our favorite part of the show where
Aaron Randall 0:42
the most important part of the show
Amy Phillips 0:44
definitely the most important part of the show. It's really kind of like customary for us to draw all of our Humans+Tech guests a doodle of them which we put in the show notes. So I'm going to show you your doodle be great to get some feedback you know, just we're going for like likeness of course.
Pat Kua 1:02
Okay.
Aaron Randall 1:05
I'm really sorry in advance.
Pat Kua 1:06
This is exciting. I have no talent for drawing, so
Aaron Randall 1:09
I would, neither do I apparently.
Pat Kua 1:13
Oh, that's really good. I like it, I like it
Aaron Randall 1:20
I really focus on, I think I've got the glasses right.
Pat Kua 1:25
You've got all the characteristics
Amy Phillips 1:33
Yeah.
Aaron Randall 1:34
Amy was saying before for the show that I made you that like a sausage
Amy Phillips 1:37
I think you came off like kind of unfortunate. I think people had longer hair look less like everyone's kind of same basic shape.
Aaron Randall 1:51
Say, yeah, there we go. Great. Well, that's the important stuff done. Sorry again, apologies in advance. And so as Amy mentioned, you recently launched TechLead.Academy.
Pat Kua 2:00
Yeah.
Aaron Randall 2:01
Where you're running a course on time management for tech leaders. Why do you think time management is such a common problem for tech leaders?
Pat Kua 2:08
Yeah, it's one of those issues which, you know, I think not just tech leaders struggle with, but anybody in general. And one of the things that I think was really beneficial, or I learned a lot through consulting was how to manage my own time. It's like one of those things where you kind of have to be independent a lot and try to work out how to get the most done, often without a lot of support. You know, you're obviously working with the team and things like that. But it's one of those things that I think a lot of leaders when they fall into this role for the first time, nobody's really given them skills. So just like a lot of other skills that are needed to be a good leader, nobody's teaching them these are important things you need to focus on. And so what normally happens is when people fall into that, that sort of role, you know, they're sort of overwhelmed. I think, by all the other things that they have to do that they don't really think about how do they manage their own productivity. And you know, there's kind of the awareness problem, you don't know what you don't know, and then realize that it's a problem. And then you're maybe a little bit overwhelmed to actually solve it. And so you know, one of my things that I normally do for first time leaders is walk people through how to manage their own time. Because, you know, the less time you have, the more reactionary you're going to be, the more stress you have, the less time you end up with, and you end up in this vicious cycle. And so I want to help people basically change that cycle to a positive cycle of if you manage your time well, you'll be able to react a lot more thoughtfully, you'll be calmer, and then that will actually help you create more time.
Aaron Randall 3:38
That's awesome. And without giving away too much in the syllabus because obviously that's your job is to teach it a sense of the kinds of things you're going to cover in that course.
Pat Kua 3:47
Yeah, absolutely. Um, you know, I think one of the topics I cover in there is kind of like this difference between sort of maker and manager mode. I kind of prefer the term multiplier because not all technical leaders are managers, but you know there's a difference between working at a keyboard tapping away deep thought, and then switching into lots of context switching lots of interrupt mode of meeting to meeting to meeting conversation to conversation. And those two worlds don't really mix together. And you know, I've been there myself where you're just sort of caught in between. And if you're not explicit in managing that sort of separation of sort of maker versus manager or multiplayer time, then you're just going to get really stressed out. So that's an example around that sort of example. I think one of the other things that I can sort of cover is really about, like, how do you start to prioritize your time? This is one of those things that you know, when you're working as an individual contributor or a team member, normally the team has a process to manage priorities. But suddenly, when you're that sort of leader, it's like, oh, you just have this influx of things. Lots more things to do. You don't really know you say yes to everything. And once again, part of the art of prioritizing is knowing what to say no to or maybe not yet, and how to break things into smaller chunks. So that's another sort of key thing about a key topic that we cover.
Aaron Randall 5:08
I mean, I wish I had this.
Amy Phillips 5:11
Like these are skills I definitely would love to have. Like it is really hard, though. And I think it's, I've definitely seen a lot of I've been in a lot of conversations where people are saying, like, you know, I'm going to, you know, I need to, I don't know, write this piece of documentation, should this be a JIRA ticket? And it's like, you know, yeah, so like you say we've got really good processes for prioritizing and tracking, like normal, normal work. But as soon as you step outside of like, it's not code or it's not something the team cares about It can be really hard to fit that in.
Pat Kua 5:41
Exactly. Yeah. And I think one of the things that I noticed is that you tend to like watch other people when you're in that sort of thing about asking them how do you like cope with this, kind of a building out toolkit, and I think that's the other sort of side of it is that you kind of never done with it. Like, I still always look for other productivity tips and ways that other people do things and I still learn from like everyone about like different, you know, ways of managing email or calendars or other sort of time activities. Yeah. And so you're never ever done.
Amy Phillips 6:10
I love that, like, how can we get a productivity tip? Like I love these things.
Pat Kua 6:15
Yeah. So my favorite is actually using the Send Later in Gmail. So part of that is it's like as a manager or leader, you know, some people feel like you have to instantly respond. And obviously, if you do this to people who they perceive you as a leader, they feel you know, they have to respond to you immediately. And sometimes when you're processing a whole bunch of emails in one block, I don't want to trigger a whole bunch of replies immediately. And I don't want to like sort of stress other people out so I love the whole Send Later kind of feature. My hack before it was actually available in Gmail was actually to put calendar reminders in so I'd save drafts, and then have calendar reminders to actually send them. We couldn't quite connect something like Boomerang, which was an add-on to Gmail just because it has access to all your emails
Amy Phillips 7:02
I think that's so important though, like I do, like I'd love to be able to work as a time which you know, suits me and obviously other people ideally should do the same. But sometimes that is like, Saturday morning at eight o'clock and it looks terrible. I don't want to say that everybody should be writing emails at eight o'clock on Saturday, but for me that actually sometimes it's exactly when I want to write them. So yeah, I love that send later. People must this I'm so productive at eight o'clock on a Monday morning.
Aaron Randall 7:32
12 emails go out and same time. Yeah. I do that thing with it where I give it like send in the morning at 9am I always make it like 9:04. What monster leaves it at a round number? Yeah.
Amy Phillips 7:50
Awesome. So I love the bit, that sort of you mentioned as well there about like people falling into this role becaus e I think one thing Aaron and I were actually talking a little bit earlier about tech leads and it's like It's such a critical role. But also, it's quite a difficult role, because it's probably the first time you're in kind of leadership. And you are probably still writing quite a bit of code, but also sort of playing this multiplier right. I know that you've actually given quite a lot of talks about and actually read a book about as well. which is quite cool. So what what do you think makes a great tech lead?
Pat Kua 8:23
Yeah, it's a good question. You know, I think a great tech lead is a person who knows how to be flexible in their leadership style. And I think part of that is obviously you build up experience over time. But I think you know, the trap that a lot of first time tech leaders fall into is still thinking like a developer, right? They want to be the expert person, they want to deal with all the hard problems they want to be seen as the go to person for all the questions and information. And you know, if you're with a team of very inexperienced people, you know, the most senior developer a tech lead may be suitable to be the person who gives answers. But that's not going to be sustainable as people learn and grow. And you know, as more work comes to a team. And so I think that's a real key for a lot of successful tech leaders is that they know how to adapt that style. I think the other thing, why I sort of focus on this sort of adaptability is, you know, everyone is really different. Everyone has personal preferences, styles, communication, wants and dis-wants. And you know, I think a lot of first time tech leaders fall into that trap where, you know, everyone will they believe that everyone acts and feels the same as they do. And I think that's the interesting thing. And you know, this both being like managers and leaders, of the variety of people, things that your preferences and differences that you've never ever done, you can never really predict. You think you'll you know, you know how somebody's gonna react, but you never, you're always surprised, right? And I think that's the thing of like a good tech lead of being able to be flexible in understanding you know, some people will maybe want to have one to ones and be told news personally. Other people would perhaps like to read things more so than be dragged into a meeting or, you know, have some time to digest information before talking stuff through. Some people will want to work through a problem other people need to talk through a problem. And so you know, there's all of these different styles that you sort of build up over time through experiences. And I think that's what really makes a great tech lead.
Amy Phillips 10:20
I mean, love that. Yeah,
Aaron Randall 10:21
that's awesome. And when you're talking about those traits, it made me think about the times I've helped create new tech leads in my teams over the years. One of the things that I've noticed in them is that they tend, there's a tendency to create process everywhere, as they're stepping up. And I've seen it as a patten I've observed I was wondering, have you seen that and why do you think happens?
Pat Kua 10:45
Yeah, I think so. I think some of the process that I think comes is you know, people going you kind of imprint like you think about like what other people have done who you like, either respect or often it's the I don't want to do this bad thing because I had a bad lead or a bad manager. So I'll do the opposite. And so it's often like the strong reaction to, you know, this kind of first time falling into that role. I think it's also just an actual consequence of learning. Right? So I think, you know, I've studied a little different learning models, if you take the shoe heart re shoe is like you follow the rules, right? And I think the process is an example of following rules. And then over time, you start to work out those rules start to break, they don't apply everywhere. Oh, my goodness, this world is much more complex. Hopefully, people get there really fast instead of, you know, using this process and overhead all the time. And I think that's the hard thing about a lot of leaders is that they don't get a lot of support. And, you know, the experiment is kind of their team, right. And so that's kind of a hard thing to experiment with, because it's having impact on people on work product. It's harder to make mistakes than you know, writing a bit of code on a sort of dev machine and having it break. And so I think that's why a lot of organizations and it's great to hear that, you know, you've been supporting people in that, because I also think it's a responsibility of all leaders to sort of support new leaders, because a lot of organizations do it really poorly.
Aaron Randall 12:10
Mm hmm. I mean, let's talk about that as well that's a great point. Amazing that TechLead.Academy exists, and that you've created something that helps train tech leads, but why do you think that needs to exist? Why why tech is not getting the support they need in house?
Pat Kua 12:24
Yeah, I, it's an interesting question, because I've puzzled a long time around this. And I'll give you a little bit of history about how a lot of the training that I sort of built came about is that, you know, I also suffered as a first time tech lead. I got a call from staffing, you know, asking me to take on this role. Nobody really walked me through what was the differences? Like what did I need to focus on what did good look like? Where did I have skill gaps? Or, you know, where did I need to start focusing, you know, my own personal development. And you know, sometimes it's like one of those things where that sort of sink or swim kind of experience can really turn people off leadership or it can really, you know, help you gain a lot of confidence. And, you know, I saw a lot of people go through this process of being a first time tech lead, I talked to a lot of people around this in the book as well. And I think one interesting thing is a lot of support. Learning development often comes from kind of the people team or HR department. And it's kind of interesting, because they kind of have a high level idea about like what these people do, but it's out of context, and they don't really know the day to day. And so the consequences is they often organize leadership training it has a cross section of people across the organization. It's really great because you build a network and you learn some generals and leadership skills, but the scenarios that you're going to play with and the problems that you're going to face in your context as a tech lead, are very different than if you're going to be leading a team, say in marketing or in a sort of sales team. And so it's very hard to then translate that sort of theoretical or the classroom experience into, like, here's a situation gonna have like, what are your options? How are you going to deal with it? What might go wrong with that. And so I realized it had to come from people who sort of been there before, but also who could teach because I think that's the other sort of aspect of it is that, you know, obviously get other people at tell other tech leads, here's how you have to do it. But once again, that adaptability is a reflection of experience of understanding people will lead differently, they'll have to also take on skills differently, they'll need to learn differently. And so it's just really hard to get that support for a lot of people.
Amy Phillips 14:34
Like, like, I think it is really interesting, like when if you're lucky you get some in-house training, but but yeah, it probably doesn't help you balance like the, you know, one hand you've got, like some production incident that you're suddenly quite responsible for, but also, you know, someone else on your team is upset in a different, completely different reason in a different way. And you kind of got to juggle these two new problems.
Pat Kua 15:00
Yeah, exactly. Yeah. And and one of the examples that we normally cover in the course is around sort of conflict resolution, right, with developers arguing over which library do I use for this thing? I have two solutions, and you just have these developers butting heads. It's like, now you have to come in and like, work out how to get this, you know, through. And that's something that people just don't really, you know, get walked through that example.
Amy Phillips 15:22
Yeah, so true. And I think probably one of the other things, which I think is maybe uniquely difficult at this stage is that I think most tech leads are kind of promoted into the role like like, especially like new tech leads which means they go from being one of the team to suddenly leading this team. And that's quite a difficult transition as well, I think.
Pat Kua 15:41
Yes, yeah, definitely. There's sort of that peer to being a leader, sort of transition, change in relationships. I also forgot to add that I think with tech leads in particular, there's a slight difference as well with them stepping into a leadership role, or the tech lead role because there's also this idea of architecture that often doesn't really get talked about and so this is something that, you know, a lot of developers have never had an experience with, because their tech leads took care of a lot of that, right. So if you're building a new system, you're often in conversations with people in operations infrastructure, if you're in a place where you host it, you have a lot of procurement processes, potentially, a lot of upfront planning, you have to involve support people, you have to think about all these other things. And often the rest of the team aren't even aware about a lot of that responsibility, because the tech lead was taking care of it. And so when they fall into that role, that's another trap is that any of these sort of broader systems sort of architecture perspectives, they don't realize it's their responsibility. And no leadership course is going to teach them that it's actually they have to deal with these
Amy Phillips 16:44
And I guess that ties right back to the whole time management challenge as well, which is, you've suddenly got this whole you're expected to have a, I don't know like a two year roadmap and you're worrying about this bug.
Aaron Randall 16:59
And you've got no time to write code.
Amy Phillips 17:03
One of your talks you've given in the past Pat was called 'What I wish I knew as a first time tech lead' What, What do you wish that you had known? or What do you wish that every tech lead knew when they started out in the role?
Pat Kua 17:17
Ah, that's a while ago that talk. So I was going to have to think back but off the cuff, I think. I think one thing is like how your where your value is or where your reward center is. And I think that's why it's an interesting thing of thinking about this maker versus multiplier mindset. Because I think, you know, makers, you get the satisfaction. And I know, this as a developer, I still love writing code and seeing the output and seeing this kind of fast result. But then when you're leading a team, you're often not writing a lot of code and you're kind of like feeling guilty because it's like, ah, but like, I don't have anything visible like I haven't been putting features through. And you know, that's another thing that fits the time management thing of like you're trying to put as many features through as every other developer, but then you're also trying to take care of all these other responsibilities. And actually just simply that message and helping new people in that role understand, actually, if you're spending that much time writing code, you're probably not taking care of a lot of other things that you are responsible for. So it's okay. And nobody is giving them that reassurance of actually, you know, like, here is where you should be adding your value. And here are the sort of, I guess, signs that you're doing this, you know, the team is healthy, the code quality isn't diminishing, is that, you know, developers productivity is going well, because you're managing things like build times, test times, being able to deploy things really rapidly give people fast feedback, working well with product people, so that, you know, it's balancing technical risk, as well as delivering value not just going off and building your own technical solution, because it's fun. You know, it's all of these interesting sort of reward signs, but nobody tells you what they are. And I think that would have been, you know, just a simple walkthrough of like, what this role is why it's so different. And also just how to prepare yourself for it.
Aaron Randall 19:05
That's a great I remember, like, after a little while of tech leading having to ask myself the question like, what am I not doing when I'm doing this? And when I'm writing code, there's always stuff I should have been doing that no one else in team would have done because not their job as they're not the tech lead. And yeah, just falls to the wayside.
Pat Kua 19:20
Yeah.
Aaron Randall 19:20
Good to remind yourself.
Pat Kua 19:21
And it's really interesting, actually, because I think, you know, there's the what I wish I knew as a first time tech lead, but I think actually, there's something that what I wish every developer knew about leaders and managers, because I think that's the other flip side is that people don't understand the value add. And, you know, I'm a little bit tired of developers kind of automatically dismissing managers as overhead or leaders, because there is a huge value add, and often their association is really with bad management, bad leaders, which is totally understandable if people get thrown in there for the first time without a lot of support, right, it's a bad system that kind of does that. But there are also so many excellent leaders and managers out there and they do add a lot of value and I think that's something that I wish that a lot of developers and makers really understood about the value of good management, the value of good leadership, because it just makes everyone's life a lot easier.
Aaron Randall 20:08
How do we do that? That's such a great point.
Pat Kua 20:12
Well, I don't know how you how it's possible. But I think one thought experiment I've had, but it's a little bit harsh, is like forcing people to have a bad manager and then to have a good manager, because then they start to realize the contrast effect.
Amy Phillips 20:26
Yeah, I think that's true. I mean, I feel like most people, unfortunately do have certainly had at least one bad manager. So yeah, but it's it is quite surprising to me how many people have not had a good manager or not, maybe not a good manager for them. I think that's the other piece, right? Like, yeah, yeah. It's such a shame like the poor people who've never had a good manager. It's like they're missing out so much.
Aaron Randall 20:52
It's really disappointing, very sad.
Amy Phillips 20:54
It really is. Yeah.
Aaron Randall 20:56
So you recently gave a talk called The Secrets of a Strong Engineering Culture'.
Pat Kua 21:00
Yeah.
Aaron Randall 21:01
What do you think are the key elements in creating a healthy culture for a tech team?
Pat Kua 21:05
Yeah, I think there's a lot of things that leaders can do around culture. And I think the first thing I want to sort of say is that culture is not something that you create, for me, it's something and I use the metaphor of like gardening. And in reality, I'm a really bad gardener. I can't keep anything alive I think I'm not consistent enough, maybe I care more about people than about like plants. But um, you know, like, a gardening sort of metaphor, you can't force a plant to grow. Right. And I think that's the other thing is that I think sometimes there's this metaphor of like, leaders, being parents treating people as like children, and I don't really like that metaphor, because you are also dealing with adults, right? So they also have a sense of individuality. You know, and, for me, a lot of the things that you can do as a leader is really thinking about those traits that you couldn't foster that sort of create the best environment for those people to thrive. So that's the sort of fertilizing metaphor. Thinking about like, what nutrients or sunlight, or water, but also being very deliberate about the type of culture that you want to create. And I think that's the exciting thing about being a leader is that you sort of get to focus on that a lot more, right? So if you want to encourage more collaboration, you know, measuring people as a team, rather than as individuals is a really great way of starting to sort of do this and encourage people to want to work together because they're measured by being working together, versus very individual sort of targets or goals. You know, I think the other thing that I see about cultivating good engineering culture is that, you know, there's a big mindset shift. I'm working on a course about systems thinking, and it's all about mental models. One of the mental models we're talking about is like the idea of, you know, developers, like just people that you tell what to do, right? They like factory workers, you like build the plan, and then everyone just, the developers will execute and you know, I don't know of any developer that's like that unless they've been beaten by the system, where all their creativity is already been sort of beaten out of them for being punished. But most engineers want to learn, they want to solve problems, and they want to add value, right? So the reason why I think a lot of developers get into programming is because they get to solve problems. They learn new tools, they learn new approaches. And I think that's a huge mindset shift of thinking about how do you foster that environment where you basically are sort of giving them hairy, bigger problems, but also making sure that they can solve them without sort of failing spectacularly. But you don't need to be the person that is like the person solving the problem for them, and then telling them how to actually solve it. It's really creating that right environment where people feel empowered. And you know, I think one of the good books around this is the Dan Pink's Drive book, which talks about this sort of autonomy mastery purpose, where, you know, the autonomy thing is that developers get to choose, I guess the way that they break down a problem they may not necessary get to choose the problems that they have, because every organization needs to have like priorities, right? So there needs to be some sort of how it links to the greater good. But I think that if that's done well, you can then link that to the greater purpose of the mission of the company of whatever the product is and help people see that path to how their work contributes for greater sort of good. And I think when I think about the engineering cultures, where it's like, really good and versus where it's really bad, it's often where, you know, developers are really close to the customer, because they can see the impact of the work that they're having an immediate value. The further I think developers away from an end user and a customer, the more that they're just going to start to play around with tools because they don't really understand how their work solves real world problems. Yeah, so there's some of the things that I would be thinking about with like engineering culture.
Aaron Randall 24:52
That's awesome. Um, I guess, leading on from that, you know, so you mentioned before we started recording the podcast, you you've worked at N26 and grew the team there from five to 110 people did you say?
Pat Kua 25:05
it was from 50 to 370 People
Aaron Randall 25:07
Oh, wow. Even more so. So significant growth. And by the way, I love the gardening metaphor for culture. I think that's amazing. My question is, as you take a team though that kind of growth, and a culture presumably does change, like how do you keep a healthy engineering culture through that kind of rapid growth and scaling?
Pat Kua 25:26
Yeah, so one of the things that we were really deliberate with, with our growth was really thinking about at different scales and stages 'what does autonomy look like?' And I think this is one of the hard things about people who've been at startups, and they see that rapid growth is that, you know, there's a sense of impact feels less like if you're five people, it feels like can change everything. But you know, when I left N26, I think the whole company was about 1700 people. Right? And if you were one of those early stage people, obviously it's like, well, like what are the rest of the people doing? What am I doing and and how is that actually having a big impact? And I think part of the art, I guess, of scaling an organization through that process is once again trying to help people understand where their boundaries of autonomy, or, where their purpose, right. So having a developer that's trying to fix everyone's sort of product issues. firefighting is okay in the very, very early stage of a startup. Because it's not very probably many customers, there's not too much sort of code or too many products. But as your product sort of grows, as you have more complexity, you're just going to be on a path to burnout. And so that's one thing that I really wanted to balance out is helping people understand it's not because like, we don't want you to have access to all of these different products, but you know, you're not going to be able to do that sustainably. Right. So you know, we have lots of engineering teams building lots to code evolving lots of products, one person can't keep all of the changes in their head, and that level of complexity without you know, breaking down or burning themselves out at some point. And so what we used is what I call the Target Operating model which talks about what is a stage of, for a certain stage of the organization or number sort of size, what is a good balance of that structure that allows us to maintain the right level of autonomy and alignment. So, as a counter example, it doesn't make sense to have 50 teams when you have 50 people, right? So that's obviously too much overkill. And it probably doesn't make sense to probably have 20 teams either, because then there's small teams, lots of coordination. And so as a sort of team or group grows, it's trying to like create those identities that allow teams to work. So rather than having lots of people, it's really thinking about units as teams, and how do they work well, effectively around a particular goal or unit where they can have value, autonomy as much as possible. And also they can have a lot of speed without needing to coordinate with a lot of other organizations. And this is kind of, I guess, The inverse Conway kind of law of thinking about, okay, looking at your product, what are the areas that can be mostly independent, and grow a team and then maybe a small department or organization there. So to give you an idea, when I came in, we were about 50 people in tech, which included helpdesk and security. And then what we had with Target Operating Model Version One was planning for about 120 people. And so here is where we decided to have sort of very clear team boundaries. At least nominally, a lot of them were obviously very empty and theoretical until we actually started hiring people. But at least we understood about the sort of areas where, you know, we didn't want to add more people to a certain product because it wasn't complex enough, you just have people stepping on each other's toes. Other product areas, were not enough engineers, a lot of people on the path to burnout there as well. So they needed a lot more capacity, but also there was a lot more sort of essential complexity. So you can add in more teams that took care of certain parts of complexity there. But then, you know, as we hit about 120 150, people, obviously just having a lot of teams around, if you will, then even just taking a planning session with one person from each of those groups. You know, that's a meeting with 15 people, which is quite a lot as well. So and so this is where we evolved our model to go to Target Operating Model 1.1 where we introduced the idea of groups, so groups being a sort of collection of different teams in a product area. And then they will focus on a particular theme. So as an example, we had a group around payment infrastructure. So if you've ever dealt with payment infrastructure, it's very complex, very low level lots of standards. And also being a bank in Europe we had and moving to the UK into the US with lots of payment schemes galore. And so there's a lot of sort of, well, essential complexity, but it's also a little bit invisible because you don't really see it from a user perspective. So we can have a group around that. We could then have lots of sub teams within that group that could be focused on certain areas of complexity and grow and manage that. And then, as I left, we started a office in Barcelona, which ended up being about 110 people. We wanted that to be mostly independent as well. And, you know, the organization was growing. And so we also introduced the idea of segments. And this is the idea of how groups connected to a segment in that they will try to shift the same sort of major business goal. So we had a group around growth, for example, around sort of customer onboarding, all the things to do with sort of, I guess, SEO, all the onboarding channels, sort of lifecycle, which is a little bit more expensive, I guess, in banking, because of identity verification, and all these other processes. So all the groups that had anything to do with customer growth, were then sort of grouped together in a segment. And so that segment could sort of manage all its parties, and it's really just about trying to minimize the dependencies to reduce coordination. So teams and Groups can be as effective as possible.
Amy Phillips 31:03
So in terms of the sort of breaking down dependencies, I guess I'm kind of curious on like, that sounds like a very nice, neat growth sort of path, I imagine it gets messy in moments. But like, how did you go about like, was there, was there a time where you sort of realized like, Oh, actually, these two teams, they're in completely different places, but actually had some unexpected dependency? Like, how do you actually like, break those things apart?
Pat Kua 31:30
Yeah, it's a really great question. And I think I know a lot of people that go oh, another reorg or whatever. And I think part of that is a realization about Conway's Law. If you're adapting Conway's Law. One of the interesting things that I didn't really maybe appreciate as much as a consultant of helping companies go through this approach is, you know, as a consultant, you come in, you see a snapshot, you help people model like the domain, come up with dependencies, and you know, people then implement it, but in a startup really rapidly growing the interesting thing is the product changes really rapidly as well. And so I think that's the other thing is that, you know, as you add in complexity, the business is taking a bet, you don't really know how to deal with that complexity. So it's like, Okay, give it to an existing team. But at some point, you know, the complexity maybe has a life of its own, and it's a product area significant enough. And so if we're refactoring our architectures to maybe pull out a service, it also, then logically concludes, we should probably pull out a team to focus around that business capability. And so I think that's the thing, just like you get code wrong, and you have to refactor, sometimes rearchitect pieces, you kind of have to do the same to your organization as it's growing and learning. So I think that's the thing that I saw really rapidly in a very hyper growth sort of environment, just because product changes really, really rapidly, more complexity keeps adding in. And so you have to kind of respond to that and you make mistakes, right? So what you thought was going to be maybe simple actually. Now, there's a pendency because maybe a product person wanted a connection where there wasn't there before. And so it's like you still ship the product, because it's important in any business to ship. But then you kind of go, Oh, we have some tech debt or organizational debt. So we now need to like maybe deal with it more sustainably. And so that then leads to a refactoring or revision over the organization.
Amy Phillips 33:23
I love the way you described that and kind of like the technical terms, because if they I think people do panic, then they're like, oh, reorg everything's changing, but actually, they're really comfortable. Everyone's really comfortable with the idea of you refactor code, you don't always get it right. There will be bugs. Not the end of the world. So yeah, that's really nice.
Pat Kua 33:39
Yeah, I think part of the art was I was speaking to a CTO who struggled with this is that I think they went through too many iterations, too much variation. And I think that's the interesting thing about the change is that there's a difficult art. I don't know science, whatever, around trying to find the right time and place to make changes. So too early, you're probably going to end up over engineering an organization, too late and there's going to be a lot of sort of pain. And too frequently people are going to get that sort of change fatigue. And I think that's a interesting thing that people should be really deliberate about when they're sort of thinking about the organization design structure about, is there enough reason to do this. And one of the analogies I kind of think about is kind of pain driven development is it's kind of like, you know, sometimes you have parts of the codebase. It's a little bit like gnarly, but you can live with it, right? And then it's like something that you kind of keep coming back to every day that's really slowing you down. You really have to do something about that. And I think that's the same sort of idea and this is harder in the organization sense because you get so many different signals from people about you know, I don't like this, you know, that's not working or whatever. And, you know, part of the art is in trying to find, I guess, a common theme that is really having a big effect impact. So I look for sort of strength of signal, consistency of signal, and then applying my sort of systems thinking head on, is it a side product? Or is it actually caused by something, in our, sort of structure. So I don't want to just simply put a patch on it, but actually, I want to deal with that, like more holistically. And so I wouldn't like react immediately when people say, Oh, that's wrong. So we need to change something. But I'd really be looking for signs that gave me a sense of like, if we fix this thing, this will give us a good runway for another six to 12 months of we've made significant improvements for everyone.
Aaron Randall 35:37
Nice. I'm frantically writing notes, but so much I feel like I'm learning so much right now.
Amy Phillips 35:42
This is a selfish podcast we just...
Aaron Randall 35:48
It's just for ourselves yeah. Back to the 'Secrets of a Strong Engineering Culture' presentation, you gave, talk you gave, one of the things you mentioned on that is a five step recipe. I was wondering if you could tell us about that and talk us through it.
Pat Kua 35:59
Yeah. I can't, I have a really bad memory. So
Aaron Randall 36:03
I've got, I can prompt you.
Pat Kua 36:07
I need my crib notes. Yeah, maybe you can prompt me. Maybe I can talk through reasoning.
Aaron Randall 36:15
Yeah, of course. Yeah. So step one is gather input. Step two is publish tech culture. Three is prioritize key improvements, four is decide on actions. And five is repeat.
Pat Kua 36:24
Yeah, that's right. Thank you.
Aaron Randall 36:28
That's a great talk, everyone should watch it.
Pat Kua 36:30
Yeah, thank you. So I think, um, yeah, so it kind of follows a retrospective, but at an organizational level. So that's the way that I see it. And for me, software organizations are complex entities. And this is the whole thing about you can't just take Spotify model and and implant it into your organization. So you kind of have to work and do a bit of homework about actually understanding about what are your actual problems. So that's the idea about really gathering input. And you know, as a as an example with a target operating model, one of the first things I did was actually run team retrospectives with everyone. And I really tried to focus people on, I don't really want to hear about, like the problems within your team, I want to hear what's constraining your team. Like, I want to hear about the things that you feel your team can't address. You know, I expect you to be able to improve your own process your working team culture, but actually I want to understand a little bit more about how you work with the environment, but also the good things because I don't want to lose those things. And so that's the gathering input process. And then, Can you remind me the second step, sorry,
Aaron Randall 37:35
Publish your tech culture
Pat Kua 37:38
Sorry, memory like a frog. Yeah, no. So yeah, so publishing, I think, is a good way of really trying to codify it. And I think there's a power to simplification and I think by publishing it, you have to simplify. And I think it helps people understand what is what your culture values, and I think particularly If you're trying to nudge your culture in a certain way, that's also an important thing. You know, I'm always conscious that, you know, stated culture and culture in action is always a little bit different. But you also want to be clear about what you're going to reward. And that's really that stated culture. Right. So and I think it's to be fair with people, you want to be clear about what that is. I don't think it should be done in a vacuum. It's something that you should really be cultivating. And so that's one of the things that I was like listening into with teams as I was doing retrospectives was like, asking, you know, trying to listen for what is it that makes this organization different from other organizations that works here that if we lost that, it would feel like there's a big loss in the identity. So codifying and publishing I think helps people sort of rally around it, and then also helps give people that common vocabulary.
Aaron Randall 38:49
Hmm, that's awesome. I feel like when you talk about that, it sounds like almost going through the process of writing it down for the outside world. It's like a version of rubber ducking where it makes you sort of really think about how to best articulate it. If you really hold it true or not? And yeah, that's really, really cool. Yeah.
Pat Kua 39:03
And it's a really great way for you to keep yourself accountable as well of like going back to Am I doing something? As an example, you know, I knew that N26 was quite a pragmatic sort of culture, right. And so I knew maybe I needed to tone down my own personal idealistic sense, having come from a consulting background of actually not trying to do something that's too much of a stretch goal, but actually has to be really grounded in a lot of value, right? So to has to have a clear, concrete outcome has to be actionable. It's not just about like, complete blue sky thinking. Step three,
Aaron Randall 39:40
Prioritize key improvement areas.
Pat Kua 39:42
Yeah. You can't do everything. So this is like, once again, the whole time management thing, right. So I think the thing that every leader looks for is really the high impact actions. And I think that's the thing and, you know, I think a lot of startups and you know, like N26 included you always say that you're going to do a lot of things. And then things get out of hand or things distract you and you don't quite complete all those other things. But I think that's why it's quite important for leaders to go up with a list of here's all the things that we're going to do. But also, here's the things we're not going to do to manage expectations.
Aaron Randall
And that's actually as a team, what you're gonna, what you're gonna do what you're not going to do, Yeah, awesome. Awesome. And number four is decide on actions.
Pat Kua
Yeah. And so that's kind of really about, like actually taking care of them. So I think one of the things in communicating change is you want to be clear about I guess what's gonna happen next. So I think people are saying, you know, what does this mean people want to have an answer about okay, what does it, what does it mean for me in my day job, like, do I have to change something? Do I have to act differently, like I think that's that's a group responsibility. I don't think it's a great sort of idea to once again say, here's the ideal without giving people concrete things they can do to actually make steps towards that.
Aaron Randall
Great. And five is repeat. It's great.
Amy Phillips
I think it's really interesting. Like I love the I love the sort of like the actual writing it down and sharing it. Like, I think that's a step. Like I think it's really easy to hear things and be I go and I go and make that I can make this improvement, but you forget to kind of loop it back and actually really help people see I heard you, and we're doing something so you lose half of the benefit.
Pat Kua
Yeah, and I think that's a really great opportunity for a lot of leaders is that I think that's the, I guess one of the key things is working out how to shape that culture. You know, I think that's one of the reasons why a lot of people jump into a startup very early on because you can kind of shape and mold that culture, but trying to shape a very large organization and change that culture becomes a lot harder the bigger it gets, you know, I'm very impressed with a lot of the turnaround, I think from Microsoft that Satya has had in sort of Microsoft, which from my point of view was not always a developer friendly ecosystem, unless you were sort of Microsoft stack. But you know, now it's, you know, with GitHub and lots of other sort of open source stuff. It's been really interesting at that sort of transformation. But it's a hard journey. I can only imagine.
Amy Phillips
Yeah, I agree. I mean, like the I think the the thing that's really impressive is the speed at which they've done it, because I think that's the other thing that sort of, I mean, I'm a very, very impatient person. So like, for me, whenever you kind of go into these cultural things, like you're lucky if it's like six months, but often it's, you know, way longer to make significant changes. Yeah, it's like, I guess I suppose that's probably another piece that's kind of interesting. It's like what are what is the sort of realistic timeframe for you know, real team change or like that even yeah, just even within like a normal team like how, how long would like it take to properly bed in a cultural change?
Pat Kua
It's good question and I'm gonna give you the consultant answer. I'll ground it in a couple of reasons. Right. So I think it's not just about change, I think it's about what sort of change. And one of the reasons, you know, step one around gathering input and trying to understand the pain points is, obviously change will be a lot easier if people can understand how it helps their life get better. If it's change for the sake of change, then people are obviously going to resist and if they don't understand the value that they're personally going to have, they're not necessarily going to buy into it or they're not necessarily going to take action. And so I think that's one of the reasons why change by itself isn't so useful. It's really trying to understand what change is, you know, helping, right. So, you know, when I was consulting, I used to work with development teams who did a lot of manual testing. And it's like, like, I'm just like bashing my head on the keyboard redoing this test again. And again, it's like, wouldn't it be interesting if we could like automate this and then we wouldn't have to be doing all that typing, right? And it's like, over time, people started to understand, okay, like, like, I am wasting a lot of time running through the same scenario again, and again, I've written the scripts that only I can run that I can't share with my other team members. Maybe if we merge them in some way we could share, then we could actually save some time. And you know, that helping people understand how the change addresses their problem, I think is a key element to helping change accelerate. You know, I think the further out that change doesn't mean to somebody or a team, then it's not really gonna have so much of an impact. So that's why I don't think you can really instigate or you can really say how long change is going to take. My favorite mode of doing this with teams is really using sort of iterations or sprints, whatever your terminology might be as experiment cycles, right? So that's the beauty I love about retrospectives is that actually we can start doing a change next week. And we don't have to commit to it for life. If we don't like it, we can decide to roll it back, right? So we can try it out. See if we have a better life. We like it. Let's do more of it. And, you know, hopefully those habits start to or the positive habits that actually have impact start to escalate. Yes.
Aaron Randall
Am I hate to be the bearer of bad news, but unfortunately, we are running out of time. But before before we let you go, we have four quickfire questions that we ask all Humans+Tech podcast guests so I'm gonna dive into these. First one is what is your top book recommendation?
Pat Kua
I'm a big systems thinker. So I love Thinking In Systems by Donella Meadows. It's really accessible, easy to read. Yeah, love it.
Aaron Randall
Awesome. Amy, you're nodding your head like you know it
Amy Phillips
I love it, yeah great book. I think it's very interesting stuff.
Aaron Randall
Nice, question two is what tip do you wish you'd received when you first moved into tech leadership?
Pat Kua
Find a mentor. So I think that's somebody that's something nobody ever told me about. a, uh, yes, I would have loved to have that advice.
Aaron Randall
That's amazing advice. And that's, by the way, great advice for anyone in any kind of tech leadership, right?
Amy Phillips
In Tech, I thought you were going to to say. Nobody mentions it, for the first like, 10 15 years of your career, and it turns out, this is the secret.
Aaron Randall
But then you you get like four of them. Okay, question three is who inspires you in tech?
Pat Kua
Oh, who inspires me in tech? I have to give a lot of, so I spent a lot of my career at Thoughtworks and I have a lot of respect for Martan Fowler. Not just because he is like an amazing person who can summarize content in a really simple way. That's definitely something that inspires me, but the thing I want to point out is how he uses his platform to support other people. You may have noticed, probably over the last five years, maybe even earlier, he's getting a lot more people to publish articles on his platform, because he knows he has something that he can use, that helps people amplify their message. And I think that's something that I really appreciated from the sort of social and economic justice pillar from Thoughtworks is not just about tech or making money, but actually trying to use whatever power or influence you have for good. And I think he was a really great example of that of, you know, if, you know, he can't make a talk he would introduce and pass it on to somebody who might not have those talking opportunities. He was very generous with his own sort of personal platform. And it's a really great example of sort of paying it forward. And I think for me, that really is something that I really get inspired by and one of the reasons why I enjoy teaching and coaching and helping other people grow.
Aaron Randall
Hmm, that's great. Very nice. Question four, finally is what is the most ridiculous thing about you?
Pat Kua
Oh, I'm not very funny. I love laughing
Aaron Randall
We'll take it, very nice. Finally, where can people find out more about you?
Pat Kua
Yeah, you can find out more about me at PatKua.com or if you want to join the Level Up newsletter, it's at levelup.patkua.com
Aaron Randall
which you absolutely should join. Amy made me join because it's great.
Amy Phillips
It's such as great newsletter like, you know, I'm subscribed to quite a few newsletters. They kind of arrive weekly, but whenever your one comes in, it's always the first one I open it's like, I just I love the little like, like little stories you write. It's not just like four links. It's like, yeah, you give the context. So yeah, genuinely love it.
Pat Kua
Thank you.
Aaron Randall
Very nice. Pat, thank you so much, again for taking time to talk to us today. It's been a lot of fun.
Pat Kua
Yeah, it's a great pleasure to speak to both of you. Thank you very much for having me.
Amy Phillips
Thanks so much.
Aaron Randall
We'll be sharing the links in the show notes plus the all important doodle of Pat over on our website, HumansPlus.tech. I'm Aaron Randall. This is Amy Phillips and you've been listening to the Humans+Tech podcast.
Welcome to the Humans+Tech podcast. I'm Amy Phillips. And this is Aaron Randall.
Aaron Randall 0:07
Hi.
Amy Phillips 0:08
Today we're so excited to be talking to the one and only Patrick Kua. Pat's an incredibly experienced tech leader, most recently as CTO and N26. He's also a regular keynote speaker, mentor, author of three books, and curator of the awesome Level Up newsletter. He's recently launched the Tech Lead Academy with his first course 'Time Management for Tech Leaders', so Pat, welcome to the show.
Pat Kua 0:32
Thank you for having me. It's a great pleasure to speak to both of you.
Amy Phillips 0:36
So to dive straight into possibly maybe our favorite part of the show where
Aaron Randall 0:42
the most important part of the show
Amy Phillips 0:44
definitely the most important part of the show. It's really kind of like customary for us to draw all of our Humans+Tech guests a doodle of them which we put in the show notes. So I'm going to show you your doodle be great to get some feedback you know, just we're going for like likeness of course.
Pat Kua 1:02
Okay.
Aaron Randall 1:05
I'm really sorry in advance.
Pat Kua 1:06
This is exciting. I have no talent for drawing, so
Aaron Randall 1:09
I would, neither do I apparently.
Pat Kua 1:13
Oh, that's really good. I like it, I like it
Aaron Randall 1:20
I really focus on, I think I've got the glasses right.
Pat Kua 1:25
You've got all the characteristics
Amy Phillips 1:33
Yeah.
Aaron Randall 1:34
Amy was saying before for the show that I made you that like a sausage
Amy Phillips 1:37
I think you came off like kind of unfortunate. I think people had longer hair look less like everyone's kind of same basic shape.
Aaron Randall 1:51
Say, yeah, there we go. Great. Well, that's the important stuff done. Sorry again, apologies in advance. And so as Amy mentioned, you recently launched TechLead.Academy.
Pat Kua 2:00
Yeah.
Aaron Randall 2:01
Where you're running a course on time management for tech leaders. Why do you think time management is such a common problem for tech leaders?
Pat Kua 2:08
Yeah, it's one of those issues which, you know, I think not just tech leaders struggle with, but anybody in general. And one of the things that I think was really beneficial, or I learned a lot through consulting was how to manage my own time. It's like one of those things where you kind of have to be independent a lot and try to work out how to get the most done, often without a lot of support. You know, you're obviously working with the team and things like that. But it's one of those things that I think a lot of leaders when they fall into this role for the first time, nobody's really given them skills. So just like a lot of other skills that are needed to be a good leader, nobody's teaching them these are important things you need to focus on. And so what normally happens is when people fall into that, that sort of role, you know, they're sort of overwhelmed. I think, by all the other things that they have to do that they don't really think about how do they manage their own productivity. And you know, there's kind of the awareness problem, you don't know what you don't know, and then realize that it's a problem. And then you're maybe a little bit overwhelmed to actually solve it. And so you know, one of my things that I normally do for first time leaders is walk people through how to manage their own time. Because, you know, the less time you have, the more reactionary you're going to be, the more stress you have, the less time you end up with, and you end up in this vicious cycle. And so I want to help people basically change that cycle to a positive cycle of if you manage your time well, you'll be able to react a lot more thoughtfully, you'll be calmer, and then that will actually help you create more time.
Aaron Randall 3:38
That's awesome. And without giving away too much in the syllabus because obviously that's your job is to teach it a sense of the kinds of things you're going to cover in that course.
Pat Kua 3:47
Yeah, absolutely. Um, you know, I think one of the topics I cover in there is kind of like this difference between sort of maker and manager mode. I kind of prefer the term multiplier because not all technical leaders are managers, but you know there's a difference between working at a keyboard tapping away deep thought, and then switching into lots of context switching lots of interrupt mode of meeting to meeting to meeting conversation to conversation. And those two worlds don't really mix together. And you know, I've been there myself where you're just sort of caught in between. And if you're not explicit in managing that sort of separation of sort of maker versus manager or multiplayer time, then you're just going to get really stressed out. So that's an example around that sort of example. I think one of the other things that I can sort of cover is really about, like, how do you start to prioritize your time? This is one of those things that you know, when you're working as an individual contributor or a team member, normally the team has a process to manage priorities. But suddenly, when you're that sort of leader, it's like, oh, you just have this influx of things. Lots more things to do. You don't really know you say yes to everything. And once again, part of the art of prioritizing is knowing what to say no to or maybe not yet, and how to break things into smaller chunks. So that's another sort of key thing about a key topic that we cover.
Aaron Randall 5:08
I mean, I wish I had this.
Amy Phillips 5:11
Like these are skills I definitely would love to have. Like it is really hard, though. And I think it's, I've definitely seen a lot of I've been in a lot of conversations where people are saying, like, you know, I'm going to, you know, I need to, I don't know, write this piece of documentation, should this be a JIRA ticket? And it's like, you know, yeah, so like you say we've got really good processes for prioritizing and tracking, like normal, normal work. But as soon as you step outside of like, it's not code or it's not something the team cares about It can be really hard to fit that in.
Pat Kua 5:41
Exactly. Yeah. And I think one of the things that I noticed is that you tend to like watch other people when you're in that sort of thing about asking them how do you like cope with this, kind of a building out toolkit, and I think that's the other sort of side of it is that you kind of never done with it. Like, I still always look for other productivity tips and ways that other people do things and I still learn from like everyone about like different, you know, ways of managing email or calendars or other sort of time activities. Yeah. And so you're never ever done.
Amy Phillips 6:10
I love that, like, how can we get a productivity tip? Like I love these things.
Pat Kua 6:15
Yeah. So my favorite is actually using the Send Later in Gmail. So part of that is it's like as a manager or leader, you know, some people feel like you have to instantly respond. And obviously, if you do this to people who they perceive you as a leader, they feel you know, they have to respond to you immediately. And sometimes when you're processing a whole bunch of emails in one block, I don't want to trigger a whole bunch of replies immediately. And I don't want to like sort of stress other people out so I love the whole Send Later kind of feature. My hack before it was actually available in Gmail was actually to put calendar reminders in so I'd save drafts, and then have calendar reminders to actually send them. We couldn't quite connect something like Boomerang, which was an add-on to Gmail just because it has access to all your emails
Amy Phillips 7:02
I think that's so important though, like I do, like I'd love to be able to work as a time which you know, suits me and obviously other people ideally should do the same. But sometimes that is like, Saturday morning at eight o'clock and it looks terrible. I don't want to say that everybody should be writing emails at eight o'clock on Saturday, but for me that actually sometimes it's exactly when I want to write them. So yeah, I love that send later. People must this I'm so productive at eight o'clock on a Monday morning.
Aaron Randall 7:32
12 emails go out and same time. Yeah. I do that thing with it where I give it like send in the morning at 9am I always make it like 9:04. What monster leaves it at a round number? Yeah.
Amy Phillips 7:50
Awesome. So I love the bit, that sort of you mentioned as well there about like people falling into this role becaus e I think one thing Aaron and I were actually talking a little bit earlier about tech leads and it's like It's such a critical role. But also, it's quite a difficult role, because it's probably the first time you're in kind of leadership. And you are probably still writing quite a bit of code, but also sort of playing this multiplier right. I know that you've actually given quite a lot of talks about and actually read a book about as well. which is quite cool. So what what do you think makes a great tech lead?
Pat Kua 8:23
Yeah, it's a good question. You know, I think a great tech lead is a person who knows how to be flexible in their leadership style. And I think part of that is obviously you build up experience over time. But I think you know, the trap that a lot of first time tech leaders fall into is still thinking like a developer, right? They want to be the expert person, they want to deal with all the hard problems they want to be seen as the go to person for all the questions and information. And you know, if you're with a team of very inexperienced people, you know, the most senior developer a tech lead may be suitable to be the person who gives answers. But that's not going to be sustainable as people learn and grow. And you know, as more work comes to a team. And so I think that's a real key for a lot of successful tech leaders is that they know how to adapt that style. I think the other thing, why I sort of focus on this sort of adaptability is, you know, everyone is really different. Everyone has personal preferences, styles, communication, wants and dis-wants. And you know, I think a lot of first time tech leaders fall into that trap where, you know, everyone will they believe that everyone acts and feels the same as they do. And I think that's the interesting thing. And you know, this both being like managers and leaders, of the variety of people, things that your preferences and differences that you've never ever done, you can never really predict. You think you'll you know, you know how somebody's gonna react, but you never, you're always surprised, right? And I think that's the thing of like a good tech lead of being able to be flexible in understanding you know, some people will maybe want to have one to ones and be told news personally. Other people would perhaps like to read things more so than be dragged into a meeting or, you know, have some time to digest information before talking stuff through. Some people will want to work through a problem other people need to talk through a problem. And so you know, there's all of these different styles that you sort of build up over time through experiences. And I think that's what really makes a great tech lead.
Amy Phillips 10:20
I mean, love that. Yeah,
Aaron Randall 10:21
that's awesome. And when you're talking about those traits, it made me think about the times I've helped create new tech leads in my teams over the years. One of the things that I've noticed in them is that they tend, there's a tendency to create process everywhere, as they're stepping up. And I've seen it as a patten I've observed I was wondering, have you seen that and why do you think happens?
Pat Kua 10:45
Yeah, I think so. I think some of the process that I think comes is you know, people going you kind of imprint like you think about like what other people have done who you like, either respect or often it's the I don't want to do this bad thing because I had a bad lead or a bad manager. So I'll do the opposite. And so it's often like the strong reaction to, you know, this kind of first time falling into that role. I think it's also just an actual consequence of learning. Right? So I think, you know, I've studied a little different learning models, if you take the shoe heart re shoe is like you follow the rules, right? And I think the process is an example of following rules. And then over time, you start to work out those rules start to break, they don't apply everywhere. Oh, my goodness, this world is much more complex. Hopefully, people get there really fast instead of, you know, using this process and overhead all the time. And I think that's the hard thing about a lot of leaders is that they don't get a lot of support. And, you know, the experiment is kind of their team, right. And so that's kind of a hard thing to experiment with, because it's having impact on people on work product. It's harder to make mistakes than you know, writing a bit of code on a sort of dev machine and having it break. And so I think that's why a lot of organizations and it's great to hear that, you know, you've been supporting people in that, because I also think it's a responsibility of all leaders to sort of support new leaders, because a lot of organizations do it really poorly.
Aaron Randall 12:10
Mm hmm. I mean, let's talk about that as well that's a great point. Amazing that TechLead.Academy exists, and that you've created something that helps train tech leads, but why do you think that needs to exist? Why why tech is not getting the support they need in house?
Pat Kua 12:24
Yeah, I, it's an interesting question, because I've puzzled a long time around this. And I'll give you a little bit of history about how a lot of the training that I sort of built came about is that, you know, I also suffered as a first time tech lead. I got a call from staffing, you know, asking me to take on this role. Nobody really walked me through what was the differences? Like what did I need to focus on what did good look like? Where did I have skill gaps? Or, you know, where did I need to start focusing, you know, my own personal development. And you know, sometimes it's like one of those things where that sort of sink or swim kind of experience can really turn people off leadership or it can really, you know, help you gain a lot of confidence. And, you know, I saw a lot of people go through this process of being a first time tech lead, I talked to a lot of people around this in the book as well. And I think one interesting thing is a lot of support. Learning development often comes from kind of the people team or HR department. And it's kind of interesting, because they kind of have a high level idea about like what these people do, but it's out of context, and they don't really know the day to day. And so the consequences is they often organize leadership training it has a cross section of people across the organization. It's really great because you build a network and you learn some generals and leadership skills, but the scenarios that you're going to play with and the problems that you're going to face in your context as a tech lead, are very different than if you're going to be leading a team, say in marketing or in a sort of sales team. And so it's very hard to then translate that sort of theoretical or the classroom experience into, like, here's a situation gonna have like, what are your options? How are you going to deal with it? What might go wrong with that. And so I realized it had to come from people who sort of been there before, but also who could teach because I think that's the other sort of aspect of it is that, you know, obviously get other people at tell other tech leads, here's how you have to do it. But once again, that adaptability is a reflection of experience of understanding people will lead differently, they'll have to also take on skills differently, they'll need to learn differently. And so it's just really hard to get that support for a lot of people.
Amy Phillips 14:34
Like, like, I think it is really interesting, like when if you're lucky you get some in-house training, but but yeah, it probably doesn't help you balance like the, you know, one hand you've got, like some production incident that you're suddenly quite responsible for, but also, you know, someone else on your team is upset in a different, completely different reason in a different way. And you kind of got to juggle these two new problems.
Pat Kua 15:00
Yeah, exactly. Yeah. And and one of the examples that we normally cover in the course is around sort of conflict resolution, right, with developers arguing over which library do I use for this thing? I have two solutions, and you just have these developers butting heads. It's like, now you have to come in and like, work out how to get this, you know, through. And that's something that people just don't really, you know, get walked through that example.
Amy Phillips 15:22
Yeah, so true. And I think probably one of the other things, which I think is maybe uniquely difficult at this stage is that I think most tech leads are kind of promoted into the role like like, especially like new tech leads which means they go from being one of the team to suddenly leading this team. And that's quite a difficult transition as well, I think.
Pat Kua 15:41
Yes, yeah, definitely. There's sort of that peer to being a leader, sort of transition, change in relationships. I also forgot to add that I think with tech leads in particular, there's a slight difference as well with them stepping into a leadership role, or the tech lead role because there's also this idea of architecture that often doesn't really get talked about and so this is something that, you know, a lot of developers have never had an experience with, because their tech leads took care of a lot of that, right. So if you're building a new system, you're often in conversations with people in operations infrastructure, if you're in a place where you host it, you have a lot of procurement processes, potentially, a lot of upfront planning, you have to involve support people, you have to think about all these other things. And often the rest of the team aren't even aware about a lot of that responsibility, because the tech lead was taking care of it. And so when they fall into that role, that's another trap is that any of these sort of broader systems sort of architecture perspectives, they don't realize it's their responsibility. And no leadership course is going to teach them that it's actually they have to deal with these
Amy Phillips 16:44
And I guess that ties right back to the whole time management challenge as well, which is, you've suddenly got this whole you're expected to have a, I don't know like a two year roadmap and you're worrying about this bug.
Aaron Randall 16:59
And you've got no time to write code.
Amy Phillips 17:03
One of your talks you've given in the past Pat was called 'What I wish I knew as a first time tech lead' What, What do you wish that you had known? or What do you wish that every tech lead knew when they started out in the role?
Pat Kua 17:17
Ah, that's a while ago that talk. So I was going to have to think back but off the cuff, I think. I think one thing is like how your where your value is or where your reward center is. And I think that's why it's an interesting thing of thinking about this maker versus multiplier mindset. Because I think, you know, makers, you get the satisfaction. And I know, this as a developer, I still love writing code and seeing the output and seeing this kind of fast result. But then when you're leading a team, you're often not writing a lot of code and you're kind of like feeling guilty because it's like, ah, but like, I don't have anything visible like I haven't been putting features through. And you know, that's another thing that fits the time management thing of like you're trying to put as many features through as every other developer, but then you're also trying to take care of all these other responsibilities. And actually just simply that message and helping new people in that role understand, actually, if you're spending that much time writing code, you're probably not taking care of a lot of other things that you are responsible for. So it's okay. And nobody is giving them that reassurance of actually, you know, like, here is where you should be adding your value. And here are the sort of, I guess, signs that you're doing this, you know, the team is healthy, the code quality isn't diminishing, is that, you know, developers productivity is going well, because you're managing things like build times, test times, being able to deploy things really rapidly give people fast feedback, working well with product people, so that, you know, it's balancing technical risk, as well as delivering value not just going off and building your own technical solution, because it's fun. You know, it's all of these interesting sort of reward signs, but nobody tells you what they are. And I think that would have been, you know, just a simple walkthrough of like, what this role is why it's so different. And also just how to prepare yourself for it.
Aaron Randall 19:05
That's a great I remember, like, after a little while of tech leading having to ask myself the question like, what am I not doing when I'm doing this? And when I'm writing code, there's always stuff I should have been doing that no one else in team would have done because not their job as they're not the tech lead. And yeah, just falls to the wayside.
Pat Kua 19:20
Yeah.
Aaron Randall 19:20
Good to remind yourself.
Pat Kua 19:21
And it's really interesting, actually, because I think, you know, there's the what I wish I knew as a first time tech lead, but I think actually, there's something that what I wish every developer knew about leaders and managers, because I think that's the other flip side is that people don't understand the value add. And, you know, I'm a little bit tired of developers kind of automatically dismissing managers as overhead or leaders, because there is a huge value add, and often their association is really with bad management, bad leaders, which is totally understandable if people get thrown in there for the first time without a lot of support, right, it's a bad system that kind of does that. But there are also so many excellent leaders and managers out there and they do add a lot of value and I think that's something that I wish that a lot of developers and makers really understood about the value of good management, the value of good leadership, because it just makes everyone's life a lot easier.
Aaron Randall 20:08
How do we do that? That's such a great point.
Pat Kua 20:12
Well, I don't know how you how it's possible. But I think one thought experiment I've had, but it's a little bit harsh, is like forcing people to have a bad manager and then to have a good manager, because then they start to realize the contrast effect.
Amy Phillips 20:26
Yeah, I think that's true. I mean, I feel like most people, unfortunately do have certainly had at least one bad manager. So yeah, but it's it is quite surprising to me how many people have not had a good manager or not, maybe not a good manager for them. I think that's the other piece, right? Like, yeah, yeah. It's such a shame like the poor people who've never had a good manager. It's like they're missing out so much.
Aaron Randall 20:52
It's really disappointing, very sad.
Amy Phillips 20:54
It really is. Yeah.
Aaron Randall 20:56
So you recently gave a talk called The Secrets of a Strong Engineering Culture'.
Pat Kua 21:00
Yeah.
Aaron Randall 21:01
What do you think are the key elements in creating a healthy culture for a tech team?
Pat Kua 21:05
Yeah, I think there's a lot of things that leaders can do around culture. And I think the first thing I want to sort of say is that culture is not something that you create, for me, it's something and I use the metaphor of like gardening. And in reality, I'm a really bad gardener. I can't keep anything alive I think I'm not consistent enough, maybe I care more about people than about like plants. But um, you know, like, a gardening sort of metaphor, you can't force a plant to grow. Right. And I think that's the other thing is that I think sometimes there's this metaphor of like, leaders, being parents treating people as like children, and I don't really like that metaphor, because you are also dealing with adults, right? So they also have a sense of individuality. You know, and, for me, a lot of the things that you can do as a leader is really thinking about those traits that you couldn't foster that sort of create the best environment for those people to thrive. So that's the sort of fertilizing metaphor. Thinking about like, what nutrients or sunlight, or water, but also being very deliberate about the type of culture that you want to create. And I think that's the exciting thing about being a leader is that you sort of get to focus on that a lot more, right? So if you want to encourage more collaboration, you know, measuring people as a team, rather than as individuals is a really great way of starting to sort of do this and encourage people to want to work together because they're measured by being working together, versus very individual sort of targets or goals. You know, I think the other thing that I see about cultivating good engineering culture is that, you know, there's a big mindset shift. I'm working on a course about systems thinking, and it's all about mental models. One of the mental models we're talking about is like the idea of, you know, developers, like just people that you tell what to do, right? They like factory workers, you like build the plan, and then everyone just, the developers will execute and you know, I don't know of any developer that's like that unless they've been beaten by the system, where all their creativity is already been sort of beaten out of them for being punished. But most engineers want to learn, they want to solve problems, and they want to add value, right? So the reason why I think a lot of developers get into programming is because they get to solve problems. They learn new tools, they learn new approaches. And I think that's a huge mindset shift of thinking about how do you foster that environment where you basically are sort of giving them hairy, bigger problems, but also making sure that they can solve them without sort of failing spectacularly. But you don't need to be the person that is like the person solving the problem for them, and then telling them how to actually solve it. It's really creating that right environment where people feel empowered. And you know, I think one of the good books around this is the Dan Pink's Drive book, which talks about this sort of autonomy mastery purpose, where, you know, the autonomy thing is that developers get to choose, I guess the way that they break down a problem they may not necessary get to choose the problems that they have, because every organization needs to have like priorities, right? So there needs to be some sort of how it links to the greater good. But I think that if that's done well, you can then link that to the greater purpose of the mission of the company of whatever the product is and help people see that path to how their work contributes for greater sort of good. And I think when I think about the engineering cultures, where it's like, really good and versus where it's really bad, it's often where, you know, developers are really close to the customer, because they can see the impact of the work that they're having an immediate value. The further I think developers away from an end user and a customer, the more that they're just going to start to play around with tools because they don't really understand how their work solves real world problems. Yeah, so there's some of the things that I would be thinking about with like engineering culture.
Aaron Randall 24:52
That's awesome. Um, I guess, leading on from that, you know, so you mentioned before we started recording the podcast, you you've worked at N26 and grew the team there from five to 110 people did you say?
Pat Kua 25:05
it was from 50 to 370 People
Aaron Randall 25:07
Oh, wow. Even more so. So significant growth. And by the way, I love the gardening metaphor for culture. I think that's amazing. My question is, as you take a team though that kind of growth, and a culture presumably does change, like how do you keep a healthy engineering culture through that kind of rapid growth and scaling?
Pat Kua 25:26
Yeah, so one of the things that we were really deliberate with, with our growth was really thinking about at different scales and stages 'what does autonomy look like?' And I think this is one of the hard things about people who've been at startups, and they see that rapid growth is that, you know, there's a sense of impact feels less like if you're five people, it feels like can change everything. But you know, when I left N26, I think the whole company was about 1700 people. Right? And if you were one of those early stage people, obviously it's like, well, like what are the rest of the people doing? What am I doing and and how is that actually having a big impact? And I think part of the art, I guess, of scaling an organization through that process is once again trying to help people understand where their boundaries of autonomy, or, where their purpose, right. So having a developer that's trying to fix everyone's sort of product issues. firefighting is okay in the very, very early stage of a startup. Because it's not very probably many customers, there's not too much sort of code or too many products. But as your product sort of grows, as you have more complexity, you're just going to be on a path to burnout. And so that's one thing that I really wanted to balance out is helping people understand it's not because like, we don't want you to have access to all of these different products, but you know, you're not going to be able to do that sustainably. Right. So you know, we have lots of engineering teams building lots to code evolving lots of products, one person can't keep all of the changes in their head, and that level of complexity without you know, breaking down or burning themselves out at some point. And so what we used is what I call the Target Operating model which talks about what is a stage of, for a certain stage of the organization or number sort of size, what is a good balance of that structure that allows us to maintain the right level of autonomy and alignment. So, as a counter example, it doesn't make sense to have 50 teams when you have 50 people, right? So that's obviously too much overkill. And it probably doesn't make sense to probably have 20 teams either, because then there's small teams, lots of coordination. And so as a sort of team or group grows, it's trying to like create those identities that allow teams to work. So rather than having lots of people, it's really thinking about units as teams, and how do they work well, effectively around a particular goal or unit where they can have value, autonomy as much as possible. And also they can have a lot of speed without needing to coordinate with a lot of other organizations. And this is kind of, I guess, The inverse Conway kind of law of thinking about, okay, looking at your product, what are the areas that can be mostly independent, and grow a team and then maybe a small department or organization there. So to give you an idea, when I came in, we were about 50 people in tech, which included helpdesk and security. And then what we had with Target Operating Model Version One was planning for about 120 people. And so here is where we decided to have sort of very clear team boundaries. At least nominally, a lot of them were obviously very empty and theoretical until we actually started hiring people. But at least we understood about the sort of areas where, you know, we didn't want to add more people to a certain product because it wasn't complex enough, you just have people stepping on each other's toes. Other product areas, were not enough engineers, a lot of people on the path to burnout there as well. So they needed a lot more capacity, but also there was a lot more sort of essential complexity. So you can add in more teams that took care of certain parts of complexity there. But then, you know, as we hit about 120 150, people, obviously just having a lot of teams around, if you will, then even just taking a planning session with one person from each of those groups. You know, that's a meeting with 15 people, which is quite a lot as well. So and so this is where we evolved our model to go to Target Operating Model 1.1 where we introduced the idea of groups, so groups being a sort of collection of different teams in a product area. And then they will focus on a particular theme. So as an example, we had a group around payment infrastructure. So if you've ever dealt with payment infrastructure, it's very complex, very low level lots of standards. And also being a bank in Europe we had and moving to the UK into the US with lots of payment schemes galore. And so there's a lot of sort of, well, essential complexity, but it's also a little bit invisible because you don't really see it from a user perspective. So we can have a group around that. We could then have lots of sub teams within that group that could be focused on certain areas of complexity and grow and manage that. And then, as I left, we started a office in Barcelona, which ended up being about 110 people. We wanted that to be mostly independent as well. And, you know, the organization was growing. And so we also introduced the idea of segments. And this is the idea of how groups connected to a segment in that they will try to shift the same sort of major business goal. So we had a group around growth, for example, around sort of customer onboarding, all the things to do with sort of, I guess, SEO, all the onboarding channels, sort of lifecycle, which is a little bit more expensive, I guess, in banking, because of identity verification, and all these other processes. So all the groups that had anything to do with customer growth, were then sort of grouped together in a segment. And so that segment could sort of manage all its parties, and it's really just about trying to minimize the dependencies to reduce coordination. So teams and Groups can be as effective as possible.
Amy Phillips 31:03
So in terms of the sort of breaking down dependencies, I guess I'm kind of curious on like, that sounds like a very nice, neat growth sort of path, I imagine it gets messy in moments. But like, how did you go about like, was there, was there a time where you sort of realized like, Oh, actually, these two teams, they're in completely different places, but actually had some unexpected dependency? Like, how do you actually like, break those things apart?
Pat Kua 31:30
Yeah, it's a really great question. And I think I know a lot of people that go oh, another reorg or whatever. And I think part of that is a realization about Conway's Law. If you're adapting Conway's Law. One of the interesting things that I didn't really maybe appreciate as much as a consultant of helping companies go through this approach is, you know, as a consultant, you come in, you see a snapshot, you help people model like the domain, come up with dependencies, and you know, people then implement it, but in a startup really rapidly growing the interesting thing is the product changes really rapidly as well. And so I think that's the other thing is that, you know, as you add in complexity, the business is taking a bet, you don't really know how to deal with that complexity. So it's like, Okay, give it to an existing team. But at some point, you know, the complexity maybe has a life of its own, and it's a product area significant enough. And so if we're refactoring our architectures to maybe pull out a service, it also, then logically concludes, we should probably pull out a team to focus around that business capability. And so I think that's the thing, just like you get code wrong, and you have to refactor, sometimes rearchitect pieces, you kind of have to do the same to your organization as it's growing and learning. So I think that's the thing that I saw really rapidly in a very hyper growth sort of environment, just because product changes really, really rapidly, more complexity keeps adding in. And so you have to kind of respond to that and you make mistakes, right? So what you thought was going to be maybe simple actually. Now, there's a pendency because maybe a product person wanted a connection where there wasn't there before. And so it's like you still ship the product, because it's important in any business to ship. But then you kind of go, Oh, we have some tech debt or organizational debt. So we now need to like maybe deal with it more sustainably. And so that then leads to a refactoring or revision over the organization.
Amy Phillips 33:23
I love the way you described that and kind of like the technical terms, because if they I think people do panic, then they're like, oh, reorg everything's changing, but actually, they're really comfortable. Everyone's really comfortable with the idea of you refactor code, you don't always get it right. There will be bugs. Not the end of the world. So yeah, that's really nice.
Pat Kua 33:39
Yeah, I think part of the art was I was speaking to a CTO who struggled with this is that I think they went through too many iterations, too much variation. And I think that's the interesting thing about the change is that there's a difficult art. I don't know science, whatever, around trying to find the right time and place to make changes. So too early, you're probably going to end up over engineering an organization, too late and there's going to be a lot of sort of pain. And too frequently people are going to get that sort of change fatigue. And I think that's a interesting thing that people should be really deliberate about when they're sort of thinking about the organization design structure about, is there enough reason to do this. And one of the analogies I kind of think about is kind of pain driven development is it's kind of like, you know, sometimes you have parts of the codebase. It's a little bit like gnarly, but you can live with it, right? And then it's like something that you kind of keep coming back to every day that's really slowing you down. You really have to do something about that. And I think that's the same sort of idea and this is harder in the organization sense because you get so many different signals from people about you know, I don't like this, you know, that's not working or whatever. And, you know, part of the art is in trying to find, I guess, a common theme that is really having a big effect impact. So I look for sort of strength of signal, consistency of signal, and then applying my sort of systems thinking head on, is it a side product? Or is it actually caused by something, in our, sort of structure. So I don't want to just simply put a patch on it, but actually, I want to deal with that, like more holistically. And so I wouldn't like react immediately when people say, Oh, that's wrong. So we need to change something. But I'd really be looking for signs that gave me a sense of like, if we fix this thing, this will give us a good runway for another six to 12 months of we've made significant improvements for everyone.
Aaron Randall 35:37
Nice. I'm frantically writing notes, but so much I feel like I'm learning so much right now.
Amy Phillips 35:42
This is a selfish podcast we just...
Aaron Randall 35:48
It's just for ourselves yeah. Back to the 'Secrets of a Strong Engineering Culture' presentation, you gave, talk you gave, one of the things you mentioned on that is a five step recipe. I was wondering if you could tell us about that and talk us through it.
Pat Kua 35:59
Yeah. I can't, I have a really bad memory. So
Aaron Randall 36:03
I've got, I can prompt you.
Pat Kua 36:07
I need my crib notes. Yeah, maybe you can prompt me. Maybe I can talk through reasoning.
Aaron Randall 36:15
Yeah, of course. Yeah. So step one is gather input. Step two is publish tech culture. Three is prioritize key improvements, four is decide on actions. And five is repeat.
Pat Kua 36:24
Yeah, that's right. Thank you.
Aaron Randall 36:28
That's a great talk, everyone should watch it.
Pat Kua 36:30
Yeah, thank you. So I think, um, yeah, so it kind of follows a retrospective, but at an organizational level. So that's the way that I see it. And for me, software organizations are complex entities. And this is the whole thing about you can't just take Spotify model and and implant it into your organization. So you kind of have to work and do a bit of homework about actually understanding about what are your actual problems. So that's the idea about really gathering input. And you know, as a as an example with a target operating model, one of the first things I did was actually run team retrospectives with everyone. And I really tried to focus people on, I don't really want to hear about, like the problems within your team, I want to hear what's constraining your team. Like, I want to hear about the things that you feel your team can't address. You know, I expect you to be able to improve your own process your working team culture, but actually I want to understand a little bit more about how you work with the environment, but also the good things because I don't want to lose those things. And so that's the gathering input process. And then, Can you remind me the second step, sorry,
Aaron Randall 37:35
Publish your tech culture
Pat Kua 37:38
Sorry, memory like a frog. Yeah, no. So yeah, so publishing, I think, is a good way of really trying to codify it. And I think there's a power to simplification and I think by publishing it, you have to simplify. And I think it helps people understand what is what your culture values, and I think particularly If you're trying to nudge your culture in a certain way, that's also an important thing. You know, I'm always conscious that, you know, stated culture and culture in action is always a little bit different. But you also want to be clear about what you're going to reward. And that's really that stated culture. Right. So and I think it's to be fair with people, you want to be clear about what that is. I don't think it should be done in a vacuum. It's something that you should really be cultivating. And so that's one of the things that I was like listening into with teams as I was doing retrospectives was like, asking, you know, trying to listen for what is it that makes this organization different from other organizations that works here that if we lost that, it would feel like there's a big loss in the identity. So codifying and publishing I think helps people sort of rally around it, and then also helps give people that common vocabulary.
Aaron Randall 38:49
Hmm, that's awesome. I feel like when you talk about that, it sounds like almost going through the process of writing it down for the outside world. It's like a version of rubber ducking where it makes you sort of really think about how to best articulate it. If you really hold it true or not? And yeah, that's really, really cool. Yeah.
Pat Kua 39:03
And it's a really great way for you to keep yourself accountable as well of like going back to Am I doing something? As an example, you know, I knew that N26 was quite a pragmatic sort of culture, right. And so I knew maybe I needed to tone down my own personal idealistic sense, having come from a consulting background of actually not trying to do something that's too much of a stretch goal, but actually has to be really grounded in a lot of value, right? So to has to have a clear, concrete outcome has to be actionable. It's not just about like, complete blue sky thinking. Step three,
Aaron Randall 39:40
Prioritize key improvement areas.
Pat Kua 39:42
Yeah. You can't do everything. So this is like, once again, the whole time management thing, right. So I think the thing that every leader looks for is really the high impact actions. And I think that's the thing and, you know, I think a lot of startups and you know, like N26 included you always say that you're going to do a lot of things. And then things get out of hand or things distract you and you don't quite complete all those other things. But I think that's why it's quite important for leaders to go up with a list of here's all the things that we're going to do. But also, here's the things we're not going to do to manage expectations.
Aaron Randall
And that's actually as a team, what you're gonna, what you're gonna do what you're not going to do, Yeah, awesome. Awesome. And number four is decide on actions.
Pat Kua
Yeah. And so that's kind of really about, like actually taking care of them. So I think one of the things in communicating change is you want to be clear about I guess what's gonna happen next. So I think people are saying, you know, what does this mean people want to have an answer about okay, what does it, what does it mean for me in my day job, like, do I have to change something? Do I have to act differently, like I think that's that's a group responsibility. I don't think it's a great sort of idea to once again say, here's the ideal without giving people concrete things they can do to actually make steps towards that.
Aaron Randall
Great. And five is repeat. It's great.
Amy Phillips
I think it's really interesting. Like I love the I love the sort of like the actual writing it down and sharing it. Like, I think that's a step. Like I think it's really easy to hear things and be I go and I go and make that I can make this improvement, but you forget to kind of loop it back and actually really help people see I heard you, and we're doing something so you lose half of the benefit.
Pat Kua
Yeah, and I think that's a really great opportunity for a lot of leaders is that I think that's the, I guess one of the key things is working out how to shape that culture. You know, I think that's one of the reasons why a lot of people jump into a startup very early on because you can kind of shape and mold that culture, but trying to shape a very large organization and change that culture becomes a lot harder the bigger it gets, you know, I'm very impressed with a lot of the turnaround, I think from Microsoft that Satya has had in sort of Microsoft, which from my point of view was not always a developer friendly ecosystem, unless you were sort of Microsoft stack. But you know, now it's, you know, with GitHub and lots of other sort of open source stuff. It's been really interesting at that sort of transformation. But it's a hard journey. I can only imagine.
Amy Phillips
Yeah, I agree. I mean, like the I think the the thing that's really impressive is the speed at which they've done it, because I think that's the other thing that sort of, I mean, I'm a very, very impatient person. So like, for me, whenever you kind of go into these cultural things, like you're lucky if it's like six months, but often it's, you know, way longer to make significant changes. Yeah, it's like, I guess I suppose that's probably another piece that's kind of interesting. It's like what are what is the sort of realistic timeframe for you know, real team change or like that even yeah, just even within like a normal team like how, how long would like it take to properly bed in a cultural change?
Pat Kua
It's good question and I'm gonna give you the consultant answer. I'll ground it in a couple of reasons. Right. So I think it's not just about change, I think it's about what sort of change. And one of the reasons, you know, step one around gathering input and trying to understand the pain points is, obviously change will be a lot easier if people can understand how it helps their life get better. If it's change for the sake of change, then people are obviously going to resist and if they don't understand the value that they're personally going to have, they're not necessarily going to buy into it or they're not necessarily going to take action. And so I think that's one of the reasons why change by itself isn't so useful. It's really trying to understand what change is, you know, helping, right. So, you know, when I was consulting, I used to work with development teams who did a lot of manual testing. And it's like, like, I'm just like bashing my head on the keyboard redoing this test again. And again, it's like, wouldn't it be interesting if we could like automate this and then we wouldn't have to be doing all that typing, right? And it's like, over time, people started to understand, okay, like, like, I am wasting a lot of time running through the same scenario again, and again, I've written the scripts that only I can run that I can't share with my other team members. Maybe if we merge them in some way we could share, then we could actually save some time. And you know, that helping people understand how the change addresses their problem, I think is a key element to helping change accelerate. You know, I think the further out that change doesn't mean to somebody or a team, then it's not really gonna have so much of an impact. So that's why I don't think you can really instigate or you can really say how long change is going to take. My favorite mode of doing this with teams is really using sort of iterations or sprints, whatever your terminology might be as experiment cycles, right? So that's the beauty I love about retrospectives is that actually we can start doing a change next week. And we don't have to commit to it for life. If we don't like it, we can decide to roll it back, right? So we can try it out. See if we have a better life. We like it. Let's do more of it. And, you know, hopefully those habits start to or the positive habits that actually have impact start to escalate. Yes.
Aaron Randall
Am I hate to be the bearer of bad news, but unfortunately, we are running out of time. But before before we let you go, we have four quickfire questions that we ask all Humans+Tech podcast guests so I'm gonna dive into these. First one is what is your top book recommendation?
Pat Kua
I'm a big systems thinker. So I love Thinking In Systems by Donella Meadows. It's really accessible, easy to read. Yeah, love it.
Aaron Randall
Awesome. Amy, you're nodding your head like you know it
Amy Phillips
I love it, yeah great book. I think it's very interesting stuff.
Aaron Randall
Nice, question two is what tip do you wish you'd received when you first moved into tech leadership?
Pat Kua
Find a mentor. So I think that's somebody that's something nobody ever told me about. a, uh, yes, I would have loved to have that advice.
Aaron Randall
That's amazing advice. And that's, by the way, great advice for anyone in any kind of tech leadership, right?
Amy Phillips
In Tech, I thought you were going to to say. Nobody mentions it, for the first like, 10 15 years of your career, and it turns out, this is the secret.
Aaron Randall
But then you you get like four of them. Okay, question three is who inspires you in tech?
Pat Kua
Oh, who inspires me in tech? I have to give a lot of, so I spent a lot of my career at Thoughtworks and I have a lot of respect for Martan Fowler. Not just because he is like an amazing person who can summarize content in a really simple way. That's definitely something that inspires me, but the thing I want to point out is how he uses his platform to support other people. You may have noticed, probably over the last five years, maybe even earlier, he's getting a lot more people to publish articles on his platform, because he knows he has something that he can use, that helps people amplify their message. And I think that's something that I really appreciated from the sort of social and economic justice pillar from Thoughtworks is not just about tech or making money, but actually trying to use whatever power or influence you have for good. And I think he was a really great example of that of, you know, if, you know, he can't make a talk he would introduce and pass it on to somebody who might not have those talking opportunities. He was very generous with his own sort of personal platform. And it's a really great example of sort of paying it forward. And I think for me, that really is something that I really get inspired by and one of the reasons why I enjoy teaching and coaching and helping other people grow.
Aaron Randall
Hmm, that's great. Very nice. Question four, finally is what is the most ridiculous thing about you?
Pat Kua
Oh, I'm not very funny. I love laughing
Aaron Randall
We'll take it, very nice. Finally, where can people find out more about you?
Pat Kua
Yeah, you can find out more about me at PatKua.com or if you want to join the Level Up newsletter, it's at levelup.patkua.com
Aaron Randall
which you absolutely should join. Amy made me join because it's great.
Amy Phillips
It's such as great newsletter like, you know, I'm subscribed to quite a few newsletters. They kind of arrive weekly, but whenever your one comes in, it's always the first one I open it's like, I just I love the little like, like little stories you write. It's not just like four links. It's like, yeah, you give the context. So yeah, genuinely love it.
Pat Kua
Thank you.
Aaron Randall
Very nice. Pat, thank you so much, again for taking time to talk to us today. It's been a lot of fun.
Pat Kua
Yeah, it's a great pleasure to speak to both of you. Thank you very much for having me.
Amy Phillips
Thanks so much.
Aaron Randall
We'll be sharing the links in the show notes plus the all important doodle of Pat over on our website, HumansPlus.tech. I'm Aaron Randall. This is Amy Phillips and you've been listening to the Humans+Tech podcast.
