Illustration by Matt Peet

Many great tech leaders and engineering managers share a common motivation for becoming leaders in the first place: because they worked under really bad ones. They know from experience the toll that ineffective, lackluster or toxic leadership has on a team’s environment and productivity.

Sometimes, simply doing the opposite of those bad leaders is enough to steer them in the right direction. “But the step up requires different skills,” Patrick Kua says. “You have to want to focus on what good leadership and management is.”

Kua believes that leaders don’t turn bad out of an inherent rottenness. They either a) are leading for the wrong reasons—a slight increase in pay, or the perception of prestige, instead of a true desire and willingness to lead; b) fail to recognize the different non-technical skills that leading people requires; or c) lack the necessary support to become effective leaders.

Kua passionately enables the growth of new tech leaders through giving keynote speeches, authoring books on the subject, and launching online leader training and support through the Tech Lead Academy. He has nearly 20 years of seasoning in technical leadership as a Technical Principal Consultant at ThoughtWorks and as the CTO and Chief Scientist of N26, where he grew the tech team from about 50 to 350 in just two years.

He thrives on helping people learn to steer around those treacherous obstacles. “I stay as a technical leader and help technical leaders on this journey because I get a lot of pleasure out of seeing the success years later,” he says.

In this interview, Kua discusses eight action items that new and emerging tech leaders can adopt and practice to ensure that they are in leadership for the right reasons—and that they’re setting themselves up to be the best leaders possible.

Some tech leaders feel like they’ve finally found their natural calling. Some grind away at the practice to continuously improve themselves. And others just never stop floundering. Those so-called “bad leaders” may suffer from a single misstep: it’s entirely possible that they’re simply on the wrong career track.

“I think the good thing about our industry today is that we recognize that there are other ways that people can add value to an organization,” Kua says.

He points industry leaders to the Trident model of career development, which differs from the standard career ladder in that it draws out three different ways for engineers to advance their careers:

• Management track, where people spend a majority of their time leading and supporting people, managing structures and processes and organizing for their teams. Often, engineers think this is the only way to further their career.

• Technical leadership track, where people spend a majority of their time leading others on technical topics, without necessarily being responsible for people in the way a manager is. Leaders on this track must still hone their leadership skills to succeed.

• The true IC track, where people spend a majority of their time focused on executing and doing the technical work. Early-stage software engineers tend to reflect this track—but it’s not only for newer employees. As people advance in their careers, this track becomes increasingly specialized, especially in larger organizations.

In the Trident model, no one track is inherently more valuable or necessary than the others. The scale of the company may shift the quantities and ratios between these roles, but engineers looking to grow can have three distinct tracks that reflect their own desires, skills and willingness to learn. This choice is the first step to setting up new leaders for the most success. One formative moment sticks out to Kua as a great example of how leaders can make room for their team to forge their own path.

“I had this person on my team who was not the strongest developer but was really interested in doing user experience and testing,” he recalls. “He wanted to understand how easy it was for our users to accomplish certain activities, and because he was empowered to do something about it, we found that we had designed things functionally, but not very usable or intuitive. I wasn't really an official tech lead during that time, but that was a huge lesson in leadership. They created an environment where people felt permission to do things their way. They didn't need to ask.”

This takeaway Kua gained early on in his career has only been reinforced over time: Great leaders need to be comfortable ceding control of their team to the team members themselves. Their responsibility lies more in creating an environment for their team to find their own path than being an overseer.

Simply put, a team can produce more together than individual engineers can alone. Through that lens, some tech leaders may not be coding or reviewing code. But, Kua says, they are the ones most capable of shaping the environment to make it more conducive for the entire team.

“A good leader is not necessarily telling people what to do,” Kua says, “but creating the environment so that everyone knows the right thing to do and how to go about doing it. Good leaders and managers aren’t managing people and tasks. They are managing the environment.”

With credit to Grace Murray Hopper, he reminds us that we manage things and lead people. Effective managers remove blockers and provide the tools their teams need to accomplish what they do best.

“To me, the essence of good leadership is bringing out the most potential in everyone, but also being inclusive as possible so people can contribute in lots of different ways,” Kua says. 

As he’s led many of his own teams, Kua puts the culture and environment of his team as a top priority. He believes in offering everyone on the team opportunities at ownership, while giving them the tools and help needed so they’re set up for success.

