#9 - Tech Leadership & Hypergrowth at Fintech Bank N26 - Patrick Kua

Episode Introduction [00:00:43]

Henry Suryawirawan: Welcome to another episode of the Tech Lead Journal podcast with me your host, Henry Suryawirawan. If you have been enjoying the podcast and would like to follow any new updates coming out of the show, you can subscribe to our email list at techleadjournal.dev, or you can also follow our social media channels on LinkedIn or Twitter. I’ve been very encouraged by some of your likes, your posts, your sharing and your retweets on those channels. And I hope that more of them can keep coming in order to spread this podcast to more people out there. And if you would like to pledge your support and contribute back to the show, make sure to check out our patron page at techleadjournal.dev/patron. I will greatly appreciate your contribution and it would help me towards achieving a goal that I’m currently running on the page.

For many of you listeners out there who have started following this show since the beginning, some of you asked me whether this show is solely focused on the Tech Lead role due to the name that I use for the show. I would like to just clarify a little bit that this show theme is around technical leadership and technical excellence. I think it just sound less catchy and a bit mouthful, if I named the show Technical Leadership Journal. And thus I chose to shorten the Technical Leadership to become Tech Lead. And that’s how I ended up naming this show as Tech Lead Journal. In summary, this show is not solely focused for just Tech Leads, but it also covers technical leadership and excellence in general.

However, for those of you who are the real Tech Leads out there, do not be disappointed! In today’s episode, I am really, really excited to share with you my conversation with Patrick Kua. Pat was my ex-colleague in ThoughtWorks and is someone that I look up to and always follow for any Tech Lead related knowledge and wisdom. He has spent many, many years researching about the role and even came up with training workshops and materials to teach people on how to become a good Tech Lead, including a book titled “Talking with Tech Leads”. I have been into one of his workshops, and I must tell you that it is one of the best resources out there to learn about being a Tech Lead.

After ThoughtWorks, Pat moved to N26, a digital banking scale-up based in Berlin, to become their CTO. And there, he showcased his technical leadership skills, transforming the product and technology team and culture to highly aligned with the demand of the hypergrowth scale-up company. This episode contains a lot of our deep conversation about Tech Lead, including the definition of the role, the quality attributes, how to be effective in the role, and some of the success measures. I highly enjoy our conversation and I hope that you all can learn a lot from it. And make sure you leave me any comment or feedback about the episode. Let’s get started!

Introduction [00:04:14]

Henry Suryawirawan: Hey Pat, it’s good to see you again. Welcome to the Tech Lead Journal.

Patrick Kua: [00:04:18] Hi Henry, nice to see you. Thank you very much for having me here. Pleasure to be here.

What Pat is Up To [00:04:22]

Henry Suryawirawan: [00:04:22] Yeah. I’m really, really excited to have you here because I’ve been following a lot of your work since ThoughtWorks days. (I’ve) been in one of your Tech Lead Workshop as well. I really, really enjoyed that and I hope you can share some of the tech lead wisdoms that you have here as well with the audience. And I’m also looking forward to learning of your ThoughtWorks story and with N26 and also with what you’re doing at this moment. So probably we can start with what are you up to now at this time? Patrick Kua: [00:04:46] Yeah. Thank you very much. So, I left N26 at the end of last year, I was there for about 2.5 years as CTO and Chief Scientist. I think to explain a little bit about what I’m doing now, I wanted to just give a little bit of background as to what I was doing there. You’ve benefited from some of my Tech Lead training and material and I’m very passionate about this topic, as you can tell, I’ve been doing it for a while. And that’s one of the reasons I decided to go more independent. I really enjoyed my time growing technical leaders at N26. I ran this Tech Lead course about five or six times internally just because we had so many people that both needed to go on their Tech Lead journey, but I also wanted to make sure they had the right support. And I had a lot of requests from other companies about helping them with building out their technical leaders and also themselves as CTO and VP Engineering. From my perspective, it’s something I enjoy doing. It seemed like there was some demand for this and as a result, I wanted to be able to do it outside of just one company. So that’s the trade offs with being in a more permanent spot is that I could do it with all the people in that company, but then I was also limited to that.

At the beginning of the year, I went more independent. I’m focusing on a couple of different things. So one of them is coaching and mentoring of CTOs and VP Engineerings, of particularly scaleups. So, I’ve been there as a CTO. When you were at that sort of top executive area, you can feel quite lonely and it’s often good to have support, be it their peers or mentors, who can help you through interesting, challenging times. Particularly with scale-up or startup type companies, a lot of people haven’t had the experience and so they just want to understand what are the challenges and how to do that. So I combined mentoring and coaching at an individual basis. I like working with the people at the top of the company because they’re creating the environment for everyone else. So my theory here is that if I can help those technical leaders be a lot more effective, then everyone in that environment benefits from that as well. So that’s what I really enjoy doing.

The second thing I’m doing is running Tech Lead workshops. Obviously with the current situation and COVID, I haven’t been able to do that many in person. At the beginning of the year it was happening, but like everyone else, I’ve had to adapt. I’ve adapted that in a couple of different ways now. So I have self-driven learning courses on a website called the Tech Lead Academy. For the moment I’ve developed two courses, one about time management and systems thinking. I’ve recently launched an online workshop built from the ground up, particularly for this distributed manner. It’s a three-hour workshop because translating two days into an online two day thing, I know just won’t work. So it’s a three-hour workshop where there’s interactive exercises, there’s interaction with myself, using some tools that allow us to do group interaction, which is a lot more effective than point to point over Zoom or Hangout and then some exercises. I’ve run one of these workshops already, and then I’m doing one more per month until the end of the year. And then, I’ve had a little bit more free time and flexibility to pick up some interesting projects so I can do things like this podcast, thank you very much, and meet some interesting people. Like everyone else this year, it’s been a very unplanned, but also adaptive year and I’m also just really grateful that I can do a lot of my work remotely.

Pat’s Career Journey [00:07:37]

Henry Suryawirawan: [00:07:37] Cool. Thanks for sharing that. I see your career profile, it’s very interesting for me, so maybe we can go into your career journey, right, you spent about almost 14 years in ThoughtWorks. The last role you have is, I think, Principal Technologist and then afterwards like what you mentioned, two and a half years in N26 as a CTO. Can you maybe share with the audience here about your career journey, what are some major interesting turning points or highlights or maybe challenges that you went through that you want to share?

Patrick Kua: [00:08:04] So maybe we can go back to the very beginning. I’ve been working for about 20 years and I wasn’t one of those people that was programming as a kid. I was actually quite lucky, I grew up in Australia and I took a class in high school called, I think it was ICT, Information Computing and Technology , where we learned everything about like word processing, where we actually did do a little bit of programming, so that was Turbo Pascal back then, and even things like Database Access programming, which is very interesting. I just love this world of creating something out of nothing to a certain degree, like digital kind of products and that creativity that you get. So I decided that’s something I would pursue in university, and studied a Business/IT degree at Bond University. From that, I was really lucky to fall into a couple of different opportunities. I did an internship with Bell Labs, that was (then) part of AT&T, which became Lucent at the time. I actually learned a lot of Perl there, which is interesting. It’s one of those hidden things that I don’t typically talk about cause everyone tends to go, Ooh, Perl, it’s like PHP, we don’t like that. When I was there, I worked on this amazing project built by some really amazing engineers and I was there extending it. And it was one of the most well constructed (and) designed set of testing scripts that I’d seen. Me, as a junior intern, being able to extend it just shows that you can design systems well, regardless of language. So I don’t tend to think about language as being better or worse. There’s obviously trade-offs but it really comes down to how people engineer things.

For me, that was actually a really important lesson because when I went into work full-time, one of my leaps was at Oracle where we were doing an R&D healthcare platform. For me, I saw this engineering excellence from Bell Labs, and I was a bit torn cause we had to use these internally built frameworks, which were poorly documented, which were not typically very intuitive and we didn’t have a lot of training around that. So for me, it was like an opposite. I was actually really lucky because during that first job in Oracle, we were actually experimenting with early versions of Extreme Programming. I was sitting on really long telephone calls going through a requirement specification, trying to understand what we needed to do for building this healthcare platform and I was like those first graduate engineers saying, “Hey, I just want to write some code. Give me something to do. I don’t want to just spend time reading a specification.” And I managed to pester my manager enough, that he actually gave me some side projects that he never found the time to do. So if I now put myself in his shoes, he was engineering manager or tech lead, but he was caught up in meetings all the time, so he never had any opportunity to code. He had lots of great ideas of making things better, but he just never had the time to code. This is actually a great opportunity that he delegated to me.

We were trying to use the first version Continuous Integration server called CruiseControl. We were using a source control called CVS. So if you think about Git, the precursor to that was Subversion and then precursor to that was CVS. So it’s three source control systems ago. But the internal release process Oracle used a proprietary home-built version of source control. We wanted to use Continuous Integration, which was only working on CVS and so I ended up using my skills with Perl to actually write an adapter layer. As people checked source files into CVS, it would effectively mirror and push all the file changes into the internal source control system, including things like tags and branches. Those are really fun projects that I worked on and we got to play around with unit testing, with JUnit. We got to experiment with Continuous Integration, trying to really use the benefits of that. And also helped me underline why mindset makes a big difference in our industry.

An example I’ll give you is as we were experimenting with JUnit, the first unit testing framework or automated unit testing framework that I worked with. People wrote unit tests, but the way that they would write it is they would use system.out.println, the current value is X and then system.out.println, the value should be Y. There’s something that you’re not fundamentally getting about this. It’s that this old pattern of “here is how I used to debug systems simply in a different tool” and it made this interesting thing where people just follow the tool, but they’re not thinking about what’s the purpose of it and the value for it. For me, that’s been a principle of mine, thinking about when we do use a process, when we use a tool, we should be thinking about the value we get out of that and are we getting what we intend to get out of it. Because the context matters and the wrong tool or the wrong process and the wrong context won’t give you that value or it can really impede you.

That led me down the path of Extreme Programming. Where else can I do more of this sort of stuff? That’s where I joined ThoughtWorks and one of my first projects that I was on in Australia was working on this startup. Probably they’re more of a scaleup, they’d been running for a couple of years, but they had problems scaling their systems, so we worked with them to boost their development team and also to also scale out their system. As an example, back then Oracle had release cycles of probably 8 to 12 months, we were releasing into production every week or 2 weeks in this startup. It was such a very different environment. There was nothing like Continuous Delivery tools. There was nothing like cloud computing back then. And here we are actually releasing fairly continuously into production. Short planning cycles of every 2 weeks or every 4 week planning horizons. And it was just a really fun environment to work in. I learned a lot as an engineer there, building systems, releasing into production.

And then I moved over to the UK where I was doing lots of consulting for lots of different types of companies. Everything from telecoms, banking, government, charity. I think for me, the interesting part here was thinking about not just the engineering, but also why is it that some engineers have maybe a bad experience, they can’t do what they can. And I realized that had to do a lot with the environment. And it really depended on the technical leader or manager and how people set up that environment.

One of the reasons I have done a lot of reading over my lifetime around good leadership, good management, is because it has such an effect on everyone in a company. We have so many examples of really poor management and poor leadership. We need more concrete advice about how people can be more effective leaders and managers, so that we can unleash the potential that everyone has in that workforce.

That’s something I’ve really enjoyed doing. Working as a consultant was like working within teams helping people feel more empowered through adopting more agile processes. But then also starting to work with leaders and managers to help them understand their style needs to change. In a very command and control kind of culture, the leader role is seen as a particular type, but in more agile empowered cultures where, I often find myself repeating this, engineers don’t often need to be told how to solve problems, because the essence of engineering is problem solving. And what they need to understand is: What is the problem? What are the priorities? And also what are the constraints in that environment? What to optimize for? What are the trade-offs to consider? Leave the engineer to actually come up with the solution and implement it. But, they need help with that environment and so that’s where seeing leaders successful or not and what made them successful in this environment.

My journey went through leading teams, working with management in other companies that we worked with to help them unleash that. And then started working with senior leadership people, so being at a director or a CTO, helping them understand how they set up the overall organization so that leaders and then teams could be a lot more effective as well. Sometimes that was in the context of migrating legacy systems and often it was more about the organizational side.

When I had the opportunity to become a CTO of a scaleup, I’ve done consulting for a long time, it was always working through other people. I felt it was a really good opportunity to actually move in and actually have the accountability, but also the decision making authority to say, “This is the organization I would like to build.” I was very proud of the team that I built there. When I came in, we had a very small engineering team. Technology was about 50 people, of which about 35 of those people were product engineers, and it was a very small proportion of the business. One of the interesting things I noticed there was actually the ratio of builders to people who have ideas was way out of ratio. And so I needed to address that by hiring and getting that to a good balance. But I also knew that the business was going to grow really rapidly. The proportion of people who had more requests for things to build was also going to grow, so I had to really amplify hiring, which meant a very aggressive growth strategy for our engineering team.

By the time I left at the end of last year, two and a half years later, growing the team from 50 to about 370 people - very large growth. And also that’s an interesting thing cause you have to think about, as things grow, you’ll get different constraints and problems along the way. This was really thinking about, okay, what stages will things break down? And so how do you change structures, team structures? How do you introduce roles or capabilities that you didn’t have before at different stages? And then also, how do you sustain that growth as your product and engineering team is really, really growing? And so that’s led me to where I am now and I talked about it at the beginning.

Tech Lead Definition [00:16:46]

Henry Suryawirawan: [00:16:46] Wow. It’s a pretty impressive journey, I would say. There are lots of learnings that you share with us as well, which are pretty good. We can dive deep obviously later, but I want to start with your bread and butter, which is tech lead. You’ve been doing this for, I don’t know how many years now?

Patrick Kua: [00:16:59] Yeah, probably almost 10 years.

Henry Suryawirawan: [00:17:01] Alright. Wow. That’s pretty long. So maybe let’s start with, what is the definition of Tech Lead? I know there is no clear definition, it’s pretty abstract for some people, but is there any good definition from you, what is a Tech Lead?

