Talking with tech leads with Pat Kua

Podcast transcript

Neal Ford:

Hello, and welcome to the Thoughtworks Technology Podcast. I'm one of your regular hosts, director software architect and meme wrangler at Thoughtworks, Neal Ford. And I'm joined today by another of our regular hosts, Rebecca

Rebecca Parsons:

And I'm Rebecca Parsons. I'm the chief technology officer of Thoughtworks. And today, we are here to talk to Pat Kua about his book, Talking With Tech Leads. So welcome Pat.

Pat Kua:

Hi, thank you very much for having me. I'm very excited to be here.

Neal Ford:

Some of you may recognize the combination of names that you see together in this call because the three of us, in fact, coauthored The Building Evolutionary Architectures book. But right now Thoughtworks is on a bit of a campaign to highlight some books that came out a few years ago that are sort of evergreen that still have really terrific advice in them. And Pat's book, Talking With Tech Leads, came up as part of that campaign and Rebecca and I both volunteered to chat with him about that book because that actually came out before The Evolutionary Architectures book. And that's the first thing many people know about you. So if you would tell us a little bit about your background and some biographical stuff before we start talking about tech leads and where you are now, et cetera.

Pat Kua:

Absolutely. Yeah, so I started as a technologist engineer almost 20 years ago. I feel really old now, but been working for awhile. And I also used to work for Toolworks. I've done consulting and played many roles across my journey. So did everything from being a developer, to being an agile coach, to being a tech lead, to consulting and helping heads of technology or CTOs and directors replatform or redesign their organizations. I left Thoughtworks and also was a CCO for a scale-up FinTech company based in Berlin, which is where I'm based now called, N26, where I grew the technology team from about 55 people to about 370 over two and a half years. So massive, phenomenal growth. And my current sort of role is really about helping other CTOs and VP engineerings, particularly of scale-ups, navigate that journey themselves through sort of coaching and mentoring.

Pat Kua:

And as you said, Neal, the book was written quite a while ago. And I think for me, it was interesting because it was at that sort of time where I was playing sort of my first couple of tech lead roles. And I think, like a lot of things in our industry, we tend to create the things that don't exist for us. And one of the things that I wanted to have was kind of like a, "How do you become an effective tech lead?" And there wasn't really anything out there for that. And so the natural instinct was, "Well, you have to build it yourself." So you have to go talk to other people and I thought it would be useful to capture that as a set of stories of people who were going through that role.

Pat Kua:

And there's two parts to talking with tech leads, one, which was trying to capture people who were in their literally your first tech lead role. Obviously those people have now sort of moved on to perhaps different roles and they're a lot more seasoned. And then the second part was really capturing people who've been playing that role for a while. And so you sort of start to see how people have got comfortable with that role, how they approach it very differently, and share the stories of all these different people in different situations.

Neal Ford:

So roles in the software development world are a mess because nobody knows what anything means. And a lot of companies don't make a real distinction between tech lead and architect, but some do. So what's a good distinction between a role like architect and tech lead? Because there is a fine distinction between those things and it's important. So let's start there.

Pat Kua:

I mean, we're terrible as an industry with naming. I think my perception is with a tech lead, what I see in industry is most of those people tend to be sort of connected to a single team more or less full-time. So an architect, it depends on companies as well. You also have sort of architects who are sort of a synonym for a tech lead, but often architects might be looking at a broader spectrum. So they might be looking at different systems and different product teams as a result and not necessarily sort of connected to a team more or less full time, whereas a tech lead will typically be more connected to a product team full time. So that's how at least I see the difference.

Rebecca Parsons:

And what about kind of their focus? When I think about the distinction, the tech lead is really responsible for the team. It is kind of an inward facing almost role and having to do with that team and with the product that that team is developing, whereas even if an architect is assigned full time to a team, and in fact, I was in that situation in one of our earlier gigs in the UK. The tech leads were taking care of the developers on the team and I was the outward face. I was the one who was looking at the interfaces with operations, all of the other things. Do you think that kind of difference in role influences what it takes to be a good tech lead?

Pat Kua:

Yeah, absolutely. So I think that's the interesting thing is that the context matters and therefore the skills of that tech lead will need to be adaptive to that sort of context. And I've seen that as well where I've seen people, they sort of call themselves a sort of co-tech lead where one of them might be more externally facing because that organization has many different technical stakeholders, or maybe there are many other teams who they are dependent on. And so there's a lot of time or skills required for that external tech lead to be a very good bridge builder to connect to different teams, just even to be aware of which teams to talk to in a large enterprise or organization. That just takes a lot of time. And at the same time, they can't focus their time within that team. And so that sort of co-pairing where you have a more internally looking tech lead trying to make sure that the team is aligned in how they're working as a team.

