Talking about ideology of Tech Leads with Patrick Kua

Patrick Kua is the Chief Scientist at N26. He has authored/co-authored the books Talking with Tech Leads, Building Evolutionary Architecture and The Retrospective Handbook. He runs the newsletter, Level Up, which delivers curated news for leaders in tech. He likes to groom technical leaders and has given many conference talks on this topic.

We got a chance to interview him and understand his views on engineering management. Here is a transcript of the interview with him, edited for brevity.

Can you tell us a little about your journey so far?

I have been working in technology for almost 20 years. I was working with ThoughtWorks for about 14 years. That is a significant part of my career. I joined N26 as the CTO and transitioned to a new role as chief scientist. I described my role coming into N26 as a sort of shakeup CTO, so really helping us move from the early-stage startup into the scale-up. It's now been about two years, and we've grown the tech team by nearly seven times from about 50 people to more than 350. It was really about addressing the scale and balancing it.

My passion is about growing technical leaders. Your interview series is an excellent format for that. I have authored a couple of books, including Talking with Tech Leads. I also started a newsletter called 'Level Up' as well, which is about helping technical leaders stay in touch with leadership and technical and process organisational topics related to modern engineering companies.

What is N26?

N26 is a FinTech bank, and we have a German banking license. We operate as a consumer bank so that people like you and I can sign up for a bank account in Europe. We have not only launched in the Eurozone, where the currency is the Euro, but we have also launched in the UK, where they have different banking regulations and currency. We also launched into the US this year, which is a first for us, and it is a different region with different banking regulations even more separate than those the EU regulations allow us to operate in the UK.

What made you pick N26?

It's interesting when you move from a consultancy into a permanent company because one of the interesting things about a consultancy is that you are always working through other people. But one of the reasons I decided to come in early in N26 was that it was in the first part of the growth stage. The founders were both business people, but they needed someone who could understand the technology and who could help them to grow the tech team sustainably during the hyper-growth.

Therefore, when I joined, it was all about having an early impact. When you are dealing with a team of about 50 people, it means that you know everyone, right? It also means that you can put the right structures in place to allow the team to perform well, given that there are a lot of things that you cannot control; for example, the timing of when people will join and how hiring will progress. It is all about trying to change the culture by keeping the right parts of the start-up culture, but also shifting the culture that is not growing. The aim was to achieve face-to-face communication and to bring everyone together in a single room, from multiple disciplines, floors, offices, locations, and time zones. It has been fun to play a part in shaping and influencing the business in this way.

What does your role "Chief Scientist" mean, and what are your top challenges?

I think the first thing is to know that every CTO is very different. Even my responsibilities as a CTO have shifted several times along the journey. One of the things I believe in is that as a leader, we should focus on where our strengths lie. There are a couple of different things that I enjoy doing. I like to talk about what we do here, to teach people, and that was one of the things that my new role would allow me to focus on by giving up some more of the operational day to day activities. In the new role, I spend a lot of time travelling and talking about what we do without having to worry about catching up on all the things that I've missed out from the business.

When I transitioned to the new role at the time, I started to realise that I was spending much more time with other operational departments, rather than with people in tech around technical topics. You would think a CTO would typically spend a lot of time talking about technical architecture and working with technical teams. But due to the state we were in at that time, it was a lot more operational and helping the rest of the business understand how to interface with technology. That's not necessarily something I enjoy doing. I can do that, but also, it's the question of is this something where my talent is used up? We put the director or VP engineering into the CTO role because it's a very operational CTO role where the company needed. Then we didn't want to have two CTOs, so we named my role, chief scientist, which allowed me to focus on growing and mentoring technical people. I could spend a lot more time responding to technical RFC, some of the scaling practices we implemented, etc.

What is the advice you would give to people who are aspiring to level up to directors or VP of engineering?

I think the first thing is realising that a technical leader and an engineering manager are different roles. People often think about these things as a promotion, but these things require significantly different skills. The skills don't often overlap very well with a lot of skills that you develop as an engineer or an individual contributor. I often talk about a trident model of career development these days.