Patrick Kua: [00:17:14] I’ll caveat this by saying every company is different so sometimes people might call them an Engineering Manager, sometimes it might be a Lead Developer. But for me, the definition of a Tech Lead is a person with a technical background, typically an engineer who is leading a team and particularly responsible and accountable for their technical direction. Sometimes you might call an architect, but these people are typically more hands-on working in a team. So some architects tend to float around, but there isn’t really somebody who is accountable with a team, and really aligning a team and their technical direction. The reason I think that’s important is often a good high-performing team will probably work naturally towards a different direction, but in a lot of cases, people disagree. And the question is what happens when they disagree? You need somebody to make sure that things are moving in the same direction. So that’s the essence of a Tech Lead for me.

Why Pat Is Interested About Tech Leads [00:18:02]

Henry Suryawirawan: [00:18:02] So in the first place, why are you so interested in researching more about this? Because obviously you were doing some kind of tech lead role during your projects, probably in ThoughtWorks, consulting and all that. But what made you decide that you want to dive deep, and deep, and deep, and even come up with internal workshops during your time there?

Patrick Kua: [00:18:19] It’s a good question. And I think like a lot of things, it comes down to your personal experience. I still remember when I was pushed into this role for the first time, is that nobody explained to me the expectations of this, nobody helps me understand, okay, these are the expectations. There was no recognition of where your skills are and also where do you need to grow. I see this repeatedly in so many companies, where I think things like management, there’s a little bit more training in general around this. Leadership and management, there’s a lot of generic courses that talk about that. But the technical lead role, I feel is a little bit special, in that there are these expectations of what somebody should be able to do in this role that A) people don’t talk about and then B) there’s no support for giving people the skills of doing that. Typically people are moved into this role because there’s a gut feel or they’re the most senior or feels like they’re a Tech Lead and they’re ready to be that. But, there’s no discussion and preparation for that.

I guess where the origins of my focus for this is, industry is just really bad at this and I really want to help our industry get better at helping technical leaders move into this role. I published a lot of articles, a book, and a lot of talks about this topic and I hope it really helps people who are transitioning into that role or particularly companies thinking about establishing this role, about how to help people move into this role easier, because I’ve seen too many times when it goes wrong. You get a most senior engineer, as an example, who gets put into a Tech Lead role and suddenly they’re turning around telling everyone exactly how to write code and how to structure code. They’re the dictator type of person and nobody wants to work with them ever again. And they have a bad experience because they think my team isn’t working well or I’m working with poor performing people. They don’t realize they’re contributing to that as a system, and nobody has really sat down and told them here’s a different way of approaching that. It’s a bad experience for that person who maybe gets traumatized and never wants to do a leadership role again. It’s bad for the people who work in the team because they don’t get to bring their potential out. And it’s bad for the company because they typically won’t deliver an effective software project.

If we invert that and give people a really good opportunity to transition into that role with the right structure, for me, it’s the theory that they have the best likelihood of success. There’s no guarantee when it comes to people, you can’t force people to learn. You can’t force people to make good decisions. You hope that they’re good decisions. But if you can support people in that transition, then hopefully they’ll have a better experience, they’ll function better, they’ll build a team that’s aligned around technical choices, and hopefully you end up with a better software project, a better team atmosphere and company benefits as well. So I see it as a win, win, win.

Henry Suryawirawan: [00:20:50] You have been around for quite a number of years. You probably have to work with a lot of engineering teams. What I’m trying to ask is that, have you seen the trend changing to the better, or is it probably much the same than the previous one?

Patrick Kua: [00:21:03] I do believe that we’re getting better, I think our industry is relatively young still, and one of the reasons I’ve published “Talking with Tech Leads”. I think it was 2014. It was that there was nothing really around this sort of material. And today, there’s a lot of books and a lot of talks and a lot more communities around engineering leadership or management. I think one of the really great book that gives people a good insight into many different career paths is “The Manager’s Path” by Camille Fournier, where it outlines what does that look like on the journey to being maybe a CTO and what are the skills and changes in responsibilities along that pathway. In Europe we have a community or a conference called “The LeadDev”, they used to run these engineering leadership type things. I see a lot more people speaking about this topic, a lot more knowledge that is out there and I think that’s really great because the more stuff that we can get out there, the more accessible it is and we just have so many people coming through our industry where more support from different perspectives is always going to be better.

Tech Lead Attributes [00:21:58]

Henry Suryawirawan: [00:21:58] It’s very good to hear that. So you mentioned a lot of things about the responsibility of tech lead. They need to make technical direction, obviously because of that, they need to know some technical skills and also they need to work with people, managing either above or below within the team or even themselves. So maybe can you share with us, what are some of the fundamental skills or good attributes of a good technical lead?

Patrick Kua: [00:22:19] It’s a great question. Let’s start off with the technical side. It’s difficult to lead technical topics unless you understand what people are talking about. So I think this is where there’s a little bit of rebuff, when you hear about people saying, “Oh, I don’t want a non technical manager.” And that’s okay to have a non technical manager if they’re not responsible for leading technical decisions. That’s where for me, the difference of that technical lead is that to understand what a good technical decision, they need to understand what is being talked about from that side. A concrete example is if you were trying to decide of breaking up a service into different types of microservices, somebody who needs to understands how that system is built and the trade offs associated with breaking up the system in a certain way, they need to really be able to understand that quite intimately to understand if it’s a good choice or not. That’s a little bit different if they’re thinking about the team and how that’s actually functioning, that’s a little bit more generic. You don’t need to be technical to understand: Are people collaborating well? Are they avoiding difficult conversations? It’s still difficult to pick, but it’s not so technical. Whereas if you’re trying to choose the right tools and you’re trying to understand how to improve developer productivity, and also maybe set the right example patterns. So if you have a less experienced team, a technical lead might actually be quite hands-on to establish a good first time practices. There’s that technical side of being a good technical lead, is that they need to have enough technical background to be able to do that well. I do like to say that a Tech Lead is often not necessarily the best engineer on the team, sometimes they are, if you’re in a less experienced team, but the tech leader function is not just to be the expert on everything. It’s just impossible to be an expert on everything, but they need to understand enough to be able to lead technical topics.

The second focus there that I want to talk about is then the leadership side of being a tech lead. And this is really different skill sets and this is why sometimes the best engineers aren’t great tech leads is because they have such a deficit in leadership skills. So a good leader, for instance, will know how to engage the entire team to bring in many different opinions and to get the best solution out of that. That itself requires interesting facilitation skills, the right questioning skills, the right ability to bring an inclusive environment that allows everyone to feel safe to contribute their ideas, but then also a way to bring those ideas together, to unify them and then also to get that buy-in from a team. That itself is not a technical skill, that is a leadership skill that you have to develop and practice and not all great engineers automatically have that. And so that’s why a lot of first time tech leads fail because they don’t realize actually you need to draw upon these great leadership skills. You have to listen to people in your team or they’ll get disengaged. You want to make sure that a decision gets made fairly rapidly rather than having conflicting opinions with people who go on under the surface for a very long time.

