Fog Creek

Becoming a Tech Lead – Interview with Pat Kua

Looking for audio only? Listen on and subscribe

In this interview with Pat Kua, Principal Consultant and Tech Lead for Thoughtworks, we discuss becoming a Tech Lead and the challenges faced by those new to the role. Pat is the author of the book ’Talking with Tech Leads’, in which he spoke to more than 35 Tech Leads about their experiences. We cover common issues faced by Tech Leads, the nature of the Tech Lead role, why he thinks Tech Leads should spend at least 30% of their time coding, and how to find the time to do so! We finish by discussing common mistakes new Tech Leads make and with Pat’s recommended resources for those wanting to learn more about being a successful Tech Lead.

He writes about topics like this on his blog.

Content and Timings

  • Introduction (0:00)
  • About Pat (0:24)
  • Talking with Tech Leads (1:07)
  • Common Issues Faced by Tech Leads (2:22)
  • The Tech Lead Role (7:00)
  • Tech Leads Should Code (8:14)
  • Common Mistakes of New Tech Leads (12:28)
  • Recommended Resources (15:02)

Transcript

Introduction

Derrick:
Today we have Patrick Kua, principal consultant and Tech Lead for ThoughtWorks based in London, UK. He speaks and writes about Agile development, Continuous Delivery and is the author of two books, ‘Talking with Tech Leads’ and ‘The Retrospective Handbook.’ Pat thank you some much for joining us today, I really appreciate it. Why don’t you say a bit about yourself?

About Pat

Pat:
Sure, firstly thanks for having me. I’ve been working in the industry for quite a long time and working as a consultant in spaces with Agile teams. One of the interesting things I’ve observed is a gap on leaderships skills for technical people. And I think it’s kind of an important area for developers to look at, particularly if they’re looking towards an architecture career. If they’re looking to lead teams or work with people. And my interest in being in this space of working and developing developers who want to move in to the role of a Tech Lead or an Architect.

Talking with Tech Leads

Derrick:
I wanted to touch on the book, ‘Talking with Tech Leads’. What made you want to write the book?

Pat:
It was quite interesting actually, because I went through the transition many, many, many years ago and I’ve worked with a lot of clients, I’ve worked with a lot of developers trying to coach them in to this new role and what I’ve really found is that people really struggle to find good materials out there. So, there’s lots of books that teach you how to be a great developer, that teach you how to learn refactoring skills, things about good clean code, how to unit test stuff, but actually trying to build a solid architecture at the same time as convincing people that it is a good architecture and to get developers to contribute towards this – there’s actually not a lot of stuff out there. And I kind of focussed on this idea of talking to different types of Tech Leads because I think, it’s kind of interesting when you talk to other people who have been through a similar position, when you’re a Tech Lead yourself, you’re kind of by yourself. And there’s not a lot of support. You’re kind of thrown in to this world between business people and this frustration of wanting to write code and there’s nobody there to help you. So I kind of wanted to focus on actually collecting the experience of different people going through that transition or have been through that transition to see if there were sort of common themes that would come up.

Common Issues Faced by Tech Leads

Derrick:
So you went and spoke to what, 35 Tech Leads about their roles. Where there any themes or topics that kept coming up?

Pat:
Absolutely, yeah it was quite interesting talking to people. I had started off my quest starting to try and find people who were quite new to the role. Which actually was a huge challenge by itself because once a Tech Lead has been through it one, they kind of understand what it is, and it’s hard to relive that first step into the role. And then talking to more senior, seasoned Tech Leads, it was kind of interesting. So for the people who were stepping into the role the first time, a lot of the challenges were actually about the people side to the role. So it was kind of being thrown away from this world where you’re surrounded by compilers, test frameworks, new technologies and then suddenly you’re having to worry about who on your team is currently a bit upset, about trying to negotiate an agreement between two very opinionated developers, or maybe more than two… while you’re still trying to get something delivered and at the same time, sort of business folk, are depending on you to come up with plans and deliver on schedule. And that’s quite an overwhelming theme that emerged from the first group. From the more senior, seasoned group, so the people who had been Tech Leading for a while, a lot of the themes were the surprise of having a broader outlook, so your day-to-day thoughts aren’t so much as what features you’re developing, even though you still write code, but it’s kind of thinking more outwardly. So thinking about longer-term plans, are there any bigger, nagging architecture issues that need to be dealt with, or are there the right technologies choices or should we be looking at a new technology and if so how do you kind of introduce that. There was also another aspect, which was around the business side. To dealing with technical ideas or technical topics in the context of a business setting. So, in the book I talk about bridging with business. And a lot of the skills from Tech Leads, that they end up being developed is this kind of translation, where you’re kind of trying to avoid all of the technical terms, and trying to express it in ways that your normal family members might be able to understand who don’t understand technology whatsoever. But you kind of need their buy-in to understand why you’re going a certain direction with things. And the final topic or theme, that emerged was really about dealing with yourself. So I think it’s true for anyone in a leadership position, which is you won’t have enough time to deal with all of the things that you’d like to do, and this is true when you’re being pulled in quite a few different directions. But I think it was really nice to hear some of the experienced from Tech Leads particularly reflect on how they manage their time, how they avoid stress. So one of the Tech Leads talked about meditation about his go to thing about managing himself. Trying to really prioritize time to its best use possible.

