Why Your Technical Failures Are Leadership Failures (and Vice Versa)

Technical leadership is the intersection between technical expertise and leadership. I feel that combining the two is generally undervalued today, and by the end I hope it will be clear why.

Technical expertise is skill in a domain. It is effectiveness of a software engineer at building systems or an electrical engineer at designing circuits. Early in your career much of your growth is in this area.

As John Maxwell says, “Leadership is influence.” When an architect gets buy-in from teams to implement his plan, a QA person raises the quality bar with their team, or a scientist teaches others in his lab who follow his example, they are leading, regardless of what their title might be.

Consider a hypothetical example. You work on a web service and trying to prevent users from abusing your login page; they are trying to steal passwords and take you down.

As a good engineer you recognize, we should at least use an IP-based blocking solution. You survey options. Can a CDN do this? Can we built it internally? What will each cost in effort or money, both now an into the future? Perhaps you pick an internal build with a data storage option that's robust, well-tested, and satisfied your current needs. You find that balance between costs, future needs, and scale. That's technical expertise.

How about technical leadership?

First, likely you noticed the problem in the first place. You built the monitoring dashboards and noticed the unusual traffic patterns. Rather than let those sit, you investigated, weighing the impact on your database, and tracking down the cause. That's initiative.

Then, you spoke with stakeholders like the Product Manager to explain why this should be solved. You explained the problem, potential solutions (like firewalls and captchas) and their costs in terms a less technical person could understand. That's connection.

You also asked, has anyone else here solved this? What can I learn from them? Can we share? You learn that another team at the company has built a Redis-backed rate-limiting solution that can solve this problem in a cost-effective way. That's seeing bigger.

The catch is, it has no API to be shared like this. You feel tempted toward the fastest solution, building your own similar thing. But knowing the long-term benefits of well-designed shared components, you reach out to work with the team that owns the service. You persuade this team of the mutual benefit of making this shared component a distinct API service. That's getting buy-in.

All of these are just a part of what goes into influencing your organization through people.

In the end, perhaps some else builds it. It's a well-defined piece of work non-leaders can do. You move on to other tough problems that can only be solved by technical leaders.

Here is how I often see this process fall flat when technical leadership is undervalued.

Apart from leadership, technical experts will choose solutions that optimize the exercise of their craft. Engineers will solve the problem by building something with a preferred tool. Operators or IT people will find something to buy. Scientists will create novel inventions. Most will ignore the breadth of possible options, not just because those options are outside their field, but because they lack the context of business value and trade-offs which should ultimately decide what an organization does.

Apart from technical expertise, leaders cannot allocate resources in properly. They cannot properly train and rate their people. They miss industry signals the require domain knowledge to recognize. They are unaware of optimal solutions to their organizational goals, choosing instead to copy what friends or competitors are doing.

In practice, of course, good leaders work closely with technical people to overcome these gaps together. No human is perfect at either (or perfect at all). I am not advocating for individualistic super-humans. We need teams.

Still, it is rare to find a leader and expert who are both skilled, both aligned, and trust each other. In practice I see the failures I mentioned earlier happening regularly.

Ask yourself: