From Developer to Tech Lead

Pat Kua knows what it is to be a great Tech Lead. Not only has he worked with hundreds of clients, helping to solve their engineering problems, as part of his role as Principal Consultant and Tech Lead for Thoughtworks. But he’s also learned a lot from his conversations with other experienced Technical Leaders. Kua spoke to more than 35 whilst researching his book, ‘Talking with Tech Leads’.

He knows the Tech Lead role inside out and has seen first hand the issues they face. In this interview, Kua shares his view of the role, the mistakes he has seen new Tech Leads make and tips for being more successful. We also hear why he thinks Tech Leads should spend at least 30% of their time coding. Perhaps more importantly, we also hear how they can find the time to do so!

*Read more interviews with some of the world’s best developers on ** or follow us on *

Pat Kua has been working as a Technical Leader for eight years, working alongside Agile development teams. “One of the interesting things I’ve observed is a gap in leadership skills for technical people”, Kua says. Part of the cause of this is a lack of learning resources on the subject. “There are 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 there’s not much out there about becoming a Tech Lead.

That’s not the only problem new Tech Leads have to contend with. It’s also a lonely role — “you’re kind of by yourself”, Kua says. “There’s not a lot of support. You’re kind of thrown into this world between business people and this frustration of wanting to write code and there’s nobody there to help you”. You’re taken away from the familiar, “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” and all “while you’re still trying to get something delivered”.

Anyone who has been in any sort of leadership position will know that “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”. And so of paramount importance is the ability to “really prioritize time to its best use possible”, Kua says. As you develop in the role, you also have to broaden your perspective and take a more holistic view. “So thinking about longer-term plans, are there any bigger, nagging architecture issues that need to be dealt with”, have we made “the right technology choices or should we be looking at a new technology and if so how do you kind of introduce that”.

A common theme in Kua’s writing on the subject of Technical Leadership is that of the paradoxes the role throws up. As Tech Leads “we have to be really focused on delivering something. At the same time, we kind of want the team to be learning new technologies, to… spend time on training, to go to conferences” and “focus on removing problems and the technical challenges that we have in our environment. But, it’s… hard to balance out those two kinds of aspects”, Kua says. “I don’t think you can ever really say that’s it’s a perfectly 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”.

“When I talk to developers going into the Tech Lead role, the biggest thing is ‘do I still get to code?’,” says Kua. “My answer is, to be effective, I think you do need to code”. “Developers really respect technical ability. And it’s very difficult for people who want to follow a leader”, who “want to respect their leadership decisions if they don’t have that respect for their ability”. This probably stems from “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”. So that’s why “Tech Leads, to be effective, still need to code. Or at least, be at the coal face, where they’re reading code, being able to work with people on code” to help ensure that they really “understand what the key problems are. To 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”.

“I think 30% is a good minimum if I think that of a week, it’s a day and a half”, says Kua, about the amount of time you should actually still spend coding. Whilst at times this might not be possible due to more pressing concerns, “it’s important that the Tech Lead thinks about spending some time in the code, so you’re getting the respect” and maintain “a true awareness of what’s actually going on.”

“Tech Leads will always be interrupted”, says Kua. He recommends a few tactics to help cope with this. “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 than others. In a sort of more Agile environment, 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”.

So Kua suggests “having some sort of visible sign that says ‘actually I need some quiet time’”. “What I’ve used personally, for instance, is a flag on the desk to indicate when it’s no interruption time”. “Other Tech Leads take themselves out of the working space. So they go off to a quiet room, 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 offset 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 into the workplace and interruptions start to come”.

“I’ve worked with a lot of developers, trying to coach them into this new role”, says Kua. “When you watch new developers go into this role for the first time, I think there’s two streams”. “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”. “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”. Typically then, in the absence of true leadership, “the most opinionated developers sort of pipe up and they form the direction themselves” and this can “quickly fall apart”, says Kua. When this happens “people spend a lot of time arguing and the same things come up over and over again” and are never truly resolved.

However, Kua has also seen those that think they “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 while “I think these two extremes are elements that good Tech Leads should be able to play”, “they shouldn’t be playing that mode of Tech Lead all of the time”. Kua recommends an understanding of 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”. But it can take “time to develop an awareness of when to use which mode”.

Kua says that the people side of the role, is “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”. Another key part of this is the need for the tech Lead to act as a linchpin between engineering and the business. “A lot of the skills from Tech Leads, that 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”.

To help build those skills Kua recommends the book ‘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”.

He also recommends ‘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” — “it’s kind of natural, people are unpredictable”. “I think that the book helps people to understand how to 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.”

Kua reflects though that there’s really no one right way to solve these problems and taking a different approach “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… because rather than trying to mold people into what I see as an ideal Tech Lead, it kind of gives people a lot more freedom to mold the role into however they see it best fit their own skills.”

*Read more interviews with some of the world’s best developers on ** or follow us on *.