SE Radio 265: Pat Kua on Becoming a Tech Lead

Venue: Internet
Johannes Thönes talks to Patrick Kua about the role of a technical lead and how people become tech leads. The show covers the definition of a tech lead, the responsibilities of the role and the challenges of becoming a tech lead.

Show Notes

Related Links

• Episode 228: Software Architecture Sketches with Simon Brown
• Article: A Tech Lead Paradox: technical needs vs. business needs
• YouTube: The Geek’s Guide to Leading Teams
• Book: Gerald M. Weinberg et al. Becoming a Technical Leader: An Organic Problem-Solving Approach
• Book: Patrick Kua. Talking with Tech Leads: From Novices to Practitioners
• Pat’s Blog: http://www.thekua.com/atwork/
• Twitter: https://twitter.com/patkua

Transcripts

Transcript brought to you by innoQ

This is Software Engineering Radio, the podcast for professional developers, on the web at SE-Radio.net. SE-Radio brings you relevant and detailed discussions of software engineering topics at least once a month. SE-Radio is brought to you by IEEE Software Magazine, online at computer.org/software.

*   *   *

Johannes Thönes:     [00:01:15.01] Welcome to another show of Software Engineering Radio. Today with me is Patrick Kua. Welcome to Software Engineering Radio, Pat! Nice to have you here.

Patrick Kua:              [00:01:29.11] Thank you for having me, it’s great to talk to you on this podcast.

Johannes Thönes:     [00:01:33.21] Who are you? Who is Pat Kua? Pat Kua is a principle consultant and tech lead for ThoughtWorks. He is based in London, although he is currently working from Berlin. He has over a decade of experience in software development, and he has a strong focus on people, on business and on technology. You might know him for his Retrospective Handbook and the recently published book Talking With Tech Leads. Pat has also been involved in giving trainings on technical leadership, both internally to ThoughtWorks, as well as externally. I was part of one of these trainings.

The topic of this episode will actually be what is it about becoming a technical lead, so that’s perfectly fitting. Pat, is there anything more you would like to say to yourself?

Patrick Kua:              [00:02:30.28] No, you’ve summarized it pretty well.

Johannes Thönes:     [00:02:32.26] Perfect. Both me and Pat work for software, so that’s why I attended one of his trainings, just to keep the lock clear. The very first question that comes into mind when talking about becoming a tech lead is what is the role of a technical lead? What is my responsibility when I become a technical lead?

Patrick Kua:              The question is a really great one. I’ll start off by saying that there isn’t a single good definition for this, because every organization treats this role slightly differently. Having worked with a lot of different clients across different organizations, I can talk about what I think I see as common characteristics around what I see a tech lead’s responsibility being.

In some organizations a tech lead is sometimes called a lead developer; in other organizations it is simply called an architect. For me, the combination of these two ideas is that it’s not really about an architect role who’s sitting outside the team. It is actually about a developer, somebody who has development skills, who has the responsibility of leading the team. It’s quite different from a senior developer, who is maybe leading a certain area within a part of the system, but actually it’s trying to focus on the effectiveness of a team overall. I would expect that a tech lead is writing some level of code and also working at a very technical level.

[00:04:20.14] What I would say a tech lead is not, is what people sometimes call a technical manager, or somebody who might be more responsible for the people development, reporting lines, but isn’t necessarily concerned about architecture. Even if they have that technical background, they aren’t necessarily focused on where the system is. I would expect technical managers to be working with a tech lead.

In a lot of other companies [unintelligible 00:04:46.20] very popular roles, and I would say that they are separate roles. Even though a tech lead could be a Scrum Master, being a Scrum Master doesn’t necessarily automatically make you a tech lead.

Johannes Thönes:     [00:05:05.17] There is this aspect of “a tech lead is still a developer”, and he is focusing on the effectiveness of the team.

Patrick Kua:              That’s right.

Johannes Thönes:     [00:05:15.22] You would say a technical manager is exclusively focusing on the team, and an architect is exclusively focusing on the technology, and the senior developer is someone who owns a particular part of the software, when you want to contrast it?

Patrick Kua:              [00:05:30.27] That’s right. I want to emphasize that these are all about roles, and it doesn’t mean that an organization will have one person for each of these roles. Sometimes a person plays multiple of these roles. Sometimes the tech lead role may also be the technical manager, looking after the people in line management, and may be the most senior developer on the team. There are other situations where these are [unintelligible 00:06:05.11] or the way that the organization has structured themselves. It may be separate roles, as well.

I typically see a bit more of a division between the technical side, which is a bit more around the architecture and the system direction, and more about the people management and project management side, which might fall a bit more into the technical manager’s side. That’s a bit more of a common pattern that I would see, but I do want to emphasize that it is a role, and that means that it’s a collection of responsibilities.

Johannes Thönes:     [00:06:38.22] Before we dive deeper into this, can you elaborate on why a tech lead is actually needed?

Patrick Kua:              [00:06:47.01] Yes, it’s a really great question. When I’ve been talking at conferences about what a tech lead is, one of the first questions I often get is “Why do we need this?”, so this is a perfect question. I can definitely see situations where if you’re working a small team and everybody gets along really well and everyone understands what they need to do, maybe you don’t need a tech lead, because everyone is well aligned. That tends to be a very idealistic state, and there are a lot of teams that are maybe in a more chaotic state, and with a mix of skills.

