Technical leaders face challenges beyond individual contributor work: aligning with business on investments, managing systemic aspects, mentoring, and keeping up with a changing codebase, Patrick Kua mentioned in his talk Choosing The Technical Leadership Path at Goto Copenhagen. He stressed the need for technical alignment—shared codestyle, implementation patterns, and standards—to avoid accidental complexity. Leadership grows through practicing skills, improving team issues, and acting as a role model.
Technical leaders face different challenges than they would as an individual contributor, Kua said. He gave examples: having to align with business/product people on technical investments (such as tech debt, platform work), having to manage or work with other teams to manage broader systemic aspects (such as infrastructure, operations, etc), or to provide guidance and mentorship to individual team members. All while still trying to stay in touch with a constantly changing codebase and even more so toolset with GenAI, he added.
Technical alignment is essential, as Kua explained:
Without technical alignment, individuals constantly touch the same codebase, adding their feature in the simplest way (for them) but often they do this without ensuring the codebase is kept consistent. Over time accidental complexity grows such as having five different libraries that do the same job, or seven different implementations of how an email or push notification is sent and when someone wants to make a future change to that area, their work is now much harder.
With the right level of technical alignment, teams can continuously make changes to the same codebase as every part of their system will be similar, Kua argued.
To enable technical alignment, technical leaders need to help the team agree on codestyle, Kua said. The next challenge is aligning on implementation patterns. This means creating agreed standards on common functionality (e.g. email sending, user notifications) and common tasks (e.g. logging, exception handling, network retries, etc). Once they’ve been agreed on, these standard patterns should be documented in the team wiki, he mentioned.
To gauge alignment among engineers, ask everyone to describe how they specifically define “good” code, Kua suggested:
If they write down similar things, people are aligned. If they write down very vastly different things, they’re misaligned and there’s an opportunity to demonstrate technical leadership and increase alignment.
There are plenty of resources available to develop leadership skills. Kua advised to break broader leadership skills into specific ones, such as coaching, mentoring, communicating, mediating, influencing, etc. Even when someone is not a formal leader, there are daily opportunities to practice these skills in the workplace, he said. Choose a skill and then find ways to learn about it, such as with AI tools, YouTube, online courses, courses that HR/People teams offer, and books.
Then, most importantly, is to find ways to apply your knowledge in small ways, Kua said:
As an example, engineers can practice refining their communication skills every day as most are working in a team and need to communicate with team members and also business stakeholders outside of the team.
Another important way is to look for issues that everyone is complaining about, but no one is taking care of. These sorts of issues are opportunities to demonstrate leadership by improving the environment for everyone in your team.
Be the best person you can be and act as a role model, Kua said. Even if you’re not a formal leader, when people respect you and see you as a role model, you will be practicing leadership even without the title, he added.
Don’t consider a move into technical leadership as a promotion, Kua said. You will be doing a lot of activities that are very different from what you were doing as an individual contributor, so you’ll be drawing upon many different skills that you never needed before. The good thing is that you can learn these skills if you study and practice them, he concluded.
InfoQ interviewed Pat Kua about technical leadership.
InfoQ: What makes people decide to become a technical leader?
Patrick Kua: A lot of engineers wish they had more influence, and one big benefit of being a formal technical leader is that you often get invited to planning sessions about the future. In those sessions, a great technical leader can bring new insights with a good understanding of constraints and opportunities of the existing system, and suggest simpler solutions to achieve the same business outcomes. One flipside of this, however, which many technical leaders dislike, is that it does mean spending more time in meetings…
In many cases, people are simply asked to lead a team. It’s usually because they’ve invested significant time in improving their work environment, which in turn enhances the work environment for everyone, and someone has already recognised their ability to demonstrate technical leadership. They might be the person everyone goes to for advice. They might be the person who can communicate very well with product or marketing. They have many of the skills, and someone in management recognises this and asks them to take on a formal technical leadership role.
InfoQ: How does good technical leadership look?
Kua: It’s helpful to distinguish between formal and informal technical leadership roles. Formal technical leaders are accountable for ensuring teams have enough technical leadership. One way of doing this is to cultivate an environment where everyone is comfortable stepping up and demonstrating technical leadership. When you do this well, this means everyone can demonstrate informal technical leadership.
Formal leaders exist because not all teams are automatically healthy or high-performing. I’m sure every technical person can remember a team they’ve been on with two engineers constantly debating about which approach to take, and wish someone had stepped in to help the team reach a decision. In an ideal world, a formal leader wouldn’t be necessary, but it’s rare that teams live in the perfect world.
