There are business books by the dozen written about leadership, but we keep struggling to clearly define technical leadership. Even though we seem to intuitively acknowledge that leadership is a thing, we can’t clearly qualify it, nor quantify it. Technical leadership applies equally to people managers and individual contributors. The rubrics that define a technical leader don’t change because one writes code and the other one does not. The degree in which that rubric is exposed does, but not the trait itself.

Back in 2012 we went through a major restructuring at Yahoo with the target to reduce the workforce. Despite whether this was a good idea or not, clearly not, we had to find out who to let go. Although we had principle-based decisions we were following that removed hundreds of people at once, for example we were eliminating QA as a separate function and merging it with engineering, or eliminating product management as a distinct organisation, we still had hundreds of engineers to let go. Although the exercise was dreadful, as we were letting go of our friends, we still needed a quick way to measure and determine at large scale who were the best people to stay. The issue was that when engaging with tens of VP Engineering in the company to determine who should go, they all had their own views about who were the best engineers. As humans, we think that the best people are those in our team, and that they are in our team because they are the best people. When you have to look at multiple disconnected teams, every team thinks they are best. We were lacking the rubrics to define whose were the technical leaders who had to stay. A year later, after Marissa Mayer came in as CEO, we had a similar issue. Once again, we had the issue of full teams not agreeing what rubrics to use to determine who were the best engineers. Through these two exercises I defined a very simple framework for how to analyse technical leadership, and how to define the rubrics and traits of technical leaders.

When we look at the fundamental objective of software engineering, we are faced with the problem of creating complex solutions out of simple parts which meet functional product requirements, defined by understanding customer’s needs, and non-functional quality attributes, defined by experience and craftsmanship. It is the latter, the understanding of non-functional quality attributes which trips us when trying to understand what makes a great technical leader. When thinking about scalability, or observability, how should we look at technical leaders? To break this down, I analysed the problem as follows. Software engineers:

  1. Work in projects,
  2. In order to write code and configuration,
  3. That works coherently with the rest of the code written by other engineers,
  4. Who are in sync and aligned as a team in regards to the technical direction to follow.

Although simple, this framework captures the work that software engineers do, whether in bug fixing, feature development, development support, infrastructure management, operations, etc. There are four traits required for each of these steps to work well.

Operational Excellence

The first skill we require from technical leaders is operational excellence. Although not all technical roles require the same degree of operational excellence, all the technical leaders need to excel. Examples of excellence traits are:

  • Dependable and trusted, who gets things done predictably
  • Self-driven, resourceful problem solver, who manages work independently
  • Keeps the team informed to ensure constant alignment and avoid concept / domain / epic / theme drift.

There have been countless times when I have worked with exceptional coders or managers, who were spotty at execution. They would be incredible geniuses when they were focussed, but it was hard to figure out if they were going to be focussed. They couldn’t be trusted, despite how amazing they would be. The work ethics, drive and obsession required to excel is what technical leaders need to become excellent at execution.

Technical Prowess

I usually use the terms craftsmanship, arts, and prowess to define the skills of the engineer. Whether in architecture diagrams, system designs or code, it is at the end of the day the ability to create systems that solve problems what differentiates the experts from the amateurs. Although there are many ways to measure the quality of these artefacts, in my experience the one that rules it all is simplicity. The most difficult skill to develop as an engineer is thinking in simple terms, and writing simple code. Simplicity leads to better observability, better scalability, better maintainability. Simple systems are easier to understand, reason about, and change over time. The more seasoned the technical leader, the clearer and simpler their work becomes.

Technical prowess is not limited to individual contributors. People managers and project managers need to be excellent at understanding and working with simplicity, so that they can communicate effectively with their teams, and put in place project plans that clearly articulate the execution needs. Good code and good plans reduce future work, they both help reach the destination faster and cheaper.

Team Player

Whether people manager or individual contributors, technical leaders need to lead others. They don’t work in a vacuum writing plans or writing code. They need to work with teams, help others, and amplify them. A great technical leader increases the productivity of the team. A team of great technical leaders is a high performance team, highly functional, and highly self-organised. The work of a team of 7 engineers is not 7 times the work of 1 engineer, it can and should be much more. Every technical leader needs to be a team player and amplify their team’s potential.

Becoming a Technical Leader

We like to think that all an A+ engineer needs to do is write great code. That’s actually very far from the truth. Even though some engineers are extremely productive and write orders of magnitude more and better code, we can’t measure technical leadership by code alone. An engineer who has been doing the same work for years will know the system inside out. It will be hard for anybody else to effectively contribute to this system. In fact, in some cases it won’t be possible at all for others to work with these lone-ranger A++ coders. Strikingly it’s usually best to remove the super-star, than to let them do whatever is required whenever is required. Super stars become fire fighters, and great fire fighters are usually those who are responsible for starting the fire in the first place. I have learnt over the years that I’d rather have a great technical leader that knows how to define and meet deadlines (team, project or for their own), how to produce simple artefacts, and how to work closely with the team.