[00:07:26.06] What tends to happen is that there’s maybe a bit of confusion about how things should be implemented or what the direction of the system and architecture should be, and it’s great when developers who are maybe self-empowered to make choices for themselves make decisions. But when they’re working against each other, you end up with a bit of a mess. For me, one of the key responsibilities of the tech lead is really keeping the developers working effectively in the same direction.

Even a very stable team who are getting alone one day may end up in a situation where maybe they disagree about the way, or a framework, or a tool (how it should be implemented), or a feature, and you end up with a division. That tech lead role there is to really shepherd the team to make sure that everyone’s heading in the same direction, for most effectiveness.

Johannes Thönes:     [00:08:23.06] I remember seeing a tweet you share in your presentation, which is “In my last project there were ten guys with very strong opinions, and all of those were expressed in code.” Is that what you’re hinting at?

Patrick Kua:              [00:08:38.27] Yes, exactly. I put that tweet in there because it summarizes it from a different perspective. If you conceptually open up a codebase that you don’t know (maybe a stranger’s) and you open up different parts of the system, a good sign of effective tech leadership and a team working together is that everything feels like it’s written by the same developer mindset. When you have ten different personalities writing code in ten different ways it becomes difficult, a maintenance nightmare, and you tend to end up with more silos, which for me is a worry about overall effectiveness.

Johannes Thönes:     [00:09:19.23] You have been a tech lead in multiple locations, so today you are quite experienced. But there was a time when you were a tech lead for the very first time. Can you describe how you felt and how it came about?

Patrick Kua:              [00:09:36.11] Yes, absolutely. My first experience was pretty shocking. I was just coming back from holidays, I was working on one team, and I got a call at the airport saying that I’ll be starting as a tech lead for another team the day that I got back. It was a bit of a shock effect about — okay, I was a developer on this team, now I’m asked to do something different; what does that exactly mean?

For a lot of people who find themselves in this role, they’re probably feeling the same concern. Maybe they’re confident as themselves as a developer, but there’s a whole bunch of maybe unexplained responsibilities and what are the things you should be focusing on as a tech lead, and how is that different from being a developer.

[00:10:25.29] For me, a lot of that experience was trying to work out what that role is, because at that time I didn’t know where to go for that information. I talked to other people who I respected, and I had access too to talk about how they approach it. I felt a little bit unsupported because I didn’t have that safety net, where I didn’t feel so safe.

Johannes Thönes:     [00:10:51.11] What did the people tell you about the tech lead role?

Patrick Kua:              [00:10:54.29] What was really interesting back then was that some of them talked about what they felt was really important and how they approached the role. I remember one tech lead talking to me about the bigger picture in architecture. When you’re a developer, you’re probably thinking a lot more about the clean code that you’re trying to write, to make sure that things are testable, to make sure that you’re thinking about how well-designed that small component is, but you sometimes forget to think about where that fits in with the bigger picture.

In the agile space we don’t talk about architecture a lot. I’m not advocating for having an architect role and just them focusing exclusively on architecture, but everyone should be thinking about architecture. That’s what part of the architect role helps people to do on the team – to come up at certain points to make sure that we’re still aligned in that same direction.

[00:11:54.00] Another tip that somebody gave me was that focus on the fact that even though you’re a tech lead, a part of your responsibility is also working with the rest of the team. This was for me starting to get some more awareness… As a developer, if you see a conflict between two other people on the team, a common strategy that you can take is to just get on with the work that you’re doing and treat that as not your problem. But as a tech lead, trying to resolve conflict or design arguments between two developers is an important thing, because you want everyone to agree on a general direction. It doesn’t necessarily matter which solution is correct, but you want everyone to at least have buy-in as to what the general idea is.

Johannes Thönes:     [00:12:42.22] Have you had a conflict in your first tech-leading gig?

Patrick Kua:              [00:12:46.26] I did, actually. As a developer, and having that technical background, I was quite confident in my technical and architectural skills. Dealing with people, it made me realize how different individuals are and how strange people can act when they work with people in different backgrounds or different skills and strengths.

Johannes Thönes:     [00:13:16.24] Can you highlight that with an example?

Patrick Kua:              [00:13:19.23] I remember a particular pair on my team – we worked typically with pair programming (two developers sitting at a computer, working on the same feature) – and one of them was a really excitable person who really wanted to get on with work, and the other person’s style to development was a lot more “I need to actually think about this problem a little bit. I wanna go off and try to model it a little bit, draw a little diagram.” I’m not saying they needed weeks or days to go do this; it was about having some space and time. I can remember hearing a couple of frustrations within the team area about one person saying, “I just wanna get on with it”, and the other person is like, “I don’t think we’re ready for it. I don’t agree on what we’re actually doing.”

For me it’s two different styles, but they didn’t necessarily understand that each person had different styles and hadn’t come up with a way of working together.

Johannes Thönes:     [00:14:24.13] Before that critical holiday, before that call on the airport, how would you have dealt with this situation, and how did you deal with it as a tech lead?

Patrick Kua:              [00:14:34.16] If I had dealt with it before the holiday, I would have probably been in the “It’s not my problem… It’s the tech lead’s responsibility, or maybe a project manager’s responsibility to deal with that.”

Johannes Thönes:     [00:14:49.01] The maximum you would have done is talk with the tech lead or the project manager?

Patrick Kua:              [00:14:52.19] I probably would have flagged it, because it feels a bit strange to deal with arguments that you’re not involved in.