"It’s important to push ownership down into the team, but make sure that they’re capable of completing things so that they don't get overwhelmed or struggle unnecessarily," Kua says. "If you allow them to take ownership in a responsible way, then the leader can focus on improvements in the environment and processes."

The first time Kua took on a formal tech lead role, he jumped in without any real training—and he didn’t know what he was doing. So he fell into the trap that many new tech leaders stumble into: he tried to code as much as any of the developers on his team, while also acting as the backstop for anything missed or delayed by the team.

In short, he took on responsibility for everything. The result was a lot of pressure and stress.

“A lot of first-time technical leaders are of the opinion that they need to be the boss, the expert, to have all the right answers,” Kua says. “But leading is about maximizing everyone else on the team, not just your own personal productivity. It’s a mindset shift from maker to multiplier.”

He identifies part of the essence of leadership as bringing out the potential in everyone on the team so they can all contribute in different ways. Developers need permission to create without asking for it. They need someone to enable them to do what they already know needs done—and what they already, intrinsically, want to do.

“It's important to outline what is important and what the context is,” Kua says. “Is it about the deliverable? Is it about the mission? Whatever it’s about, set up the context about why we're doing the things that we do. And then trying to break those things down into sort of concrete activities or opportunities that people can opt in to take ownership of them.” 

When engineers feel this sense of ownership, buoyed by an understanding of why their work matters, the team becomes more sustainable. The role of a tech leader is arguably to build a team that doesn’t need them—so when managers and leaders go on vacation or take leave for their health, their high-performing team continues excelling because they own their own work.

And, they need a leader to calibrate their output as a team. “You’re not trying to optimize for you and you’re not trying to optimize for a single developer on your team,” Kua says. “You’re really trying to optimize for everyone and the team’s work together.”

Kua strives to allow team members to take voluntary ownership of their work. “When people choose to do something because they want to,” he says, “they’re going to do a much better job than me trying to orchestrate them.”

In other words, context alone isn’t sufficient to keep a team going. Kua reminds us that developers still need to learn and grow as individuals and as teams. It’s unhealthy and inefficient for tech leads to be constantly in the weeds with their team. This dynamic will create codependencies which result in the crippling of leaders and teams potential.

“If a leader feels that they have to be involved in every technical discussion in every team meeting, they're not really doing their role effectively,” he says. “They need a plan to stay up on what their team is doing, and also offer ways to help grow people so that they can get to a point where they can delegate those activities. It’s like the old saying—show one, do one, teach one.”

In that overwhelming situation of taking on too much responsibility, Kua’s project manager sat him down and offered him some frank feedback. It wasn’t about Kua’s “bad” approach to managing, but about how he could change the situation. He discovered he was not even aware of the problem or how to change it, and that conversation altered his career.

“What I have tried to do from that point on is build a culture where feedback is continuous and more ad hoc,” he says. “And that feedback doesn’t have to come from the person in authority. It’s a continuous process amongst everyone.”

This approach shifts away from the quarterly or semi-annual review which is both formal and too infrequent to implement anything incrementally or continuously. Kua aims to offer feedback to team members every week or two.

“Nobody should be waiting for feedback until I do an annual review,” he says.

For that continuous feedback system to work, Kua has to establish the conditions for it.

“You have to first teach people how to give and receive effective feedback,” he says. “You can create that environment, but if people aren’t prepared to give and receive feedback, they can get upset by it.”

Many engineers—and tech leaders—need to learn how to process and offer feedback in a more human and empathetic way. But Kua points out they are already knowledgeable about taking in various forms of feedback.

“I try to help people recognize that, as engineers, they’re getting feedback constantly through tests, code reviews and customer satisfaction impact,” he says. “You see numbers move. And they’re all different types of feedback.”

Often the best feedback doesn’t come down from above. So Kua creates opportunities for people on his teams to create feedback for each other. Sometimes this happens serendipitously, but Kua’s role in building the culture of continuous feedback means he implements systems to enable it.

One of the ways leaders can do this is the visual representation of the “pair stair.” Picture a spreadsheet with all the team members listed along both axes. Mapping out pairings between people forms a stair.

“Over the course of say a month or two, depending on how big the team is, you set the expectation that everyone should be swapping feedback with everyone else,” Kua explains. “They should be doing it on a weekly or bi-weekly pace. By the end of that time, they should have given some piece of feedback to everyone else.”

Kua creates that space but does not enforce it. It’s up to his team members to pick out who they want to talk with, offer feedback to and solicit feedback from. He suggests some useful mechanisms for enabling this feedback: regular calendar invites for slots of feedback time work well, as does a regular recurring block of time each week.