That’s the second area of that tech lead role is thinking about that leadership perspective. And the way I tend to think about this is a Tech Lead is typically leading within that team. So making sure that there’s a consistent technical direction, caring about technical quality to make sure that there’s group processes and things like that. There’s definitely leading outside of that team. Typically, you’re maybe working with stakeholders to manage expectations. You’re maybe working with a peer product manager to make sure that you’re also aligned to (the) technical direction it’s heading in a way that supports the product strategy or the direction. And also you have to be able to lead yourself.

You touched upon this a little bit earlier in that, a lot of first time leaders don’t realize how they communicate, how they react to something has a kind of multiplying effect. A key part of first time leaders, I do this with a lot of engineers in particular, of helping them build up a little bit of emotional intelligence. To be aware of how they’re actually feeling about something, but also not to let those feelings automatically dictate how they react to something. There’s a skill in noticing and observing how you’re feeling, being able to call out what that emotion is and then also then to not let that interfere with how you decide to lead or how you decide to communicate or handle a particular topic. They are some of the different broad categories of skills that I would expect from a tech lead.

Effective Tech Lead [00:26:12]

Henry Suryawirawan: [00:26:12] It seems like there are so many things for you to be able to be a good technical leader. So I myself personally also struggled during that period in the beginning when I became Tech Lead either like in a project team or in a consulting project as well with the clients. And at times, I feel sometimes it’s a bit difficult, especially if you’re new, how to measure your effectiveness as a Tech Lead. Because you see, there are so many things in play here. For example, you need to know the technical skills, you need to be able to make technical decisions. Sometimes it’s a hard technical decision where people probably do not agree with each other. And also you need to be able to manage people, your team, maybe your stakeholders as well, and yourself internally, maybe imposter syndrome or how to catch up with all these new technologies that people are throwing to you. Maybe you can share tips on how to measure yourself, whether you are good in terms of managing this kind of role?

Patrick Kua: [00:27:00] So one of the transitions I talk about when people move on this, is moving away from what I call maker to multiplier thinking. When you’re a maker, so if you’re thinking about a developer, you often think about “What is it that you have created? What have you produced?” And typically, that’s code or a feature or something like that. When you’re in a leadership role, you need to transition into what is that multiplier perspective. And the challenge with this, which I know this as an engineer, is that you don’t get that immediate satisfaction. So you have to deal with lots of feedback loops, sometimes they’re unclosed loops and that you don’t get confirmation. And it’s often the challenge particularly for Tech Leads is it’s not binary anymore. If you have a function or a feature, it works or it doesn’t work, it’s a yes or no, your build is red or it’s green. So you have these binary habits, but then when you’re dealing with people, organizations, it’s never really clear if you’re done or if it’s good. It’s a little bit more thinking about good enough.

So, I think recognizing you have to move from maker to multiplier mode is one of the success factors. And when you think about multiplier mode, when you think about that success there, when you reframe that is, how much have you done to multiply the effectiveness of your team, then you end up with a broader set of options.

And so one way that you can think about it is thinking about alternative paths of reality, what could have happened if you didn’t intervene? If you didn’t actually intervene in a conversation between two developers who were constantly arguing, and if you let that run for weeks, you could have a lot of messy code and tech debt. And by recognizing, Oh, actually we had a difficult discussion, we had disagreement, but actually at the end of that week, we came to an agreement, that sort of success itself is great. You have to recognize that actually you’ve helped multiply the effectiveness of your team. One of the things that a lot of leaders need to do is often unblocking or creating a path for the team, with all of the complexity of an organization or dependencies or things like that. And once again, it’s like those things, those little wins about unblocking things, these are things you should add into to answer that question about, what have I done to help multiply the effectiveness of that team? Things like encouraging learning and knowledge sharing is a really great example of improving the team’s ability to deal with more complexity. To create a high-performing team that actually collaborates well. That itself is also a great thing to be a multiplier and to measure success.

I think the challenge here is that you don’t have a “you’re ever done” kind of thing. And I think that’s the big lesson here is you have to almost accumulate actions or a series of wins. But it’s not like you’re ever done. You’re never done with building a high-performing team, you have to kind of sustain it. As you evolve your architecture, your system, once again it’s never done. You have to keep it supple, keep it easy to change, make it resilient over time. I think for me, the ultimate test is your team working well? Is it delivering value to customers and to the company? And if you’re doing all of that, that itself is a good enough test. It’s the question of what have you done to help make that happen a lot more effectively.

Examples of Tech Lead Measures [00:29:53]

Henry Suryawirawan: [00:29:53] So, another question around this, especially for me personally, all these obviously are great, but they are abstract at times because there are so many things being thrown at you, for example, number of meetings that you have to go through and you have to go with individuals, checking with them, are they comfortable with whatever that they are doing at this moment, setting up technical directions, which could be either weeks, months ahead spending time there. And also in the spirit of agile, doing this retrospective or personal reflection. Personally, do you have any quantifiable things normally that you would measure, in terms of technical leadership?

Patrick Kua: [00:30:23] So I think for Tech Leads in a team, one thing that would be a measure would be how much time do you spend in the code. And what I mean by that is not necessarily writing code, but even at least reading and reviewing code. The challenges that Tech Leads have if they’re going to lead things effectively is they have to understand what the current state of that system looks like. So it’s hard to understand technical risk if you don’t understand how that system is developing and because we have lots of people typically modifying a system, it never stays the same. The trick here is not to read every single line of code, but to get a good sense of how you delve into areas that you think are risky areas.

Ultimately, a lot of leadership is about managing risk and a Tech Lead is particularly around managing the technical risk of the system. I think one of the best ways of doing that is also delegating things to other people. A lot of first time leaders sometimes feel a bit guilty about delegating, I don’t want to distract my team from doing something. But if it’s done right, you also create opportunities for people to grow. For instance, if I’m a Tech Lead that’s first the only person looking at technical risks, I might then start to work with people on my team to help spread more of that knowledge around, what I look for, how to go about looking for it, and then I might also create a more informal opportunity to say I’m going away on holidays for two weeks. Can you be the person that’s watching out for any big things and to maybe raise this at stand up or raise this with the team that you think is risky? So you’re slowly delegating these things and, for a lot of people, it’s a great opportunity for them to grow as well, because it’s something they’ve never done before. That’s a win, win if you delegate effectively as well. And then that creates more time for you as well. So that’s definitely one of the measures there, how much time do you spend with the system.

The second one is, thinking back to that alternative reality, is that I think a good sign of technical leadership is the lack of problems. So the lack of emergencies is actually a very good sign. Because it means they’re maybe managing enough workflow that risks could be that people just keep quitting, so that itself is a technical risk. And it’s a lack of engagement or a lack of growth, maybe people aren’t growing. That’s a leadership thing to look at. When I think about really good leaders, I think of things happening very smoothly, of course not everything is completely perfect, but I think the number of emergencies is definitely a worry about something going wrong. If you don’t have any emergencies, I think that’s a good sign. You can think about this from a technical perspective of, “How many service outages do you have? “How many builds get broken all the time?” I think a healthy team should break the build every so often, but they shouldn’t be broken for too long. And that’s a couple of measures I would think about good technical leadership.