After the holiday, when I was in that role, I felt that it’s really important that every developer can talk to each other and appreciate each other’s strengths and get along. In this situation, I think I ended up taking both of the devs into a room to talk about frank feedback around what I observed. It wasn’t in a way that tried to shame them; it was about trying to explore where each person was coming from and what the source of it was.

It was really useful for each person to talk about what was important to them and how they liked doing things. For me that was a really important thing, to let people air that out in a safer environment.

Johannes Thönes:     [00:15:50.17] So in the end they agreed on a working style?

Patrick Kua:              [00:15:57.20] What they ended up agreeing on was when they picked up a new bit of work, they would have a certain time where they would maybe split their pair, and the person who wanted to get on with it would maybe prototype a few things or read around some tools and technologies that were relevant to what they were going to do. The other person would go off and draw some models on some index cards, and then they’d get back together after a couple hours to talk through how they’re going to implement it.

Johannes Thönes:     [00:16:33.00] That’s a nice story. We scrabbled on the surface of what the tasks of a tech lead are, by your first tech leading tale. You need to see the bigger vision of the project, the bigger architecture. We actually have a nice episode on architecture sketches by Simon Brown, who also wrote Architecture For Developers, and it might be worth listening to it (show number 228).

It’s the working with people aspect, you mentioned it in the conflict example. What are the other responsibilities you see as a tech lead’s responsibilities?

Patrick Kua:              [00:17:15.27] On a blog post of mine I have a model which is like a Venn diagram; if you look for it, you might end up being able to connect to it. It’s about the role of a tech lead. What I describe is an overlap of three circles. One of them is the developer skills. For me it’s really important that a tech lead can write code and work with the system that everyone is working on. It doesn’t mean that they’re only writing code, but they need to be able to do it and work with the developers at any point.

At the same time there’s a circle about general leadership. What you were talking about was maybe resolving some sort of conflict, but there are a lot of other things about leadership that effective tech lead takes on. Part of some of the responsibilities will be trying to convince business people that you need to spend time as a team working on technical things, because you need to have that time to make sure that you’re as effective dealing with maybe technical depth, or infrastructure things that will actually make you a lot more effective.  It’s a two-way street, where you also need to be convincing the developers not just to work on technical things, but to also make sure that there is a connection from what they’re working back into helping the business, because you want to make sure you continue to build trust between the technologists and the business. There’s a bridging role that a tech lead typically plays.

[00:18:48.03] I touched a little bit upon risk management, and for me that’s a big thing that a tech lead should be thinking about. In most organizations that role will often have contact points with other people outside of the team. It’s typically your operational-type people or the support people who have to run the software that people build, or it’s perhaps around marketing or finance and some of the implications about the software or features. It’s really about trying to make sure that overall somebody is really worrying about risk.

Some teams may have a project manager, some people don’t, and the tech lead also needs to be thinking about the technical risks. When people are putting software into production, is there enough logging infrastructure in place so that if something goes down, teams know how to support the software? Are we making the right technical choices such that we’re not necessarily depending on a particular vendor roadmap, and if they go away then the software ends up crashing out? Are we spending enough time keeping our code clean and spending enough time in the refactoring? Because that will eventually kick in and kill the effectiveness of the team. So these general, leadership-type responsibilities.

[00:20:12.25] The third circle is around the architecture. It’s trying to help people understand more of building a system, rather than building software; thinking about not just the features that people are writing on, but also the ecosystem in which that software is going to live.

Johannes Thönes:     [00:20:29.19] Is it thinking about the fact that it needs to be deployed on a cloud or in a Docker container, and things like that?

Patrick Kua:              Absolutely. Everything is different, and some people get to run their own software or deploy into production; other people don’t get to ever see their software live, as there are different handoffs to other parts of their organization, but it’s really important that the tech lead is trying to help people understand the consequences of their feedback and trying to help the developers get as much feedback about the software that they write. Part of that is making sure that they understand what’s happening with their software in the production.

Johannes Thönes:     [00:21:07.19] The blog post you are referencing to is called Tech Lead Cycles of Responsibility. I’m going to link that in the show notes. I would like to dive a little bit deeper into a few things I saw popping up there with the leadership and also the development thing. It’s about object orientation, writing code, evolutionary architecture, things like [unintelligible 00:21:34.09] management. It feels like it’s a little bit of managing the team culture. Is that something you would see as a responsibility?

Patrick Kua:              [00:21:44.01] Yes, definitely. Team culture is a really important part, and in one of the talks that I gave, which is called “The geek’s guide to leading teams”, I talk about what should a tech lead be focused on in terms of team culture. I contrast that with if you take a team lead, the thing here about how they interact with each other. As a tech lead, some of the cultural things that I’m looking for in addition to those things are thinking about how do people approach the code that they write. Some specific examples that I look for is what sort of development culture do you want to cultivate as a tech lead, because you can have that ability to influence that.

[00:22:22.01] A concrete example is if you’re doing continuous integrations, builds get broken. I’ve worked on teams where the build would stay broken because it was a bit more of a “somebody else’s problem” type attitude. That was a reflection on maybe a type of team culture that the tech lead didn’t focus on, versus other teams, where as soon as it’s broken, a developer springs on that, a flag goes up and you know who’s fixing that build.

Johannes Thönes:     [00:22:51.08] What do you typically do to be a support, to create that team culture?