Pat Kua:

And I think that set of skills is also very different. So I often describe a good tech lead as a sort of shepherd for internal to that team and their goal is really to make sure that the team is working like a team and not just a group of individuals who happen to share the same code base. And so that requires a different set of skills than the people who are interfacing externally. And of course, the complexity of your organization and your team and your organization sort of products that you're building will sort of derive some of the skills and necessities. And so I think people who play a tech lead in one company or one team, they may actually need to draw upon different skills when they moved to a different team or to a different company, just because the situation is very different.

Pat Kua:

So let's take a startup for example, where you don't really have that many teams is that tech lead might need to actually be facing with customers very closely and with product people a lot more closely, as well as get involved very much in sort of hiring the team that they to be working with as they grow in scale as well. So the contexts are very, very different, but very interesting, so it requires different skills.

Neal Ford:

But one commonality between both of those and a number of the piece of advice in the first part of your book deal with what we ironically call the soft skills of technologists and software architects, which is ironic because it's some of the most difficult things that many technologists encounter. And when you become a tech lead is often the first time that you have to exhibit leadership and consensus building and those sorts of skills.

Pat Kua:

Yeah, absolutely. I actually like to use the terms these days as foundation skills, because I think good engineers also benefit from those foundational skills, but a lot of people can somehow still get away with being a good engineer, but not have to use so much of those foundation skills. But as a technical leader, you need to have solid foundation skills to be successful. You'll be drawing upon them every day, and unfortunately not everyone has had a chance to build and grow those sort of skills.

Pat Kua:

So you're right. A lot of people find themselves in that role and then suddenly they go, "Oh, wow. Yeah, I don't really have great mediation skills. How do I navigate this conflict between two engineers or between myself and another tech lead so that we can agree on that common interface or a general approach? I now need to start talking to other people from very different departments and teams. So I'm not just talking technical with all the teams that I'm working with. I now have to communicate really effectively and being able to communicate in different business domains, either it's marketing or the business people will finance," if you ever have to talk about sort of CapEx or OPEX expenses, even just the logistics or the legal side, if you have to get into the licensing. That requires very flexible ways for people to be able to communicate.

Pat Kua:

And unfortunately, a lot of people who find themselves in that role don't have that sort of experience. So normally it's been sort of taken care of by an existing tech lead. So a lot of people don't get that opportunity to start practicing those skills before they find themselves sort of in that role and responsible for all of those things all of a sudden. So it's a big shock for a lot of those first time tech leads.

Neal Ford:

So we'll do a public service and broaden the audience for your book and tell developers who aspire to be tech leads this is a good way to start doing that because at the end of the day, a role like tech lead or architect or one of the more multifaceted or nuanced roles in technology really consists of a stack of different talents. It's not that they're absolutely the best at everything that they do. And good communication skills and good mediation skills is a valuable piece of your talent stack to build up the things that you need to create a complete portrait of a tech lead or architect, or eventually chief level executive.

Pat Kua:

Absolutely. I mean, I think it's interesting because the role of a senior engineer, the reason I think why it's useful to call them foundation skills is they can use those skills, even if they're not in a more formal tech lead role and be more effective. So even though they're not sort of accountable or responsible for making sure that there is a conflict resolved, they always have opportunities in their team to help sort of navigate that. And their existing tech lead will be much, much happier for that because now they don't have to step in. If you can influence other people in your team or outside of your team as an engineer, it'll be a lot easier to get your own work done as well. So there's so much more benefit of just investing in those foundation skills, regardless of what role you're playing. And you'll be a lot more effective for sure.

Rebecca Parsons:

One question I have then, we've clearly debunked already the myth that the tech lead is the best technical person on the team. How technical does a tech lead actually have to be?

Pat Kua:

Yeah, it's a great question. And the way that I kind of think about it is, well, why can't we just have somebody who's a great leader or a manager from a different domain, I don't know, like marketing, come in and lead the team? And I think part of the consequences of having some level of technical awarenesses understanding enough about the conversations that are going on to make good judgment calls. So sometimes those judgment calls will mean they, as the tech lead might need to step in and actually make that call because it's so important and they want to shape that direction and they have a bigger, broader context that the team may not have.

Pat Kua:

And often the right context is to allow your team to perhaps own that decision. And sometimes they'll make mistakes in that process, but hopefully they'll learn. But to be an effective tech leader, you have to also limit the amount of damage or risk that people have when they're learning. So you have to make that judgment call. So you do need a good sense of what the domain or what are the problems that your team are going to be facing.

Pat Kua:

I think that's a second element, which is also how well can team members empathize with you as a leader, right? So I've worked with many leaders or managers who were not technical, and I had a lot of respect for them, but I knew I couldn't go to them if I needed help with particular types of problems. So I would always have to seek perhaps a more senior person because I would then need to explain so much context about what my problem was. That was just going to be frustrating if I spend that much time trying to explain that to a person who doesn't have that background. And I think that's the hard thing with technical leaders is that we have such a broad set of technologies and skills, but some of the sort of focus of the principles apply regardless.

Pat Kua:

I think I get a lot of people who say, "Ah, but I had a background in, I don't know, Java programming, and I'm now responsible for a team that's writing Go." Well okay, you may not be the expert person for APIs as to how to use this library or whatever. I mean, everyone has to Google Stack Overflow things these days, but you have a lot of experience probably building systems, using right architectural patterns, understanding how to design interfaces really well, that those concepts are applicable regardless of the programming language you happen to be using. If you're using an asynchronous or synchronous or building a certain type of system, you should be able to make good architectural trade-offs that are sort of agnostic of that sort of technology.

Pat Kua:

Now I think that is a little bit limited because even those principles bounded. So for instance, I would probably be a little bit uncomfortable leading a machine learning team because I've never really built a lot of machine learning sort of systems. So understanding the trade offs of one algorithm versus another algorithm, that would be very difficult because I wouldn't be able to make that judgment call so effectively. And so, yeah, I think that's the essence of it is that can technical leaders help their team make good decisions. They'll have to be technical enough to be able to help them in those domains.

Neal Ford:

Well, and you point to another important skill, which is delegation. So I have seen a project where the tech lead wasn't the strongest in that technology stack because they were new to that technology stack, but they were an experienced architect, but they had a lieutenant who was extremely strong in that stack and they would defer those kinds of questions to them. And I think delegation is also important because one of the sort of anti-patterns I think that happens with tech leads is, "Oh, now I'm responsible for everything. And I've got to micromanage every detail of every thing." And you get swamped and overwhelmed and burned out, and that's not a good place to be.

Pat Kua:

Yeah. It's a really common trap for first time sort of technical leaders as well. I mean, experienced people fall into that trap as well. But I think for the first time, as an engineer, you're be often sort of expected to own the feature or the story that you're working with for end to end. And when you step into that leadership role, you suddenly feel that responsibility for everyone's. And so there's that sort of need for sort of control. And one of the things I often talk about is this difference between sort of make a mindset and multiply a mindset. And when people step into that first time technical leader role, they're often playing that sort of make a mindset where they're really trying to see their reward is what they do is their value add is what they're personally creating or producing or making.

Pat Kua:

And so that sort of keeps them from delegating because when I give something away to somebody else, it's somebody else's creation. It's not what I'm making. Therefore I question what's the value that I'm adding to my sort of team. And so part of that interesting journey of helping people be successful in that sort of first time lead role transition is shifting that mindset to your role is not really about you personally creating the best solution, but really the best solution that your team is creating. And as you said, one of the great things about really great leaders is that they tap into the skills and experiences of the entire team to multiply the effectiveness of everyone.

Pat Kua:

And so that's the real challenge for a lot of strong people going in that. So knowing who's better at what areas and being able to trust them to be able to do that with better quality, to be able to resolve conflict so that people aren't working against each other, or you have to rework things because two individuals couldn't agree on a way, so in the long-term you have to refactor or redesign an area because you couldn't agree early on. There are effective multiplier behaviors, but it takes a long time for people to sometimes re adjust to that.

Rebecca Parsons:

Well, and in particular, as technologists, we are used to a very objective success criteria. The build is green. The tests pass. All of these very concrete, "I know that I got something done because I got this story finished and the build is green." Moving into that role, it becomes much more subjective. How effective have I been at enabling my team? Well, you can say, "Well, they made all of the stories go to done and the build is green," but it is that level of indirection and it even includes that time gap. You may do something as a tech lead. What kind of advice do you have for people to make that kind of mental mind shift? Did you pick up any secrets that you think might help people as they go through that transition?

Pat Kua:

Yeah. One thing I say to a lot of tech leads is blurry as a new binary, right? So as you said, it's like, you're used to use or no, blue, green or red, and you kind of have to deal with a certain level of uncertainty. That's just the natural part of it. And then the other thing that you said was really the time delay. And so a couple of things I've found sometimes help with this, at least personally, it helps that I find other people resonate with that advice. And I think one of them is looking back at what your team has achieved over a bit of a longer period.