Derrick:
Having been a Tech Lead yourself for a number of years, you obviously had some ideas of the challenges that Tech Leads face. Were there any issues that came up that surprised you?

Pat:
Yeah, I think that the last thing about managing yourself was one of the things that I never really thought of. When I was playing Tech Leads a lot of my time is thought about outside, and actually going through this process has helped me reflect on how I manage my own time, what my own strengths and weaknesses were. And it really made me self-reflect on how I can improve myself as a Tech Lead as well. And that was a really interesting thing. I think understanding my strengths and weaknesses helped me to understand that everyone has their own personal approach to these themes and that’s a really nice aspect to the book as well, it kind of shows how everyone focusses on different things, they think about different things, but it doesn’t necessarily mean that they’re better or worse. It’s just a different way of achieving the same sort of goals. And I think for me that was sort of a surprise and also pleasant message, because rather than trying to mold people into what I see as an ideal Tech Lead it’s kind of gives people a lot more freedom to mold the role into however they see it best fit their own skills.

The Tech Lead Role

Derrick:
On your blog you go into some of the challenges about being a Tech Lead, you often position it as a paradox. Is that how you see the Tech Lead role, as one where you have to constantly balance competing forces?

Pat:
I think to be a successful Tech Lead it is definitely one of those key things. So, it kind of comes back down to the ‘you can’t do everything at once’, so what do you do? And I think the natural choice is to kind of say ‘well, I’ll focus on one thing’ at the cost of everything else. And this is where the paradox comes in, so one of the examples that I’ve written up on the blog is often talking about we often work with developers in a professional context, so we have to be really focussed on delivering something. At the same time we kind of want the team to be learning new technologies, to sort of spend time on training, to go to conferences, to sort of focus on removing problems and the technical challenges that we have in our environment. But, it’s kind of hard to balance out those two kind of aspects. So the paradox of do you spend more time on learning or do you spend more time on delivering, I don’t think you can ever really say that’s it’s a perfect unbalanced equation, it will wax and wane depending on what things are going on. But it’s a key skill for a Tech Lead to sort of accept the paradox and embrace the paradox and to find a way to do both at the same time.

Tech Leads Should Code

Derrick:
Having transitioned from a Developer to a Tech Lead, you obviously can’t spend as much time coding as you’d like given your new responsibilities. But you recommend Tech Leads spend, what, like 30% of their time coding? Why do you think that that’s so important?

Pat:
It has been really interesting though because, when I talk to developers going into that Tech Lead role, the biggest thing is ‘do I still get to code as a Tech Lead or do I get to do this sort of post-technical work?’ and it’s a huge concern. And my answer is, to be effective, I think you do need to code. I’ll go into the reasons why in a second. But the next immediate question is ‘well how much time should I actually spend coding?’ in order to be effective. And I guess my reasons, why I think it’s important for people to code in this role, is that, I think developers really respect technical ability. And it’s very difficult for people who want to follow a leader, and you want to respect their leadership decisions, if they don’t have that respect for their ability. And I think I recognize this in myself as a developer as well. I don’t understand how, this sort of the classic ivory tower architect, that makes decisions far removed from the context of the problems that we experience on a day-to-day basis. And I think that’s one of the key reasons why Tech Leads, to be effective, still need to code. Or at least, being at the coal face, where there reading code, being able to work with people on code, is that they really have to understand what the key problems are. They understand the language that developers use, so that they can talk at the same sort of level, and also know when people are maybe making a bigger deal out of something that’s maybe technical not true. So I think that’s a skill that Tech Leads need to find out. I think 30% is a good minimum if I think that of a week, it’s a day and a half. Ideally, it’s great if a Tech Lead can do more. But, there’s also phases of a product or project where if there’s lots of recruiting going on, or if there’s budgeting type cycles, then the Tech Lead will be the first to get pulled out. But it’s important that the Tech Lead thinks about spending some time in the code, so you’re getting the respect across the rest of the team and just to have a true awareness of what’s actually going on.

Derrick:
The Tech Leads I know are constantly interrupted, are there any techniques or ways of working which can help deal with these interruptions and sort of block out time for things like coding?

Pat:
Tech Leads will always be interrupted. It’s a pain, and it’s quite interesting talking to some of these Tech Leads about how they approached this. So some Tech Leads simply block out time in their calendar so that they can actually spend time without interruptions. I think that’s easier in some environments that others. In a sort of more Agile environments, where the team is all co-located, there’s lots of things going on, even blocking out your calendar doesn’t really solve a lot of that problem because people will just come and walk up to somebody and interrupt them, because they’re available. I think that that’s an easy thing to do. A technique that can help in this type of environment is just having some sort of visible sign that says actually I need some quiet time. So I’ve used personally for instance, a flag on the desk to indicate when it’s no interruption time. And it’s not that I’m not available, but it’s that I needed time to really focus on something and think about things and I’ll be available shortly after as well. Other Tech Leads take themselves out of the working space. So they go off to a quiet room, so they book a meeting room and then they sit in the room by themselves. Just so that they can go through a few things in quiet time. Another way is to maybe off-set your day as well. So either, start early or end early but do the same sort of hours. And this kind of helps you to get through all of those things before everyone else gets there in to the workplace and interruptions start to come.

Common Mistakes of New Tech Leads

Derrick:
So not spending enough time coding seems like a common mistake Tech Leads can make. What other things do you see that people sometimes get wrong?

Pat:
This is kind of interesting, so particularly when you watch new developers go into this role for the first time, I think there’s two streams of a Tech Lead that I see. So there’s the Tech Lead that believes that the entire team should be self-empowered, every developer should know what they should do, and the Tech Lead wants to have trust in everyone. And so they sort of just sit back and hope for the best. And I think this is where things get a bit dangerous if the team hasn’t gotten into that mode and they don’t already have that strong vision. I think what happens there is that probably the most opinionated developers sort of pipe up and they form the direction themselves. But in these kind of environments things kind of quickly fall apart. Particularly arguments between developers, they go unresolved. People spend a lot of time arguing and the same thing comes up over and over again. In the other extreme, I see Tech Leads who see themselves as I need to demonstrate that I’m a Leader, they’ll want to still make all of the heavy technical choices, so they’ll want to be involved in every technical discussion, and it’s important that they have their own say and they make their stamp on the project. And I think these two extremes are elements that good Tech Leads should be able to play, but they shouldn’t be playing that mode of Tech Lead all of the time. So one of the leadership models that I talk about is the situation leadership model, which kind of talks about situations where more directive behavior is useful. Where maybe more targeted coaching is useful, and where perhaps pure delegation, and just sitting back and trusting the team to do the things that need to be done makes sense. And the great thing about the situation leadership model is that it helps people identify when and where to use these modes of behavior without actually saying it’s good or bad. And without saying you have to act like this all of the time. So I think that takes a lot of time to develop an awareness of when to use which mode, but it’s probably one of the first things that I see with first time Tech Leads.

Recommended Resources

Derrick:
Can you recommend some resources for developers or new Tech Leads who want to learn something about being successful in the role?

Pat:
I think there’s quite a lot of books that can help Tech Leads, and I think particularly from a people side, that’s one of the hardest things for a Tech Lead to learn and it’s just a skill that you don’t necessarily practice when being a developer. And I think there’s a couple of books that I would recommend.

I think the first one would be a book called ‘Getting To Yes’. The book is about negotiating, and it’s about trying to come up with a good way forward while you’re trying to appease both sets of interests. What’s great about it, is that it’s a very short book and I think it has some really great stories that help people to understand some good skills.

I think the other book around sort of people skills would be ‘Crucial Confrontations’ and ‘Crucial Conversations.’ I think it’s useful because there will always be some tense situation at some point in a project with one or two people in a project. It’s kind of natural, people are unpredictable unlike computers, although computers can also be unpredictable. But I think that the book helps people to understand how do you have a discussion around the topics where they’re emotionally sensitive, or you know that you have a certain position and reaction where you need to deal with a difficult topic and talk to somebody about it.

And I think that those two books are very good starting books for Tech Leads to learn about people skills.

Derrick:
Pat, I want to say thank you so much for joining us today.

Pat:
Great, thank you for having me.