Patrick Kua:              [00:22:57.23] I think part of a lot of this stuff is around bringing the team together at certain points to bring alignment. Alignment doesn’t really happen if people are working with each other day-to-day by itself; it can, but more often than not people end up staying at their computers and maybe not talking about some of the big issues.

Some of the activities that I think about if you’re being an effective tech leader is maybe getting the development team together in a room to talk about some concerns that make sense for everyone to get agreement on. For example, people maybe log things in different formats and maybe the discussion is around “What’s our general approach to logging and how do we make sure that we log the right level of information?”

[00:23:46.05] Other ways of getting alignment, for instance getting a developer to share a certain part of their system. Maybe it’s about interacting with external APIs or other external dependencies, and to see if there’s a general, consistent approach in that. Even in a team of eight people, you might find you end up with three different strategies for dealing with external systems, and people can learn from that.

Johannes Thönes:     [00:24:12.12] What I hear you saying is a little bit what I’m familiar with as tech huddles where the team gets together and talks about technologies. Is that what you’re hinting at?

Patrick Kua:              [00:24:21.28] Yes, definitely. That tech huddle is one name and maybe one way of achieving that. Some other teams do whole group code reviews. There’s a company in the UK [unintelligible 00:24:35.26] who’s known for trying to push extreme programming even more, to the point where they’ve adopted quite regularly mob programming, where the entire team is programming at the same time.

Johannes Thönes:     [00:24:48.20] Let’s move on from team culture to something else I heard you talking about, which is growing the developer, growing people, which is also the business of a tech lead. How do you approach that?

Patrick Kua:              [00:25:03.15] I want to say why it’s important first. A very common anti-pattern that I see with particularly new tech leads is that a lot of companies tend to promote the best developer into this role. I don’t think you have to be the best developer in a team to play this role. You need to be a good developer that everyone respects, but I don’t necessarily think you need to be the best developer.

One of the consequences of when the best developer is promoted into the team is that they’ll want to keep writing all the code, the best that they can. What that ends up doing is creating a bad systemic cycle where they want to take maybe all the interesting problems, they want to tackle all the hard solutions, and leave the easy stuff for the rest of the developers.

[00:25:48.24] If you flip it around the other side and you think you’re a developer on that team, it’s not very inspiring or exciting to be working on things that aren’t so interesting. At the same time, the tech lead, in this bad anti-pattern, is maybe torn in a lot of other meetings and other things because they have other responsibilities to deal with, so it’s hard for them to do a really good job as they were as just focusing as a developer. That’s why I think it’s important to build the other developers.

[00:26:19.15] How you go to develop new developers is trying to help people connect to new opportunities that they’ve not done and give them a safety blanket around that; encouraging people to work on areas or technologies that they’ve not dealt with, and have either yourself or other people to bounce ideas off and to strategize about approaches.

Johannes Thönes:     [00:26:41.17] Can you share an example how you’ve done that with someone?

Patrick Kua:              [00:26:44.23] Yes, absolutely. On one of the teams that I’ve worked with we introduced the concept of feature leads. The idea was for me to make sure that as a tech lead I had a still good overview of how we were going to approach a certain area. Each developer got to own a feature and how we would end up implementing that area. As an example, maybe how we approach authentication in this particular example. I would pair people up so that they had support, and they’d go off, explore what we needed in terms of this particular authentication, they’d talk about what tools or libraries we might end up using, how we’d approach it and what are the potential ways that we’d end up writing or designing our code to deal with that.

[00:27:35.02] At that point I got to maybe help review some of that stuff, to make sure there are no gaps and that it makes sense in alignment with other things. When we were happy with that solution, we then doubled that up with what you would have called a tech huddle, and then got the whole team involved, to make sure they understood what the general approach would be.

What was really interesting is that some feature leads were a lot more successful in terms of being able to come up with a solution by themselves, whereas other people needed more time in terms of saying, “I don’t really know where to go about even starting about how to break this down”, and we would work together on different approaches or different options that they could explore. This is helping people grow and people who need different ways of getting there.

Johannes Thönes:     [00:28:20.13] This feature lead strategy was basically giving people explicit responsibility in the team, and then supporting the ones who struggled with that responsibility to do it completely on their own?

Patrick Kua:              [00:28:38.08] Yes, absolutely.

Johannes Thönes:     [00:28:40.15] If I’m taking over the feature lead for authentication and I don’t know how to start, what would you say to me?

Patrick Kua:              [00:28:48.08] Partly, I’d explain what I expect of a feature lead, which is around making sure that we meet all the requirements from the business side and assess all the potential risks of what type of authentication use cases we need. Part of it would be saying, “You probably need to talk to these sorts of people, to get an understanding about how they want to interact with the system.” Then they go off and look at that area, and we’d talk about “Okay, what approach do you take from a technical perspective?”

Part of the habits of a good tech lead is not giving all the answers straight away, but letting people find the answers for themselves. I do a lot of questioning to work out where people are comfortable and what knowledge they already have. If they don’t know at all where to start, like the example you gave, then I might be a little bit more directive and say, “Have you considered looking at OAuth and these libraries in this area? Do we need two-factor authentication?” Then people go off and evaluate that fit, based on the technology stack that we have.

[00:29:58.07] It might even involve saying, “Go off and run a Spike”, which is a time-boxed technical investigation where somebody comes up with a small prototype, and then we come back and we learn a little bit about that.

Johannes Thönes:     [00:30:09.12] When I’m in such situations, I typically tell the people, “That’s the terms I would start googling for.” Is that something you would also do?