Henry Suryawirawan: [00:32:50] So some of the typical challenges for Tech Lead, especially those that come from strong engineering background. One of the typical challenges that I see a lot is that being able to let go, for example, a lot of times strong technical background people tend to have opinionated solutions or even like a tech stack whatever that is. How do you think we should overcome that? Being able to sit back and try to let go of all these kinds of decisions, not to be solely on you, as a technical lead, but also giving people the opportunity to make the decision together as a team.

Patrick Kua: [00:33:22] This is really that journey to leadership for a lot of people and I go back to the idea of maker to multiplier mode. As a maker, you’re typically invested in the craft of how you built something, of how that solution was like your solution. When you move to multiplier mode, and I think that’s the hardest shift, is really getting that mindset shift into thinking you shouldn’t be rewarded for what you personally have produced, but really what the team is producing and how they’re producing that. With that mindset of thinking about the team rather than yourself, that’s the kind of journey that people have to go through to step back a little bit. And then, I think the challenge that people have is often getting the feedback early enough. When they’re falling to patterns of behavior, sometimes their actions they don’t realize are actually constraining a team.

As an example, I’ve worked with some Tech Leads in the past who, when they moved into that role, they thought they were doing their team of favor by taking all the hard problems. I don’t want my team to be stressed out, I’m the most senior person I’m going to take care of all the complexity. But then the challenges you alluded to like A) you have a lot of meetings, B) you have to communicate a lot more and get that focus time as much as you do as a developer. Typically, what happens is those people get really stressed out cause they’re trying to do too much. So they’re trying to tackle complexity. They’re trying to do all the other sort of responsibilities. And then the side effect that they don’t see is people don’t have an opportunity to basically tackle more complex problems, which is often a way that people can grow as engineers. As engineers solve certain problems, they want more complex problems or different problems. What a lot of people in that leadership role don’t realize they’re doing is that they’re actually limiting the growth of their people and their team will eventually disengage because they don’t have any interesting work. This is something that people don’t really understand if they’re really focused on themselves versus focusing on what’s better for the whole team. But it is really hard because you have your style of wanting to do things, you want to see your preferences come out.

One of the things that can really help here is a focus on outcome rather than output. Typically, a lot of first time leaders will be focused on how something is going to be done. That’s the output. So the method, exactly how that code might be structured or the service design. What they should really be focused on is really outcome. Did we achieve what we needed to do to help customer problems or have we improved resilience a certain way? Because if you are really doing that, then that’s the real test of leadership versus actually how you have actually done things.

I will say that it does sometimes matter to focus on the how and the outcome, because that’s really coming down to the alignment of the team. That’s something that I do think technical leaders do need to be careful of. You don’t want suddenly five persistence frameworks because everyone wants their own style of writing stuff to a database or a table or something. You need some consistency so that there’s a team sort of feel. So maybe going back to your thing about the test of, “Does the code look like it was written by a single person?”, is one of the things that I typically think about. Or does it look like it’s a team owned thing or is it actually very highly siloed where you can tell people’s personalities based on code. So it’s a kind of anti-pattern.

Henry Suryawirawan: [00:36:21] Yeah. I’ve seen such code before and it was not fun to read that, especially when you travel to another class and, wow, it’s different.

Tech Lead Business Angle [00:36:27]

Henry Suryawirawan: So I noticed when you define the Tech Lead, there’s one thing that I think, in my opinion is not explicitly mentioned, which is the business portion, understanding about the business, about the company, about revenue, how the company makes money. Is this intentionally defined that way? You mentioned also in the beginning that there are many definitions of Tech Lead, some people call it Engineering Managers, some probably even call it CTO. Is this where the place where the focus on business is more towards CTO versus the Tech Lead?

Patrick Kua: [00:36:54] It’s a great question. And I think I didn’t really emphasize it because my expectation is that every good engineer focuses on the business. I know that’s not the reality, but my underlying assumption of a good engineer is that they should also be caring about how their work has an impact of some sort. But you’re right, Tech Leads do need to be a lot more engaged with the business and that sort of escalates. For me, it really comes back down to the outcome. What are you really trying to optimize for? What are the constraints that you make decisions by? If you’re in financial services, you need to think about things like regulation and how you build software will change because of that context. The leaders have to be really aware of what that business outcome is, but also the current priorities of the business. In COVID times, some businesses are a lot more cash straps because of their business model. That means that actually you probably need to be very cognizant of how that comes into your team, training budgets you probably can’t use during that time, or you have to think of ways of cutting costs as a business. And all good leaders will also be thinking about how their work contributes to the bigger, broader goals. But I also challenge that every good engineer should be really focused on that.

That was one thing that I learned from agile very early on, which is bad engineers that come up with technical things to do without being able to link it to business value. To me, the heart of every good engineer, and that applies equally to Tech Leads and all the people in the leadership chain, should be really focused on what is the business outcome and value that their work is doing. And I can think of, now that you mentioned it, so many counterexamples of Tech Lead who go, “Ahhh, I just want to play around with X tool”. So you’re coming up with some reason, but there’s no business value out of it. And typically, they have some fun, but then the business turns around and says, “Hey, what have you been doing for three months? Why are we doing this? No, you’re not going to have this anymore.” And then the team gets disassembled or something like that. Everything always has to have a value of some sort, and leaders and engineers really need to be focused on that.

Henry Suryawirawan: [00:38:42] Thank you for your clarification. I really like that a good engineer needs to care about the business and the impact they are bringing to the overall growth of the company or whatever business measures that they are measuring.

N26 CTO [00:38:51]

Henry Suryawirawan: I think this is also a good segue to move to your next role, which is becoming a CTO at N26. And you kinda mentioned in the beginning, you want to move to a position where you have more accountability, and also have more responsibility in terms of decision-making , aligning the whole team. It’s also an interesting journey where you keep mentioning about scaleup and there are many companies who aspire to scale as large as possible as the business grows. Can you probably tell us, during that time, what are some of the first things that you did as a CTO, which was still a small size around 50 people you mentioned. What are some of the first things that you did?

Patrick Kua: [00:39:26] So before I talk about what I did, I want to talk about my thought process behind it, because that’s something that a lot of people don’t get insights into. Firstly, every CTO is different. The number of types or archetypes and situations for CTOs are even more type of us than probably the types of tech leads that you have. I think the name of a CTO is one of the most poorly named titles as well cause it’s a bit of a placeholder for, you have some sort of technical responsibility and you just make stuff work. In some places it’s a lot more strictly defined. For example, it might be a bit more R&D, technical strategy about 3-5 year roadmap. Other people might be about the current technical direction for the platform. There’s some basis to it around the technology and that team, but just be aware that actually the role of a CTO is really different.

When I came into N26, it was one of the things I was trying to get an understanding of is, “What’s the focus point for this role? What’s the thing that will deliver the most value?”, is the question that I had. That’s why it’s different in every situation, because when I left, for instance, we would have a different set of challenges, because the organization has grown and evolved as a result.