“It’s up to you to work out who’s the most appropriate person to get feedback to and from,” Kua says. “It’s really about personal growth from all perspectives.”

Trusting team members to take ownership of their work means giving them a certain freedom to both succeed and fail. The latter, Kua says, often manifests as either over- or under-engagement.

“With disengagement, people are putting in minimal effort,” he says. “You’re asking people to sign up for something and they never sign up for anything.”

This situation indicates a whole range of possible causes. They could be dealing with personal stuff outside of work. It could be health-related. It could be that the work is not stimulating or interesting, and they need a shift. The challenge for Kua is to converse with those developers, find out the sources of their under-engagement and work to clear the way for them.

The other extreme manifests as over-engagement. “That’s really a path to burn out,” Kua says.

Over-engagement is perhaps more difficult for tech leaders to address than disengagement because, particularly in startup and tech culture, these over-engaged individuals tend to be lauded as heroes. They always jump in and solve the problems, take on the difficult challenges, save the day.

“That’s useful to a certain degree,” Kua acknowledges. “But if it’s a consistent pattern, I would encourage them to take a holiday. Take a break. They have to take care of themselves because they might hurt themselves. And by the time they recognize it, they may already be burnt out. As a leader, you have to prevent those single points of failure in your team.”

Not all failure is a detriment to the team. Kua likens a developer’s continuous learning to riding a bicycle.

“When you are trying to teach somebody to ride a bike, you don’t just tell them how and you don’t ride the bike for them,” he says. “That will never work. They’ll never learn.”

A critical component of learning is making mistakes. These offer the opportunities for reflection and analysis. Leaders naturally want their people to do well, but if they want their people to grow, they need to create an environment where people can fall off the bike.

Carving out a space for failure is the true challenge for tech leaders. In such a zone, failures have smaller impacts on the team’s mission. “This is where tight feedback loops are really key for leaders,” Kua says, drawing on his earlier points about continuous feedback. “If somebody is doing an activity or task for the first time, and you let them go for months without any sort of help, that creates a problem. So I approach it more like this: You have to show them how to do it. You shadow them. Then you get them to do it. You give them feedback. And when they’re ready, you ask them to teach it to someone else so they get a deeper understanding about the concepts.”

“Gradual understanding is really key to making people feel safe to fail,” he adds.

And all this goes for himself as a tech leader, too. Kua guarantees that he makes mistakes. He puts himself through the same process of falling and learning, and also makes his process explicit to the team that he’s working with in order to normalize it.

Kua concludes with this thought: “It’s very important to learn more about yourself,” he says.

Developers-turned-leaders often think in binary terms. There must be a single right way to lead. But the truth is, there’s not any one right way to lead any more than there is one right variety of ice cream.

“I call them flavors of leadership,” Kua says. “Everyone has a different style. Part of being comfortable as a leader is knowing what your style is. In order to do that, you have to become aware of what your natural strengths are, where your strengths don’t lie and try to be your authentic self.”

Getting elevated into a higher leadership function can be daunting. Some engineers have difficulty transitioning to leadership positions, but Kua’s playbook contains seven actionable steps to help new engineering leaders succeed.

1. Figure out the best-fit leadership track: Let your team determine their path, rather than defining exactly how they should be doing their job. Engineers will typically fall into one of the three tracks in the trident model of career development:

• Management track

• Technical leadership track

• The true IC track

2. Manage the environment instead of people: Leaders should spend less time managing and micromanaging their team, and more time building an environment where the team is empowered to lead themselves.

3. Shift from maker to multiplier: As a leader, your mentality needs to shift from individual contributor to multiplier of efforts. By instilling an ownership among your team, you’ll create the environment needed to maximize everyone’s collective talents.

4. Create continuous feedback—for your team and for yourself: Implement ways for your team to offer feedback early and often with built-in ad-hoc and “pair stair” reviews.

5. Pay attention to over- and under-engagement: Monitor your team’s workloads, so you can step in if someone is at risk of burnout, or re-invigorate those who seem to have mentally checked out. 

6. Let your team—and yourself—fall off the bike: An important part of empowering your team is letting them make mistakes without fear. Failure is inevitable and should be learned from.

7. Find your flavor: There is no one-size-fits-all recipe for a great leader. But one component to any good leader is the ability to understand themselves, what their strengths are and how they can apply them to help your team the most.