The first time I took on a tech lead role early in my career, I had little clue what I was doing.

Overnight, I found myself suddenly responsible for the technical and project output of a team of four engineers at an underdog startup — even though I had no more training, mentoring, or tools for my new role than the day before, when I was still just a senior individual contributor.

My two options were to sink or to swim. I hustled to figure things out with 60- to 80-hour weeks. And I made a lot of mistakes.

One time, I was taking a much-needed vacation in Hawaii. During a hike on a volcano with my wife, I received a text message from the CTO: “The logs processor is down.” The logs processor was a critical but legacy piece of software that analyzed all of our customers’ logs data and generated the analytics reports they used for business decisions. And I was the only engineer familiar with the code — partly because the team was spread thinly on many projects and partly because I didn’t want to burden anyone else with it.

Apparently, there’s no WiFi on volcanoes. And so the expectations from customers and from my team weighed on my mind the entire day until I could fix the issue later that night. I learned a hard lesson that day about not being the single point of failure on a team. I’ve learned many more since then, both from my own experiences and from conversations and interviews with hundreds of engineers and leaders across Silicon Valley as I wrote The Effective Engineer.

It’s clear that everyone goes through similar struggles of tech leadership, and these stories aren’t just my own.

That’s why I was excited last week when Dropbox hosted me at their San Francisco headquarters as the keynote guest for their internal tech lead training event. For 90 minutes, I fielded questions from roughly 50 first-time and experienced Dropbox tech leads on a wide range of topics: how to define your role, how to prioritize individual versus team work, how to experiment with new team processes, and more.

One theme, however, threaded through most of the questions. And that was:

“What does success as a tech lead look like?”

In this longer post, I share a general framework for thinking about success as a tech lead.

The Tech Lead with a Thousand Faces

When I reflect back on the most effective and successful tech leads I’ve encountered, they don’t fit into a single mold.

One was a really effective tech lead because he had some of the industry’s best frontend engineering skills (his other technical skills were top-notch as well), was fearless about diving into Webkit or Chromium codebases to understand what was going on, and built tools and abstractions that noticeably elevated the productivity and code quality of the entire team.

Another was really effective because she built strong relationships with adjacent teams, acquired deep technical expertise in her team’s project area, and developed a strong ability to lead cross-team efforts that were important to her organization.

Another could hold very intricate details and ideas in her head, systematically reason through hairy edge cases, and then motivate her team to execute on ambitious projects with high degrees of technical complexity.

Yet another was effective because he could wear many hats: he could use his “good enough” design skills to quickly sketch product mocks, write them up into compelling product design docs to get feedback, and then systematically iterate on, test, and measure the efficacy of those ideas with his team.

It’s possible to become an effective tech lead by being the top 1% in your technical area. But that’s very hard to do.

It’s much easier to get very good (top 25%) in a given area. And so a much more common design pattern for effective tech leadership is this Rule of Three:

Become very good (top 25%) at three things. Then figure out how to combine those skills to effectively ship high-leverage projects.

The three things you choose to get very good at will depend strongly on your own long-term aspirations.

Do you enjoy working on user-facing products? Some things to get very good at might include frontend engineering, user research, or interaction design.

Do you want to explore management some day? Some things might include mentoring or coaching, running effective retrospectives, or onboarding new team members.

Do you aspire to do something more entrepreneurial? Some things might include product management, understanding business needs, or user growth.

Design Your Own Tech Lead Role

Once you’ve identified the three things that you’re very good at (or want to be good at), then you need to explicitly design with your teammates how to leverage those skills more.

This is one of the trickiest parts of being an effective tech lead, for a number of reasons.

It’s tricky because you might not have a clear articulation of what your role actually is — that is, assuming you’re even formally recognized as a tech lead in the first place. Oftentimes, senior engineers assume a tech lead role informally.

It’s tricky because unlike a manager, you lead a team of people to produce results, but you often lead without any explicit authority.

And it’s tricky because despite having a very different set of responsibilities than an individual contributor — you’re starting to lead meetings, prioritize tasks for your team, give more direct feedback, and motivate people — you might not be given very much training or support, if any, around how to succeed.

And yet, the tech lead is an important role because you are in some way responsible and accountable for aspects of technical strategy, product quality, team productivity, and project outcomes.

To succeed, you have to explicitly design what your own tech lead role looks like. This can be both fun (wow! there are so many possibilities!) and scary (help! there are so many possibilities!) at the same time.

To effectively choose your own adventure, you first need to understand what’s important for shipping projects.

How to Define Your Own Effective Tech Lead Role

At a high level, effective tech leads make sure that high-leverage projects ship.

Projects can be loosely defined as products, features, experiments, tools, systems, refactors, or anything else. Until the project ships, the results don’t materialize.

Just shipping projects isn’t sufficient, however. In The Effective Engineer, I shared that leverage — the impact you produce per time invested — is the central, guiding metric used by effective engineers. The same is true for effective tech leads. They ship projects with a high return on investment.

For any project to succeed, it has to do well on several core dimensions:

• Technical: What technical decisions and tradeoffs need to be made? What are the biggest technical risks?
• Product / Business: Why is this the right project to ship from a product or business standpoint? What would success for the project look like? What are the goals?
• People: Who is working on this project? How do you get them excited and accountable for their work? What is important to project stakeholders? What cross-team dependencies might there be?
• Project management: What needs to get done, by when, and in what order? Who might need to know about each thing?

Many tech leads make the mistake of assuming that they’re only responsible for the technical dimension — the term “tech lead” certainly contributes to that assumption.

The reality is that projects succeed and fail by more than just their technical merits. My team could build a great tool or abstraction with clean code following strong design patterns, but if it solves the wrong business problem or consumes more resources than the organization can afford to invest or if my teammates don’t feel great about the work experience, then we could be more effective.

That’s not to say that to be an effective tech lead, you need to cover all of these dimensions by yourself. But you do need to ensure that the different project responsibilities get covered.

And that requires explicitly designing your alliances with the other people on your team.

You and the people you work with — whether it’s a product manager, an engineering manager, a project manager, a designer, or other engineers — are allies on the project. You each bring different skill sets and aspirations. What you want and are good at will differ from the next tech lead.

Therefore, to have an effective role, you need to have an explicit conversation to design the relationships with the people you work with. It’s one of the highest-leverage activities you can do as a tech lead.

That means asking each other:

• What’s important to you in working together?
• What does success look like on this project?
• What’s the best way of asking for help from you?
• What’s the best way to share feedback with you?

Anything else that you find important to make explicit about working together is also fair game.

We’ll be sharing more about how to design effective alliances and more frameworks for tech leadership in future posts. For those who want to learn how to design alliances in more depth, it’s also one of the foundational skills that we teach in our Powerful Conversations for Engineering Leaders workshop — the next one is Wednesday, April 4th in San Francisco.