One is a technical leadership path where people are still drawing upon their technical experience leading to technical topics. Let's take an example of aligning on an API standard across the organisation. That's a very technical topic, but it requires leadership to influence lots of groups of teams. You need technical understanding, but you will be drawing a lot more while leading general leadership skills, influencing communication, negotiating across the spectrum, and ensuring that everyone feels engaged.

Another path is the Engineering Management course. I described this management track as it is with regards to dealing and interfacing with organisational policies and guidelines. You will encounter things like development processes, hiring procedures, head counting, budgeting, forecasting, and also connecting into the planning and communication cycles. You have to ensure that teams have the right context about priorities and guarantee that we are capable of delivering them. You have to confirm that everyone understands the purpose of the work that they do, so they can contribute to a more significant cause while warranting that the structure is optimum. I feel that good managers will focus on managing the system and not the people; they lead people but manage the system in which people work. These are different skills from what you develop as an engineer.

And the last path would be progressing as a specialised technical person. This is the direction where you have people who are aware of particular frameworks and can debug hairy technical problems in the tech stack. You maybe don't want them leading or managing, but they're very good at what they're doing at a very deep experience level.

I described those three paths as the Trident model, but particularly the technical leadership track and the engineering management track really require very different skills. To come back to your question, this is a lot about the advice of making sure that people start to build those skills. Because when you're in that role, you'll realise you need to use those skills, but you may not have developed them when you need them the most.

What are the steps you follow to solve a problem?

The first thing is trying to understand the priority: Is this an emergency? Or is this a long term task? I think then, depending on the type of impact, if it is an emergency, you probably have to deal with it. But hopefully, it's not always an emergency. Then you need to think about who are the right people to involve to ensure that as you tackle it, you have the right level of engagement and buy-in.

A concrete example would be, as we've changed the operating structure of tech teams, you know, you want to engage people throughout to make sure it's solving the problems that people have. People resist change often because it's coming from the top-down, but people don't understand how it's helping them. But if you're trying to address what are the problems that teams are having, of course, people are going to buy in a lot more. It's the same thing when you're dealing with a technical topic; it's often where maybe there's too much autonomy across the organisation and too much inconsistency. You need a voice to come in to help align, but you need to bring in the voices from those different perspectives to understand what are the trade-offs, and different approaches of how you might solve it.

I think one of the other ways I'd consider this is that I know it's the trap of every technical person to fall into a solution and then to push for that solution. What I've learned, particularly during scale, is trying to make sure that everyone understands before you push a solution— What is the problem that you're solving? What are the constraints? What are the things that you're trying to optimise?—before you start to jump into a solution. I think all technologists want to solve the solution. Once they've got it, they want to push for that solution. It often ends up in frustration, because it is either 'Yes' or 'No,' either having a solution or not having a solution. Often people talk with each other at cross-purposes because they do not share a common understanding of what the problem is, and they also do not understand enough about the context in which the problem must be solved.

If you are trying to align with a certain standard, maybe it will not always be the same standard; perhaps it will get you through the next six months until you decide that you want to experiment with something else. This will then change the technical solution that you decide upon.

What do you think of data-driven engineering for gauging a team's health in terms of productivity and velocity?

I think it is vital to have data. I think it is quite interesting because even though I am a big fan of 'Agile,' we still need to have things like ticketing systems. There is a lot of interesting information there that can be used to provide data. However, having data does not necessarily mean that there will be implications or decisions. I think these things should help the engineering management, in terms of trying to understand the signals, but I do not think that it will necessarily replace the conclusions about precisely how the team works.

I like the analogy. Adam Thornhill has this book, Your code is a crime scene, which talks a lot about mining software, looking at git history, and around potential theories. I think what's interesting is that these data elements give you hypotheses or theories. But there will be a disconnect because of what people think or how they interact with each other doesn't always make its way into the digital tools. I think it's fascinating to understand what tools can provide you with. I'm a big fan of things like sonar and getting metrics. But once again, I don't believe that metrics replace human values and belief systems. I think that's where metrics are an additive rather than a replacement.

How do you think an ideal team leader should operate?

I believe there is no template model. I encourage everyone to have a leadership style. It is a hard thing for a lot of engineers as we get trained to a single correct answer. But I've learned through many hard lessons that every person is different. Any combination of people is different, and any combination of people in a different context is also different, which leads to different dynamics.

If there's any common trait that I try to encourage in an effective team leader, that is being adaptive in how they lead. In times of chaos, there might be a need of a more directive style of leadership, or where you have a more junior team having more guidance, but then that team will learn and grow and develop their own experiences and would want more freedom and autonomy. So that leader will have to adapt their style over time. I think in terms of how an effective team lead can act, the team lead should be conscious that the current context of the team is dynamic and should be able to adapt their style to what they believe.

I'm a big fan of nudging towards more delegation and more autonomy because that helps everyone grow, it gives people more freedom, and has more engagement. But you can't go from directive to complete delegation. You need to take people through the journey. So I'd say the common trait would be very adaptive and aware of what the current dynamics are of a team, and to understand what is most appropriate.

What motivated you to start the "Level Up" newsletter?

It is one of the interesting things that I did when I was a CTO; I used to send a weekly email to the entire tech team. I had worked in natural environments for a long time, and one of our core values here is transparency. Part of me was trying to help people understand the context of what I was hearing and seeing. The bigger that a C-level person gets, the further away he or she gets from what's happening. This email gave me a chance to reflect on our context and what I was hearing in the business—maybe challenges or things I was excited to try. I also highlighted and celebrated things that the teams had been doing. At the end of it, I always tried to include some learning links that were related to what I'd heard about, estimations, and other things.

When I stepped into my chief scientist role, I stopped sending out those weekly emails, but I still got requests from people for them. It was harder for me to send them weekly because the effect of not being operational and connected to the business on a week-to-week basis was that I didn't have as much new information to share weekly. I got a lot of people saying that they enjoyed the learning articles at the end.

In my new role, I consume even more information than what I was previously consuming. The newsletter was my attempt to work out how can I make something equivalent, share it with a broader community. That's kind of the origins where the newsletter started. And it reflects my mental model about good engineering, technical management. I don't expect everyone reads every single link, there's a lot of information there, but I think if it helps somebody in a different context with their problem, that's perfectly fine. It's not always going to be completely relevant, but coming across something I hope that they would enjoy.

What does it take to manage the newsletter? And how much time goes into curating it?

I've had to set up new habits for this. I have a system of consuming a lot of information, particularly as I travel. So feeds through Feedly, Twitter, general web browsing, all of them tend to get saved into a 'pocket', which I then synchronise before I go travelling. I tend to consume a lot of that when I'm on the go. I'm not a podcast listener as I can read information quicker than I can get it through listening. That's why there's a bit of a bias towards articles versus videos or podcasts because I can consume them a lot quicker. As I'm consuming things, I think about what people in similar engineering leadership roles would benefit. So I categorise the articles into three categories: leadership, things in general, and what's happening in the tech industry.

Curation is a bit piecemeal because I build it up throughout the week. But I tend to set aside at least two hours in the end. I read an article, and I try to write my summary—that's a useful learning technique as well to try to work out the essence of something. At the end of the week, I'll then spend at least two hours revising, summarising, and then double-checking some of those links and content.

How can an engineering leader create an environment that helps different teams orient to the business goal?

I think there are a couple of different things there. I always go back to Dan Pink's 'Drive'. Purpose often needs to come from the product. What are the current product parties, what's most important—impactful—to the business? Even in IT initiatives that improve engineering, we try to bring a single source of parties to make sure that we can have a clear understanding. I think for us, it's about making sure that every team or group has a purpose of what they're working towards for specific periods. We do quarterly planning, and then we expect product people to break that down into weekly or fortnightly sprints, and then for them to understand what they're working towards. I think there's a purpose behind it, which represents the key.