One of the things I encourage leaders to do is to take stock of the environment. Understand what your environment is like before you make decisions. So I don’t believe in cargo culting, even though it worked in agile fashions, I didn’t really come in and say, we’re all doing Extreme Programming. I didn’t really enforce these kinds of things. I really wanted to understand what was there in that environment, what was already working really well and then also what were constraints or problems or challenges that were in the current environment. So my philosophy to management is you don’t need to manage people, you need to manage the environment to bring out the best in people. That’s what I was looking for. I really believe that good management is dealing with the topics that people recognize, but they don’t maybe feel empowered to address.

As an example, as we were growing and scaling, one of the topics that was coming up was thing that was starting to fall between teams. We had some teams that had ownerships of product areas, but then you started to notice, maybe the interfaces or a service bus or something between the teams started not to have a strong sense of ownership. And so there was a lot of conflict around that, there was a lot of frustration. A lot of that came down to lack of clarity of maybe who’s accountable or how to go about solving this. And so I see that as a management problem of the certain structures that you’ve got at the moment are leading to this, and you need to think about ways of tackling the constraint of that problem.

I was kind of looking at what are some of these problems? One of the big ones was obviously this ratio of product engineering to non product engineering people. To give you an example, product engineering was 8% of the entire company. We had about 450 people in the company, of which 35 people were product engineering. Even if you just asked 20% of those people for something, you have no capacity to actually build that. That was a huge challenge, which I realized I needed to work on both in recruiting, also retaining, and then looking at that recruiting process.

At the same time, one of the next sort of challenges that was going to happen was as we grew the organization, particularly the tech organization, there’s the old saying of “what got you here, won’t get you there”. What worked for you at a certain scale, won’t work for you at another certain scale. That’s true as a leader. What works for you as an engineer, won’t make you an effective Tech Lead necessarily. So you need to keep thinking about these transitions and then also thinking about what’s a good fit for the next transition.

One of the things that I realized is as we moved from 50 people, and we got to 150 people, you just simply can’t get everyone into the same room. In a startup mode, people are just used to talking to each other face to face. They grab somebody that they trust, they go into a room and then they make a decision. And that habit works okay at a certain scale, but then it starts to break down. As we were growing, I was also starting to look at how do we think about processes or structures that would help us scale. And particularly as we started to go distributed, as we open up an office in New York, as we opened up an office in Barcelona, these are very different communication and cultural challenges where if you’re all centered around one headquarter thing, it’s natural that people just focus on headquarters and they forget about satellite offices. And this is something that I basically tried to really invert by really trying to build up a culture of inclusivity to make sure that all the other offices were treated as equals, versus a secondary or third kind of office.

The other thing that I worked out is that I needed to work out how to scale myself. My focus as a leader is looking at: How do we be more productive as an organization? How do I multiply that? And there’s only so much that I can do. That was the other side of what I was going to do, which is what does my leadership team look like? How does that cascade into the organization and how do we support our team to do all the things that we need to have? Then there’s this hiring pipeline as well, getting that all up and running, onboarding and getting the structures there in place. That’s the story of what I was focused on when I first got there and some of the areas that I was really trying to address.

Hiring Engineers [00:44:03]

Henry Suryawirawan: [00:44:03] Thanks for sharing that. I’m interested in this ratio, like way offside, for example, only 8% product engineers within the company. And I see this quite a few times as well, especially in small startups, for example, they only have typically few engineers trying to build the product, and then you have a big number of people at the management who are throwing a bunch of features for them to build. So in the first place, how do you actually convince the management to actually see the investment in hiring more engineers is worth it, because maybe in some cities, it’s pretty expensive to hire engineers. So the more you have them on board, obviously the more expenses that you will have. How do you convince them? That’s the first thing and the second thing is about when they agree, how do you actually hire? Are there any things that you follow or framework for hiring people to be able to reach that scale?

Patrick Kua: [00:44:49] It’s a great question. So let’s first tackle the first one, how to convince people. So in our case, it was not so difficult to convince people. Part of it was to present the industry metrics to a certain degree. Now there’s no exact number, but 8% is really, really small. If we were in a logistics type of business, like Amazon or something with delivery, then of course I wouldn’t expect a 50-50% ratio of a company to be engineers. But we were a more digital firm than something that has a lot of logistics or hardware type stuff. So just giving people a sense of, okay, here is how other companies are versus what we are, that’s definitely one thing that definitely helps just in terms of industry benchmarking and just getting a sense of what is an average size.

The second thing was really trying to focus on teaching our leadership team about theory constraints. I did this a lot as an agile coach and working with product teams is helping people understand adding people to a non bottleneck doesn’t really actually help the system overall. Typically the area that happens when you’re dealing with the digital product is the engineering side. I kept saying everyone has ideas, you’ve got ideas, I’ve got ideas, we’ve all got 15 ideas. That is not the problem, we don’t need more people that generate that. That’s not the thing that is actually generating value. I also walked people through Little’s Law, which teaches people that the longer the queue is, the more slowly the overall system will go, because everyone is fighting for their pet project, they want some time, but it’s actually the focus on the most valuable thing for the business right now. Helping people understand that and how the system works overall, helped people really understand for us to actually be able to achieve more, it doesn’t really make sense to hire more people with ideas, we actually need to hire builders. So just getting a good sense of that and then getting a good ratio.

Now in some businesses, and I think this is important to understand, is that I think it’s actually also bad to have too many engineers too early. In a startup where you’re still discovering product market fit, it may make more sense to have more salespeople to try to really make sure that there is that interest there to hire more engineers. Because I think, another bad thing that can happen that I’ve seen in some companies is that you have too many engineers with not enough to do and they get bored and they invent things to do which aren’t actually delivering value. So you can go the other way as well. That’s where the business value focus is really important for leaders is to know which context you’re operating to really understand what is going to bring the business forward the most.

But it was pretty clear when I came in that we had so many different things that we couldn’t launch. We wanted to launch new products, we wanted to launch new markets, we wanted to launch so many different things, we would have to keep changing things that we already had. But like, who are you going to get to do any of this? It’s the same people. We obviously need to change that and deep down people put two and two together. With business people, they don’t really understand that maybe the interconnectedness of software. They have a little bit more of sometimes a factory mindset of inventory, I can produce more supply. If I have more supply, I can create more stock. I didn’t have to go too much into the depths of why software is more complex that kind of stuff, but simply the fact that we don’t have enough people is definitely affecting our output at some point. And then it’s up to me as a leader to make sure that they’re structured well so that it can be as productive as possible. That’s the first part of your question of how we convince people.

The second one that you asked, which I think was, how to hire people. I think this goes back to the first question of thinking about first principles is what are you hiring for? And, what does that mean? When I was thinking about hiring, one of the things I write being about a leader is that you get to create the environment or the culture that you have. And so for me, coming from an agile background, I really want to build a self-empowered, collaborative team environment. And so naturally I want to look for those things during the interview process. Now with hiring, it’s challenging because it’s challenging for everyone to hire. One of the things I was asking myself is what is it that I can offer as an opportunity for people to grow or interesting problems for certain people, so that I can attract people who want to work on those types of problems. For instance, working in a FinTech bank, I’m not going to attract somebody who wants to work on a music product like Spotify. But there’s some interesting things of either the scale up challenges or where your business is now that provide growth opportunities for people. So I think, trying to distill “what is your culture” down to distill “what is it that your environment can offer right now”. And then also to communicate that out well, is an important part of hiring. That’s probably where I was doing quite a lot of talks to let people know, we are hiring here’s what we’re about. That’s definitely one of those key areas, we ended up building a blog to sort write a lot more about that. That’s why you see a lot of engineering blogs is that people want insights into how you build things. Is this how I like to build stuff? There are companies that are a bit more hack and slash, and there are other companies that are maybe more robust. By giving visibility or transparency of that, then people will naturally get a bit more attracted to that as you go. So I think that’s the attracting side.

And then when you think about the hiring process, I think is really key because this is something that we revisited a number of times as we grew. It was really trying to be clear about what traits you’re hiring for. As an example, I don’t really believe in the white board exercises or algorithmic tests, because often they don’t really connect into what people do on a day to day basis. When I work with people to build a hiring process, the first thing I’m thinking about is A) what is expected from this role? So what are the skills or experiences from that? And then B) what’s the best way of getting an example of capability around that, either through a simulation, either through talking through past experiences, or seeing some of those skills in action. For some of our more senior leadership roles, for instance, there would be a case study where they would have to talk about how they would handle a certain case. For programmers, they would be dealing with a specific problem and then they had to show code because we wanted to see some of that capability. But I don’t believe in doing things for the sake of doing it just because other companies do it. Once again, it really has to come back to what do you get out of that and what’s the best way of doing it.

The other thing that I really think is very important which a lot of people forget during the hiring process is remember it’s a two-way street. People are interviewing you and your company as much as you are interviewing them. That’s a really important thing to keep in mind is that, for some people it may not work out in this current situation, but in the future, the opportunity may align. Also, you have to train people who are going to be part of that process to help them understand they’re testing you as much as you are testing them. Are these people who I want to work with in the future? Can I learn something from these people or are these people fully arrogant, overthinking they’re the best and brightest, and they’re trying to shame me because they want to show you how good their knowledge is. So that’s something that you have to do a lot with, people who are maybe first time interviewing as well, because it’s a skill. And you have to really make sure that people are trained for that as well.

Henry Suryawirawan: [00:51:06] Thanks for sharing that. I think some of the good tips for those of you who are hiring as well.

On Balancing Responsibility [00:51:10]

Henry Suryawirawan: Coming back to this CTO versus Tech Lead, as you mentioned, all along in the last few minutes, your responsibility tends to change when you are at the CTO level. So you have the public facing part of you, you have the hiring part, you have the internal with the business, you have also within the engineering team, what kind of direction, what kind of culture that you have to build? So obviously, we only have 24 hours in the time, right. So how do you balance all this with more and more responsibility as you climb up the chain in the leadership?

Patrick Kua: [00:51:38] The art to this is how well you can build a team and how well you can delegate. That’s really the essence of effective leadership. If you think about Satya at Microsoft, he’s not a person who’s going to be writing every single product in Microsoft. He just simply doesn’t have the time. But the reason he can run something like Microsoft is he has built a good leadership team and management team where he can trust and delegate that. The art of any leader is knowing what parts you can play in that sort of bigger picture, but also what’s the right people that you can grow and hire. Sometimes you can grow them internally and promote. Sometimes you may have to bring in those skills externally, and then just find a way of letting them work together as well. The essence of it is knowing how to delegate something, knowing how to give people responsibility and then also to manage that system so that people can work well effectively, in that overall system.

The hardest thing for me as a CTO of N26 is everything was changing and my role specifics probably changed about six or seven times throughout that journey. Very early on, I was deep into our sort of system architecture, really trying to understand how our teams were building things. But as I grew and hired people in to take care of certain areas, then I felt I could step back. Obviously I want to dive in to get some confidence every so often. But, if everything’s running smoothly, so once again that lack of problems, then I can think about different types of challenges and what’s the next most valuable thing I can focus on, that can unleash more, or multiply more of the people that we have, or unleash more value to the business.

Target Operating Model [00:53:05]

Henry Suryawirawan: [00:53:05] I saw one of the blog posts that you wrote, few years back probably, or even one or two years ago. It’s about Target Operating Model (TOM) . I think it’s very interesting write up and the framework, how it works. Would you be able to share what is a TOM and how do we actually use it?

Patrick Kua: [00:53:20] So, the purpose of the TOM is to be purposeful in organizational design. The essence of it is to be explicit, to be transparent around what an organization looks like. And I talk about it in the context of not necessarily the tech organization, but you could use this concept as well if you are a CEO and you’re thinking about the overall organization. As I was describing our journey going from 50 to 350, over 2.5 years, a lot of things needed to change along that way. And so I knew that, early on, I wanted to be intentional about how we did that, and that was the purpose of introducing this Target Operating Model. When we were 50 and then I said in the next year we’re going to grow to about 150 people, but this means that a lot of things are going to break and so here is what I think is a good structure that will help us scale to this next size or scale. So that’s the idea, it’s the target, so where would we like to be? And it helps people move and understand that. The goal there is it’s not supposed to replace product roadmaps or technical roadmap. So it’s about the, how we work together, the structures of how we communicate or areas of ownership. So that’s the operating side of the Target Operating Model. It’s a model, so it’s not a perfect representation of reality because things will never be perfectly defined, people don’t fit into boxes, but it’s really a tool to have conversations around.

As an example, when I first introduced the Target Operating Model, we were moving from a couple of product teams to many different product teams. One of the things I wanted to do was introduce an Engineering Manager role, and define that role that was going to be new because we had Tech Leads and some of the responsibilities would shift. So Tech Leads were responsible for people management. I would argue that some of our Tech Leads weren’t the strongest at people management and they often preferred technical topics. And so that was one of the areas that came up as I was observing the environment is that we didn’t have a lot of skill or capability, or maybe time to focus on actually building high-performing teams and actually building individuals so that their team would be stronger. When I introduced the Engineering Manager role, it’s where I wanted to introduce a little bit more of a team focused Engineering Manager role and the goal would be that they would work with Tech Leads, so they didn’t have to worry about the technical direction. They would delegate and work and partner with the Tech Lead, but then somebody would be focused on building a high-performing team, building good team processes, working agreements, making sure that individuals got good one-to-ones, had growth plans and how that all fit together as well. That’s an example of in the Target Operating Model of saying, okay, we’re going to have these teams and we don’t have all of these teams today and we don’t have all of these people, but we’re going to have these nominal teams with these roles and here’s how they will all fit together.