Patrick Kua:              [00:30:19.29] Yes, that’s definitely an option, as well.

Johannes Thönes:     [00:30:23.24] We mentioned featured leads, which is you look at the responsibility as a tech lead and find a certain area that you delegate to someone to grow him/her. Is there also an aspect of choosing the right person for that job?

Patrick Kua:              [00:30:41.23] I prefer more of a pool model. My goal as a tech lead is I want everyone to buy into the work they’re doing, because I want people who care about that. For a lot of the points, I try to avoid explicitly choosing people. I try to get people who want to work on that area. Part of the role, which is a communication skill, is trying to get people excited about what is interesting around different areas. Sometimes you can get talking about what’s not right in different systems, or that we have to get on with this work, but at the same time some of this stuff needs to get done, and there are other opportunities to do it. So I prefer to say, “We need to look at campaign management and we need to come up with a way to integrate that technical solution with how we’re going to run campaigns across this particular product. We need somebody to come up with a technical solution and a general approach to how we deal with this. Here are the exciting opportunities and the people you get to work with that you don’t necessarily normally get to”, and then I look for volunteers.

[00:31:50.04] Sometimes you don’t have volunteers, at which point you might need to then choose people. Part of that comes down to you as a leader, building up that trust with the developers on your team.

Johannes Thönes:     [00:32:00.26] Have you ever been in the situation where you’ve felt that someone volunteered too often?

Patrick Kua:              [00:32:07.27] Yes, definitely. I would often say that explicitly. Part of me as a tech lead trying to support people being successful is also watching how much stuff they take on and trying to manage that, as well. On one of the teams that I worked on we had a guideline rule that  nobody should be working on more than two feature areas at one time, just because there’s too much work.

Johannes Thönes:     [00:32:35.26] I remember from our trainings that you also are very deliberate in knowing where people want to develop. Can you elaborate a little bit on that?

Patrick Kua:              [00:32:45.18] Yes, I think this is something about getting to know your people. A tool that you can use is spending one-on-ones with people, asking people about what they are interested in and where they want to develop in. When you ask people that, a lot of people don’t often have an answer, because they don’t think about it, and some people will have very clear goals. Some of it trying to explore what people are interested in, what their concrete goals are and where they see themselves going. As a tech lead, I’m looking for a lot of alignment between the work that’s going on that is available in the environment in which we are, as well as the opportunities that people would like that maybe they’re not yet aware of.

[00:33:33.15] As an example, I’ve had some developers that really wanted to get into this dev ops mindset of working with infrastructure, with automation, [unintelligible 00:33:44.24] trying to work on that sort of stuff, whereas other developers really don’t want to deal with that; they want to focus on the frontend, UI-type stuff. You have developers who don’t really want to look at UI-type stuff, but really want to get better at the hardcore backend services and APIs. Unless you ask people, you don’t really find out about these things, and this is where it’s really useful to spend time with each developer, and even do it as a group, as well.

Johannes Thönes:     [00:34:16.08] Switching topics a little bit, you mentioned in the beginning as a tech lead you need to code yourself. Why is that so?

Patrick Kua:              [00:34:27.18] It’s a really key thing, and for me it’s about being able to code with a system. I have an article that I refer to, which was from Computer World or Info World. In it, the author talks about how developers tend to respect other developers because they can see the code that they write. I have an example very early on from my career where I was working in a company where there were technical managers; one of the technical managers wanted me to finish this tool which would connect back then CVS into their [unintelligible 00:35:07.02]. It was with Perl bindings, and it was late Friday, and this manager came up and said, “Okay, it’s really important that we get this done before the end of the day.” We’re talking about 3 PM on a Friday afternoon, and I’m pretty confident we’re not going to get it done. I was like, “Okay, let’s work on this together.” We sit there, and he handed over the keyboard to the technical manager, and there was this look of “What do I do next?” It was clear to me that he couldn’t write any Perl, and it wasn’t clear to me what he wanted to achieve by sitting down and pairing with me on this stuff.

[00:35:49.21] I recognized this as a developer early in my career, that it’s like “Okay, I’m putting this person into the non-technical bucket over here.” At that point, you end up having a very different perspective. So as a tech lead, if your developers don’t respect the fact that you can write the system when you’re helping them try to make choices as a group about a different direction, you’ll end up probably making the wrong decisions. Also, your developers probably won’t have buy-in. It’s really important that a tech lead understands what’s going on in the code. You’ll probably get more used to reading code than writing code, but I still think it’s really important that a tech lead can contribute to the system, they know whether to go for a particular area and they know how to add extra features in, where tests would go. It’s really important for maintaining that rapport, and also just the awareness of the general technical architecture and risk.

Johannes Thönes:     [00:36:47.05] So I need to code because I need to be respected by the developers to be a successful tech lead. The second aspect was what you mentioned in the end – you also need to know what is going on in the code to be a tech lead.

Patrick Kua:              [00:37:05.28] Yes, absolutely. I see this quite a lot as well in tech leads, particularly maybe too much of an off-hand tech lead, where they trust the team. They do that, and then they come to the team and look at the codebase six months later and say, “Why have we got classes that are 300 lines long? Where are the tests?”, and where are these expectations of what they thought was good code but hasn’t really been happening so much because the team had been making that decision. This is about that technical risk management. It’s great that you trust developers and you want to give people that understanding and freedom. At the same time, you also need a feedback loop to validate that what you think is happening is actually happening.

[00:37:52.11] That’s a really key thing. As a tech lead, you need to be able to understand what the current state of the system is, to see if the balance is maybe going too far of, “We’re pushing out features too fast and we actually need to spend some time on redesigning. Maybe we need to look at a different architectural approach for one part of this system, rather than just keep adding to what we currently have.”

Johannes Thönes:     [00:38:14.05] When you code as a tech lead, is it pairing, or is it single-handed coding, or is it other types of coding?

Patrick Kua:              [00:38:23.22] It’s a great question. I would highly recommend staying away from being the lone ranger, working on particularly time-critical tasks, because you end up being a blocker.

One of the difficulties which I think we’ll talk a bit about later is about time management, and it means that you won’t really be able to continue working on something. You should try to avoid working on the critical path item. I find pairing is really a great way of working. One of the ways that I like to work with people is typically when we sit down with a feature or user story; we’re talking about our general approach, what we need to do, and we’re a little bit more explicit about the things that we’d like to approach, so that if I end up being interrupted, which [unintelligible 00:39:06.22] or I have to go to a meeting, then you can do that, things can continue, and when you come back, hopefully things haven’t veered too off course, or at least you can have a conversation with who you’re working with.

[00:39:20.14] It has the benefit of a couple of things. The person that you’re working with gets to get some extra input from a different perspective, but also you get that touch point with features and you know what’s going on in the codebase.

Johannes Thönes:     [00:39:35.29] So you’re planning the implementation parts when you start a pairing, so that the other person can continue on its own when you have to go to a meeting?

Patrick Kua:              [00:39:47.02] Yes. I want to highlight another anti-pattern, because it’s critical here. It happened on a project where I was a developer, just before I became the tech lead for the first time. My tech lead at that time had an interesting style of dealing with things that they didn’t like, which meant that we would go home in the evening as developers and they would magically [unintelligible 00:40:10.19] to everything away in the middle of the night and check it in. When we came in the morning, we’d be looking at the code and saying, “Why is it all being rewritten?” There was no discussion about why it was done, or if it was even better, because for us it was really puzzling and very difficult to maintain. It created this sense of disempowerment. I want to highlight that as a big, key tech lead anti-pattern, of rewriting everyone’s code because you disagree with it.

Johannes Thönes:     [00:40:40.10] This leads very nicely into another area. When you are a developer, you have peers around you. Suddenly, in the situation you describe, there is the developers and the tech lead. I’ve heard you talking about tech lead being a lonely role. How much is the tech lead part of the team, and how much is it really different from the developer team?

Patrick Kua:              [00:41:10.09] The tech lead is part of the team. Some of the responsibilities and a different perspective means that you feel torn between two worlds. There’s one part where you are working with a team, writing code, but at the same time you are often drawn into other things. Maybe the business is screaming for new features, and the pressure of delivering of new things; maybe a developer has come to you with a sensitive topic about what’s concerning them, and it’s really difficult to share that with everyone else, because of that personal nature.

This is where you feel both part of the team, but also at the same time outside. As a developer who has maybe moved into this role, that can be really hard. There are a lot of other roles in development teams which are typically maybe a bit more unique. Maybe you only have one tester, or one project manager, but as a developer, you’re normally surrounded by a lot of other developers and you feel put into this role where you’re both still part of the team, but a little bit out. It can feel very lonely.

Johannes Thönes:     [00:42:15.26] Apart from feeling lonely, what does this mean for you in your becoming a tech lead?

Patrick Kua:              [00:42:22.28] Some of the things I learned the hard way. You can deal with the problems yourself… You’ve been put in this position for a reason, so you’re competent in being able to do this, but it’s important to build your own support network. For some topics, it’s often better to talk with other people who aren’t associated with your current environment. This is what I talk a lot about in the courses that I lead, around building your own support network.

[00:42:52.19] In some organizations, you may be lucky that you’re working with other tech leads from other teams, or you have a lot of tech leads on the same floor. In those situations, you have the real benefit of being able to coordinate something that we used to do, called “tech lead lunches”, or tech lead sessions where you get them all together and you get to talk about a few more of the things that are difficult to talk about with your team. It might be about managing your time and your calendar, how you cope with getting back into code… Maybe it’s about the best way of getting over some conflict in the teams, or “What tools or technologies are other teams using that make sense that maybe we aren’t even aware of, because we don’t have people who know about them?” The things that are that really difficult to get that sort of feedback from within the team, and you need that sort of support.

Johannes Thönes:     [00:43:40.15] I was once in a meeting where someone asked, “Who of you is a manager, who is a developer, and who is an architect?”, and he said, “The manager is the one where you are most of the time in your e-mail; a developer is most of the time in the IDE and an architect is most of the time in PowerPoint.” I actually, “Oh, and the tech lead is most of the time in his calendar.” Is that something you discuss in those lunches? Can you share some discussions you had in these lunches?

Patrick Kua:              [00:44:14.07] With ThoughtWorks, we’re a consultancy, so we work with different clients, but I was lucky enough to be close to other teams who are working with close clients, in the neighborhood. We got together at lunchtime, because that was the easiest way for us to meet somewhere neutral. We tried to focus on a topic of the day. We had a list of topics that we wanted to talk about. I think one of the topics at the time was time management – how do you get yourselves away for meetings. There was another topic about dealing with developer issues; maybe there’s a developer that’s not [unintelligible 00:44:58.07] with the rest of the team, and what are the strategies that other people would use to help get more some more alignment around that sort of issue. Sometimes it was really technical topics, like “Let’s review our architecture and see if it makes sense”, or “Would you have approached our problem a different way?”