We've always tried to think about how we can maximise our autonomy and alignment. Autonomy gets harder and more complex with the advancement of the product. It is evident that, as you have things like dependencies, you also have coordination. But one of the tools that I introduced very early on was the idea of a target operating model, which helps us understand the ideal picture of where we'd like to be in a specific timeframe. Now, this is hard to do during hypergrowth because you can't predict exactly where you're going to have all the people and where all the roles will fit. Therefore, some groups will be missing, maybe some leadership roles, or you will have too many backend engineers or frontend engineers, but the model helps us understand the direction we want to take. Then, we try to have each group focus on a domain and have as much autonomy within it as possible. The idea is to achieve an inverse Conway's Law: high cohesion within a group, but low coupling between groups. That's the goal we tried to reach. And that's very much dependent on the domain in which your team is working. As our organisation is growing, and as a product evolves, we have to keep revisiting that to minimise coordination costs and maximise autonomy.

There's been a lot of that element to that. I think the other side is communicating from the company perspective about what is expected. That could be defining a high-performing team? Overall, as an organisation, teams are expected to be self-empowered; they should be delivering towards their goals, then they should also be not necessarily cutting corners to do so. So there are quality and process standards that we also try to help articulate. We're also trying to scale them. It's not perfect all the time, but I think it's this iterative process of continuing to improve part of that.

When you're dealing with the difference between a team lead and an engineering lead, you have to understand that when you look at this from a perspective, you'll have different stages and different constraints and different teams. One might be about the staffing imbalance or the skill imbalance. Another team is working out well, and they've got all the perfect skills, but maybe the issue is around working well together, like cohesion and team brainstorming. Another team might be perfect, so you don't need to put too much attention on that one. Whereas another one might be on fire, they don't have the right skills and people and imbalance, so we need to address that issue. It's the analogy of spinning lots of different plates. You don't know which one, and which one is going to curve off in which direction. But you have to be good at being able to switch context pretty quickly. It helps to have a standardised mental model at some level of what is a good state.

What are your thoughts on remote or distributed teams?

One of the interesting things about hyper-growth is knowing that teams will change, so people will be on-boarded rapidly. I'm a big believer that relationships develop much quicker when you have that personal face to face. That was one of our choices.

When we set up Barcelona as a development hub, we didn't split the product across Berlin and Barcelona. We moved a whole product group area to Barcelona, and we sent people from Berlin to see culture and help them feel connected and understand how to navigate the organisation. Then we gave full ownership to that group as they developed an understanding of the product. This model has helped us to lower our coordination costs, and people do not have to synchronise their meetings as much as they did before.

The other inevitable counter-example is that we have started a development centre in the US. Launching the US project was interesting because it cut across all product groups, and it required the high coordination of all the product groups. Obviously, all the product groups had a US focus. The team in the US had to coordinate with the different groups at different stages, depending on who was on the critical path. This is where we had inevitable different perspectives on how the team should be distributed and coordinated, although we have tried to minimise this, where possible.

How do you know when you are ready for a leadership role?

The short answer is that you do not know. The best way of learning is often by putting yourself in a situation where you can start practising leadership. Often people are caught in a dilemma when making decisions, not knowing if they should try something or not, and what if they fail?

One way is to start taking more leadership decisions, to stop worrying about the role or the title, and to step up and start practising some of these things. It has two interesting effects. One is it will help scale your existing leader, so they will be happy to delegate more things, and also, the leader can coach you and support you to complete the task.

If you're thinking about wanting to do this, find a safe environment, find a good leader, a mentor, somebody that can give you ownership, and don't wait.

If you had a chance to travel to the past when you were taking up the job, what would you do differently?

I tried to do this, but how I would try to do it better is that during particularly hyper-growth, you need to take care of yourself a lot more. You have to find a way to turn off your brain, which is hard as an engineer because your engineer brain's always trying to problem-solve. The consequences of not having enough sleep are: you will be moody, you may not give your best game, you are going to reach, and you're going to say things that you wish you didn't. It's just hard to be an effective leader when you're under more stress. You have to find a way to take care of yourself, and that will help you scale.

What books do you recommend for engineering leaders?

Camille Fournier's book The Manager's path is a great one because it explains things at different levels, but the trade-off is there are less concrete things per level, but it gives you a good overview around that.

---