One of the other roles that I started to introduce was also the Director of Software Engineering. When I came in, I inherited, I think it was something like 12 direct reports. And I knew by the time that I was hiring, I was going to end up with probably about 17 or 18. I was like, this is impossible. I promise everyone, I would give around at least half an hour every fortnight of one-to-one time, which I did for, for the entirety. But once again, the things that worked for you at one stage will break down at a certain scale and that’s why I got the Director of Software Engineering in, is that Engineering Managers will report to the Director of Software Engineering and then Tech Leads at the time would report in to me, and then that was enough to get us to the next stage. That was the basis for our hiring plan, it was the basis for our whole organization to really come together. We would naturally take feedback as things were evolving to see how things were improving.

As our organization got bigger, naturally the model starts to maybe break down or you start to say, okay, we’re noticing different problems. When you have at that time we had probably like 12 or 15 different product teams, you then needed a way of thinking a bit more conceptually about not just lots and lots of teams, but maybe a product area with lots of teams within that product area. That then led to another evolution in our Target Operating Model, where we introduced another construct that solved problems that we had, which was how do you think about the overall organization without having to go to every single team? And so we decided to have what we call product groups, which were like mini product areas and each group would have a series of teams in it. If you were new to the business, you didn’t have to worry about how teams were broken down in say payments area, that was just a product group of payment stuff. And if you interacted with them, of course, you would want to understand which team is responsible for what, but for most simplicity, you didn’t have to worry about that, unless you had to be a lot more involved.

So the Target Operating Model, we went through three iterations when I was there. And the goal there was really once again to help us orient as an organization about how we work. So we didn’t just say, we’re adopting Spotify, how they work because we have different problems. We had different problems at different stages and the Target Operating Model was a way of creating common understanding around new roles, responsibilities, and how they all work together.

Chief Scientist [00:57:58]

Henry Suryawirawan: [00:57:58] So towards the end, you also evolve in terms of role as well, from CTO you become like Chief Scientist. I haven’t heard a lot about the Chief Scientist role in a startup. Can you share with us what is a Chief Scientist role and what made you transform to become this role?

Patrick Kua: [00:58:12] So once again, I think it comes down to that thinking about what you do, thinking about what the business needs, where your skills, capabilities, interests are, and what brings that forward. The reason I created this role and stepped into this role is as we were sort of growing, the role of what they needed from a CTO was a little bit more operational. This was really about keeping delivery going with a product roadmap. It was a lot more about metrics and reporting, and that’s not really interesting for me. It’s not something that I enjoy doing, I can do it, but it’s not something that energizes me. And the thing that really drives me was growing other people in the business, in our technical team, and also seeing what’s interesting there and amplifying that. And so that’s why I think about this Chief Scientist role is it’s about going through our organization and sometimes it might be just working with a team for a bit to say, “Hey, that’s an interesting service that you’re building here, does other people in our business know about this? We should talk more about this because this is actually something that can amplify that. I know other teams have problems with it.” It’s like going through and seeing ways that you can amplify and spread knowledge across that. So it’s scientist in the way that one maybe observes the system and then tries to maybe design experiments or hypotheses from observing that system and then try to improve that. During that time, I did a lot of mentoring, helping a lot of people grow, a lot of knowledge exchange around what’s actually going on. And so I was less attached to the operational side of the business, which is the phase of where we were at, and it wasn’t so interesting for me from that side.

Tech Lead Resources [00:59:38]

Henry Suryawirawan: [00:59:38] Before we move on to the last question, any resources or probably tips for those aspiring technical leaders or seasoned technical leaders out there? What can they learn from or where do they have to go to in order to level up themselves?

Patrick Kua: [00:59:52] So I’m going to do a bit of self promotion here. There’s a “Level Up” newsletter that I actually run. It’s a weekly newsletter, that’s levelup.patkua.com . And it’s a leadership, technical leadership newsletter that focuses on leadership topics, technical topics and organization process topics. So three areas I think all technical leaders should think about regardless of what level that you’re at in an organization. I send that out weekly, that’s definitely something that you can sign up for. There’s a lot of great material out there. So even if you just Google for things, you’ll find things popped up on YouTube or there’s a lot more websites that are now producing content. In terms of books and things like that, there’s endless books that you can list out. Actually I just published a blog post called “Book Recommendations By Engineering Leaders” which I think Henry can link to later, and that links off to like tons of books where people can find out more about technical leadership or management type of topics.

Henry Suryawirawan: [01:00:42] Thanks for sharing that. Do subscribe, everyone, to the “Level Up” newsletter. I am one of them. Every week, we will get a lot of articles that Pat found interesting. I don’t know how you curate all this. It seems like a lot of time. Reading Twitters, reading the internet, medium blogs, or whatever blogs that you can find. So it seems like a lot of curation being done, very thoughtful as well. I’m sure that if you subscribe, you will learn a lot from the newsletter as well.

3 Tech Lead Wisdom [01:01:05]

Henry Suryawirawan: So Pat, thank you so much for your time. As usual, a norm in this Tech Lead Journal episode, I would like to ask the guests to share their three technical leadership wisdom. Would you be able to share your technical leadership wisdom?

Patrick Kua: [01:01:18] Yeah, absolutely. I think, tip 1 is, if you are going on this journey or thinking about going on this journey, you have to make that shift from maker to multiplier. It’s not easy and you’ll fall into habits. Making that mindset shift is a key to being effective. Sometimes you’ll move between them because as a technical leader, you’re probably going to be writing some code at some point, so you’ll still be creating. But the value that you produce is very much in that multiplier side, so focus on that.

Second tip is, I talked about “What got you here, won’t get you there.” The skills that made you successful as a maker, aren’t necessarily the skills that will prepare you for being a leader. So if you’re thinking about this, you’re actually in a great place because you’re not yet accountable for it. You can practice developing these skills, learn more about these, and then find out ways to practice this safely before you suddenly find yourself having to use these skills. Understand the leadership skills, understand broader system and architecture skills, things that are bigger than maybe what you might encounter in your job, if you’re working as an engineer. So that’s tip 2.

Tip 3 would be to find people that have done this role before that you’re interested in. I think talking to people, reading about people’s stories is a really great way of learning from each other. One of the things that I really appreciate, and you touched upon this cause I’ve been doing this for 10 years, is that you’re never really done. There’s no perfect single way of doing something. You can always learn something from somebody else, some interesting insights, some interesting anecdotes. And if you start to talk to people, you’ll start to build your toolkit - is how I often describe it. It’s like the bottomless bag, you can keep adding more things to your toolkit, cause it never gets full. You can always learn something about how other people do it, it doesn’t mean it’s right or wrong, but it’s something that gives you more breadth to draw upon when you’re in a different situation and it can give you a different insight. So that would be my three tips.

Henry Suryawirawan: [01:02:59] Thank you for sharing that. I’m sure your “Level Up” newsletter is one of those toolkits that you can find, it keeps growing and growing every week. So thank you, Pat Kua, for your time. I learned a lot myself and I’m sure all the audience here will learn a lot from your experience and your knowledge as well. And for those of you who are interested to sign up with Pat Kua on “Tech Lead Academy” and “Tech Lead Workshop”, I’ll provide the links later on. Thank you, Pat Kua and hope to see you again in future episodes.

Patrick Kua: [01:03:22] Thanks very much for having me. It has been a pleasure. Thank you.

– End –