We’d try not to focus on things that were very developer-centric, because otherwise you could talk that with your team, like “What’s the right design pattern for this particular feature?” We tried to focus on issues that we felt were most valuable to share with peers at the same level.

Johannes Thönes:     [00:45:38.10] That seems to be a nice idea, to build a support network. Let’s look at the process of how to become a tech lead. There was this call on the airport once you came back from holidays, and by one call you were transformed from a developer into a tech lead. Have you been working towards it, or did it happen to you?

Patrick Kua:              [00:46:04.29] It was thrust upon me. That’s probably the best way of describing it. I didn’t really know where to go for support, other than talking to people. I’m thankful that I had people to talk to, but it would have also been a lot better had I been aware about what the responsibilities were and understand how to do that.

Post that experience, I ended up looking for books around that area. Probably one of the oldest books that I found was Becoming a Technical Leader by Gerald Weinberg. It was a really great book, it gives you a lot of toolkits, and it really helps all sorts of people in any technical environment, not necessarily just tech leads. For me there was a bit of a gap in terms of helping people understand what does it mean to be a really successful tech lead. That’s one of the reasons I ended up starting the book, which is a collection of interviews called Talking With Tech Leads.

Johannes Thönes:     [00:47:03.04] We’ll talk about the book later. When you suddenly start being in another role, what are the things you notice? What are the things suddenly different when you become a tech lead? It’s not like you’re a different person from one day to the other?

Patrick Kua:              [00:47:26.14] No. Part of the struggle is first when somebody gives you these roles, there’s uncertainty. There’s potentially a lot of stress, going “Am I actually doing what I should be doing?” It’s very difficult to get a list of responsibilities or areas in which you should focus on. I was not really aware about the things I didn’t know, and I was conscious that there were probably things that I should be looking at but maybe didn’t know about. I was trying to find and talk to people about what are those things that I’m not doing but maybe I should be doing.

[00:48:03.28] At the same time, I was trying to throw myself into understanding, “Okay, I feel comfortable in my developer-level skills. There’s definitely leadership skills in terms of the lead of the role, so what does that mean and where can I go to find and develop those things?” Understanding how you communicate effectively, particularly with non-technical stakeholders versus technical ones; how do you resolve conflict, how do you start influencing people, rather than being able to do that through code? Also, what does this technical leadership architecture stuff mean? Trying to focus on building up skills around that area.

Johannes Thönes:     [00:48:44.25] Is there something the developers on your team did that helped you in this transformation process? Is there something developers could do in general when they see they have a newbie tech lead to support him?

Patrick Kua:              [00:49:00.11] If I think back to a couple of my team, the things that helped me as a tech lead is making sure that I get feedback from various sources. One of my favorite tools for doing this is maybe part of the one-on-ones, or maybe is part of a different session, which is doing 360-degree feedback cycles. Sometimes we can go away – I’ve seen this with other tech leads, where they think they’re doing a great job, but actually the developers have a different perspective. I think it’s really important that as a tech lead you ground yourself in getting that feedback about what the perspective is from the developers. It’s hard to do if you haven’t built up that trust, but it’s really important, and it deepens that trust once you have that respect with your team.

[00:49:42.16] If you can actually talk about “What do you see me doing as a tech and your expectations? Am I fulfilling them? Where do you think I’m weaker or I could improve on? Where are the things that you think I’m doing a pretty good job?” You can get some more perspective around that and validate that across the team.

Johannes Thönes:     [00:50:06.01] Getting feedback is an important tool. What kind of feedback did you get, if you would like to share some of it?

Patrick Kua:              [00:50:15.11] I had some feedback from my team – it’s a personal thing about when I context-switch a lot, I am very task-oriented, so I end up getting a bit more directive. Particularly when I’m stressed, I maybe don’t give enough time for people to talk about their story or the pain points, and I’m really focused on “What are we doing about it?” That was a really useful checking point, because a) when you’re under stress, you don’t realize how much that’s affecting your behavior, and we all have different coping mechanisms for that. That also helps me understand what’s not working with the team, and we ended up agreeing on a mechanism for me to both deal with the stress in terms of the context-switching by having more specific times where maybe I could be more interrupted, and times where I needed to just focus thinking about bigger issues.

[00:51:18.22] It made me a lot more aware of how I was interacting with people when I was under stress. I tried to give people more time and empathize with their current situation, rather than try to drive for a particular solution.

Johannes Thönes:     [00:51:34.00] Let’s go a little bit into summary. There is one question that’s nagging around when you’re doing tech lead for the first time, or even today: how do I know that I’m good when I’m tech leading?

Patrick Kua:              [00:51:50.20] It’s a great question, I’ve never really thought about that. Everyone has a different technical leadership style. What good looks like – you have to appreciate or recognize how you approach stuff. A good sign that a tech lead is working is that you don’t really need the tech lead from a day-to-day perspective. If a tech lead is constantly involved in meetings and constantly giving the reasons to everything, they’re probably not being so effective as a tech lead.

[00:52:25.04] If we connect to one of the first questions that you asked, which is “Why do we even need a tech lead?”, if you’re being an effective tech lead, you can go back to being a developer role, still focusing on that bigger picture and watching for whether there’s misalignment. But if you’re doing your job effectively, then the team should be aligned and there shouldn’t be so many arguments, or they can resolve it themselves, and there is that general consensus.

Johannes Thönes:     [00:52:53.17] You’ve written a book, it’s called Talking With Tech Leads: From Novices to Practitioners. You’ve been interviewing a lot of tech leads, always asking the same few set of questions. You have multiple perspectives of how a tech lead can be, in this book. What I like about it is that it shows very concrete that every tech lead has his own style. What did you learn during those interviews?

Patrick Kua:              [00:53:28.08] The first part is what you already sort of answered, which is that there’s different approaches to taking this on, and each one is okay. When you move into that role, you’ll question yourself about “Am I doing the right things?” and you will have your own style; just because a tech lead on a different team approaches it differently doesn’t mean you’re doing it wrong. For me it was really understanding that there are different tools and approaches that people use, and there are different focuses. One of the biggest takeaways for me was when I’m in this role of a tech lead, I don’t take enough time for myself.

[00:54:11.29] That was an interesting observation from Jon Pither in the book. He was focused very much on meditation and being in the moment, trying to make sure that he has that time to focus on what he’s doing right and to prioritize your time. That was one of my biggest takeaways out of that book – making sure that you make enough time for yourself.

Johannes Thönes:     [00:54:39.03] How many tech leads have you been talking to?

Patrick Kua:              [00:54:45.05] I ended up talking to about 37 different tech leads. There was a few more, but I was trying to get for some depth. I also tried to focus on trying to find female tech leads. It was really interesting, because as an industry we have a problem with trying to get enough female developers. Getting some female tech leads into the book for me was a personal goal. That was interesting, trying to reach out to my network of people about who I could talk to around that.

Johannes Thönes:     [00:55:16.00] What did the different tech leads talk about? What were the main topics?

Patrick Kua:              [00:55:23.01] The book is split into two areas. One is focused on novices, and the people who have been doing it for a while, which I’ve labeled as practitioners. It was interesting, because with the novices there was a law of commonality around that shock, of “I’ve been a developer, I’m not in this tech lead role. What does it mean?” It was great to hear that everyone had the same struggles, because I hope that that helps people recognize that if you move into that role for the first time, it’s a normal thing of being in that role, and that’s okay.

[00:55:57.04] In the second part of the book there were some emerging themes that came out. There was one which was about managing yourself, which was a whole theme. This was trying to focus on prioritizing your time, making sure that you understood whether you’re spending time to be the most effective, and that it’s okay to spend time planning where you spend your time.

There was a whole section around people, and for developers this will probably be one of the more difficult parts to develop. Developers will naturally move towards more technical-type, architectural thinking, which is the [unintelligible 00:56:40.04] understanding people and dealing with difficult people circumstance is something you don’t practice as a developer, so you don’t have that experience to build on, and you’ll need that when you more into that role.

The final category was around bridging tech with business. We haven’t talked about it much in this context, because we felt a little bit more inwards and on the architecture and technical side, but the tech lead role in a lot of organizations is about bridging with the business, trying to make sure that there’s a close connection with the technical team and delivering to business value, and helping the business understand what the technical terms mean, what the architecture means, what the implications of decisions are and how they affect potential business opportunities.

Johannes Thönes:     [00:57:31.06] That was my last question. Now is your opportunity to answer to any question I should have asked. Is there something you want to say in the end, some final pearls of wisdom?

Patrick Kua:              [00:57:46.16] My advice to people who want to develop themselves as a tech lead is I hope that the mapping out about what a tech lead should do is a little bit clearer through some of the work that I’ve been trying to focus on, and I hope that it helps people start to understand that it is a map of different skills in areas, and you can find ways of developing and practicing some of those skills to make it explicit.

Make sure you build up your own support network. That’s a really key thing. Being a tech lead shouldn’t be a shameful thing, because some people think that sometimes you move post technical, but actually it’s about having a positive impact. As a developer, you get frustrated sometimes about your environment, but as a tech lead you get to help shape that, and that’s an exciting opportunity.

Johannes Thönes:     [00:58:43.17] Thank you very much. How can people find out more about this topic? There’s the book, they can buy and read…

Patrick Kua:              [00:58:54.14] I tend to blog a lot — or maybe not a lot, but quite frequently — on these topics about technical leadership on my website, which is www.thekua.com. I’m also pretty active on Twitter, and I’d love to hear questions and puzzles, or even your thoughts on what a tech lead should have. I learn a lot by talking to people about the problems that they’re having, and I love to share my experiences, so do reach out. My Twitter handle is @patkua, and there’s the book website, which you can find on Leanpub.

Johannes Thönes:     [00:59:33.19] So the next thing would be how to reach out to you. That will obviously be in our show notes. We will link the blog post mentions and also Pat’s website, as well as Twitter profile. Thank you very much, Pat, for this interview. It was very interesting.

Patrick Kua:              [00:59:54.24] Thank you for having me. You’ve had some great questions and I’ve really enjoyed this discussion. Thank you.

Johannes Thönes: Very good.

*   *   *

We at SE-Radio want to hear what you think of this show and of all the other shows, so reach out to us, use the comments on the website to comment on this episode. We have a team e-mail, which is [email protected]. We have a Twitter handle, which is @seradio. You can find us on LinkedIn, Google+, Facebook. Let us know what you think of us. That would really help us. Thank you for today. This is Johannes, for Software Engineering Radio. Thanks for listening. Bye!