Pat Kua:

And so, if you think back over two weeks or a week, and you list all the things that your team have been doing and producing. You as a tech lead should be taking some credit for that as well, because you've created an environment where everyone can sort of achieve a lot more. And I think one thing that can help is, if you compare the team's output perhaps, compared to what you could have possibly produced, it should be a lot greater. If not, then there's a bit of worry but hopefully, the team is being a lot more productive than what you possibly could have and that should help you sort of remind yourself that as a leader, you're not measured by your output, but what your whole team can do.

Pat Kua:

I think the other thing is then, thinking about the actions that you've had that have helped to multiply the effectiveness of everyone there. And one sort of game perhaps, you can play with yourself is, thinking about all the things that could've gone wrong, but they didn't go wrong because you managed to intervene. So thinking about the parallel universes, where you didn't step in, because you didn't want to interrupt a fight or a conversation or you didn't delegate and you ended up burning yourself out. There's all these like little choices that you make along the way, it's hard to sometimes not realize those problems that you could have avoided. But if you sort of think about, what could have happened and the bad things that could have happened, and you sort of steer that in the other direction, that's also credit that you should take because you've helped the team progress without issues.

Pat Kau:

And so I think those two tips, definitely sort of help. I think one other thing is, looking at the team progression over a longer period of time. So it's kind of thinking about, "Okay, maybe you started off with a bunch of graduates or fresh people to the industry who came from boot camps." And that was a very stressful time when you were leading that team because you had to get involved in a lot of sort of features. There was a lot of context switching, but fast forward say three or six months later, it's like suddenly you have a lot of people who are a lot more independent. People who've grown, their skills have grown and they can take features sort of end-to-end with a lot less assistance.

Pat Kua:

And so when you take snapshots and you sort of compare the progress of your team over time, about how well that they've grown their skills and their experience and their sort of responsibility or ownership. That's also a really great way to sort of see the environment that you've created. That have allowed everyone to really flourish and multiply, it still takes time. So you have to be patient, but it's definitely worth it.

Neal Ford:

So you're sort of talking about a multiverse risk list. The risk list of the multiverse, if we'd made this decision.

Pat:

That's right. [crosstalk 00:02:55].

Neal Ford:

Right. So let's talk about one other thing that I think is pervasive in the technology world, but not talked about enough, which is imposter syndrome. Which I think affects every tech lead and every architect, particularly the early ones in the beginning parts of that role.

Pat Kua:

Yeah. So I think everyone suffers from imposter syndrome. For those of you, I guess, who are not familiar, I think if you've been sort of playing a role and then you'll sort of playing that role, you might feel as if you're an imposter. That you don't have the right skills and experience doing that effectively. And I think there's a couple of things that can help with that. And I think one thing is realizing that nobody is perfect. So we all have strengths. We also have blind spots or what you might call weaknesses, where we might not be good for certain types of activities. And that's perfectly natural because we're human. There's two things that you can do with that. So one is, because we're human, we can learn. So that's a great way of being able to grow and expand in areas, where particularly you're holding yourself back, perhaps.

Pat Kua:

We talked about maybe people who weren't quite communicators and by focusing on understanding how to communicate more effectively of maybe practicing more deliberately, interacting with other people from different walks of life and departments in a normal organization. That can help you improve your communication skills. The other thing that a lot of people can do with that sort of imposter syndrome is, just because you're not good in a particular area, it doesn't mean you have to get great at that area. It's one of the reasons that you have teams. And that's what I really love about talking about people's strengths. And as a leader, tapping into the diverse set of strengths and backgrounds.

Pat Kua:

And I think this is a trap because I think some people sometimes higher or they want to have a team that is exactly the same replica as themselves. But if they're exactly the same, you won't then benefit from their different experiences or different approaches, which can be useful in different sort of circumstances. Every team at some time goes through some sort of crunch period. So you need people who have that, get it done, achievement kind of strength. And then you have other parts, where you're doing a lot more exploration, where you really want to maybe research things very thoroughly around what's the state of the art in the market? What's the risks associated with adopting any new technology?

Pat Kua:

You can read people who are quite thorough in that sort of skill, and you don't have to be great at that. If you have somebody on the team and you can tap into that strength. Knowing where it fits into the set of that sort of team. And so I think both of those things can definitely help with imposter syndrome, which is recognizing that everyone is learning, growing, and that you don't have to be great, particularly if you've built a strong and diverse team.

Neal Ford:

Do you view tech lead always as a transitional role between like developer and architect or can it be a permanent destination for some people?

Pat Kua:

Absolutely, it can be a permanent destination. I think that's the wonderful thing about our industry. We have a lot more flexibility with roles, I think. You can also go back if you want. There's this article by Charity Majors, I think who talks about the IC management pendulum swing. So people who sometimes go into leadership management and then go back to being an individual contributor. And I think that's a really great thing about being in our industry is, it obviously depends on your environment and the company that can support you. But that's perfectly natural to sort of say, "Hey, I'm happy with what I'm doing right now. I'm really enjoying the things that I do. I'm really enjoying helping a team grow." And then maybe you want to focus on more of the broader architecture sort of elements and interact with systems a lot more. But I think that's the great thing about an industry, you can sort of pick and choose because things don't ever stay static.

Neal Ford:

Well, and in fact, one of the things that a lot of architects struggle with is they don't get a chance to do as much coding as they would like to do. And a tech lead role is a nice middle ground between, you're making decisions of consequence and getting to flex some of those muscles, but you're also hardcore coding and immersed in the code base at all times. I know a lot of people who miss that to the point, where they do want to take a step back and stay swimming in code at all possible times.

Pat Kua:

Absolutely.

Neal Ford:

You said, your book was in two parts. The first part was kind of advice for beginning tech leads and the second was kind of advisor patterns for existing tech leads. Can you give us a kind of example of how the scope of those two bits of advice are different?

Pat Kua:

Yeah, absolutely. So I think for the novices, is how I sort of classify the people that were new to the role. I think when you read their stories, you get a sense of panic. You get a sense of that imposter syndrome coming through quite a lot. Like, I didn't know what this role was about. I have no idea, if I'm doing the right thing. It's really different from what I was expecting. Oh, my goodness. What am I going to do in this sort of area? So you get that sense-

Neal Ford:

What another meeting? I have to go to another meeting?

Pat Kua:

Yeah. Exactly. And so that's definitely one of the things there is, that ... I think when people fall into that role, they see people maybe who've been experienced. They seem to be handling it fine, but internally they're really stressed out. But I think there's two things, which is like, you're learning a new set of skills and relying on those skills for a role and it is a different role. So it's something new, whereas if you've been doing that role for awhile, you develop your toolkit. You don't have to think as hard to draw out the right sort of a tool for the right context. You have a broad set of skills and tools around that. So that's very common with the novices, which is, that surprise element, that shock.

Pat Kua:

And then for the second group, the practitioners, so the people who've been playing that tech lead role for awhile. I think the thing that surprised me, which I didn't really plan coming into it, but looking back at it shouldn't have been a surprise was, I sort of asked the same sort of questions to lots of different people. And the book is sort of classified into different themes that sort of emerged out of the way that people answered it. And I think that showed to me, people in that role, play that role differently depending on who they are. And I think that's what I really liked about that message, which is, there was no one right way of being a tech lead. There's lots of examples and lots of similar perhaps, approaches. But one person will play it differently because that's who they are in a different context than what other people are.

Pat Kua:

And so, that's a really powerful message, which is ... I think when we look at other people, we kind of go, "Oh well, we should be as good as them or do exactly the same things that they do." And I think the strong message that I came away from that book and that sort of practitioner's side is, it's okay to do it the way that you think is right. If that works for you in that context, just keep going with it and don't worry about comparing yourself so much to others. And so I think that's the nice sort of thing about, people had certain different focuses, so maybe some people were more inward focused on individual team members. Other people were maybe more outward focused, interacting with the business or sort of other elements. Other people were very, I would call it maybe more grounded on themselves. So the things about taking care of themselves first, to make sure that they led themselves well, so that they could lead the entire team.

Pat Kua:

And so everyone has their different sort of style of explaining how they like to play that sort of tech lead role. And so the book gives you a good set of different exemplars or examples about how people can play that role very differently and still be successful.

Neal Ford:

Okay. Well, you can see why we're interested in highlighting this book again, because this is still evergreen, fantastic advice for tech leads, but it's also, fantastic advice for people in other roles, who are curious about what tech leads do. I mean, why is there a special role in this project to tech lead and some of the challenges, et cetera? So thanks very much Pat, for writing the book to begin with and distilling your experience, but thanks for joining us today and sharing some of your insights.

Pat Kua:

Great, thank you very much for having me, pleasure.

Rebecca Parsons:

Great to see you again, Pat.