Effective Technical Leadership

Most successful projects have a single engineer responsible for driving the project forward while ensuring that strong technical decisions are made with confidence. Typically, that person is referred to as a Tech Lead. They often don’t manage people, but instead coach them to do their best work.

Every company is different, but there are some common threads among the best tech leads that I’ve worked with. Hat tips to Brian Stoler, Nathan Hunt, Evan Gilbert, and Rich Burdon for leading by example.

In this article, I lay out what makes for a badass TL, broken down into 3 A’s: attributes, activities and actions. And many of these concepts apply to being badass at life in general. Your mileage may vary.

Attributes

Over time, you should always be increasing three attributes: Knowledge, Speed, and Awareness.

1. Knowledge
Technical knowledge gives you insight and credibility in making good, defensible decisions. A strong tech lead’s knowledge is broad and deep. If a team member asks how a particular component or system works, you should be able to explain it at a useful level of detail or point to someone who can.

To remain knowledgable, I do three things in this order:

1. Review code
2. Read design documents
3. Write code (see ABC: Always Be Coding)

Order is important, notably for the first two. If work is completed, but waiting to be reviewed, then you should almost always drop your own work and help move it forward. When not assisting others, writing code keeps you fresh on the code base.

A tech lead should be a master of several technologies. For example: Java, JavaScript, C++, distributed storage systems, and client-side web development may make for a solid web application tech lead.

2. Speed
You should strive to be ultra-responsive and capable of making instant decisions, always kicking the ball forward. Engineers should come to you with questions expecting a swift response.

I personally pride myself on my ability to respond quickly. The goal is to seem omnipresent to my team. And my secret weapon is my inbox, so I prefer to use tools with tight email integration.

For example, it doesn’t matter which issue tracking, code review, or production alert software you use, but team members should get email notifications and be able to comment on the issue via email. Allowing anyone on the team to react quickly to new or updated issues and stay on top of all state changes, even from a mobile device.

3. Awareness
You should be able to keep the current state of the entire project in your head at all times. Otherwise, you cannot be aware of potentially imminent blockers. If there is an internal or external force that threatens slowing the project down, then you should know about it.

Again, email integration is key here. Ideally, all state changes or updates should flow through email in some form, even for offline meetings. For example, someone should always send meeting notes to the entire team, especially when important decisions were made.

You should always be improving the three attributes above, as you can always be faster, more knowledgable, and more aware.

Activities

There are five core activities that I found myself constantly doing at any given time as a tech lead. Almost every action comes down to one of these.

What I’ve learned over the years is that the two most important things that a TL can do also happen to be exact polar opposites: block and unblock.

1. Block.
Blocking requires a high level of awareness and scales from strategic decision-making to tactical engineering tasks. The tech lead needs to be alert and aware to what is going on in the project, always ready to jump in and block bad decisions before they are made, typically armed with a better solution.

For example, if an engineer sends out some code to be reviewed to another engineer on the project, which might seem innocuous to the reviewer but in fact introduces new bugs, and you are able to step in and alert the author before it is submitted or released to production is extremely useful to the author, the reviewer and the overall project.

Blocking should not stop progress, it course corrects so things can keep moving. Think harness, not safety net.

2. Unblock.
Converse to blocking, unblocking is equally important. The road to hell is paved with idle engineers. If someone has a question, you should be able to either give an answer or bring in the right person to field it.

Something that helped me develop this skill was hosting interns. The best interns have lots and lots of questions. And if they don’t get answers, they can often get stuck, or worse, frustrated. I had to learn how to provide the right answers or connect them with people that could guide them forward.

3. Redirect.
No matter how good you are, you don’t know it all. And you can’t answer every question. And even if you technically could, practically all of your time would be spent answering them. To fill in these gaps (and help you get your own work done), you should mentally build an expert index so you always know where to find an answer. An extremely useful tactic to employ early and often is the redirect. A tech lead is often a “human 302” (or a human redirect) and connects individuals together. If an engineer on your team is unsure of something or has a question that you don’t know the exact answer to, knowing who to send them to is extremely valuable and saves a lot of time.

In addition to redirecting questions, proactively adding the right individuals to any thread or code review can help increase the overall quality of the work. For example, if an engineer is adding code to a critical component that was not originally authored by them, adding an expert to the code review will help ensure that the feature is being implemented correctly.

4. Decide.
Part of your duty is to make decisions, and your team will rely on you. The faster you can reach a decision, the quicker others can act on it. Often, there is no clear path forward and simply going with your gut is the right thing to do.

When you do listen to your instincts, make sure that you’re making a robust decision that can stand the test of time. Your project will likely continue to go on after you’ve moved on, you don’t want your successors cursing your name when they inherit it. This often happens on projects that have accumulated a lot of technical debt.

When faced with making a decision against a set of options, I naturally go through the following process:

1. Reduce the number of options to 2. The complexity of any problem increases exponentially with each option.
2. Quickly determine if there is a best choice based on experience or data.
3. If the correct answer is non-obvious at this point, can it be redirected to someone who is better suited to make the decision?
4. If there is still no best choice, then there may not be enough data or the wrong question is being asked. Either block the decision from being made or unblock it by going with your instinct.

The steps above should be done in your mind in an instant.

The quality of decision is like the well-timed swoop of a falcon, which enables it to strike and destroy its victim. -Sun Tzu

5. Show.
One of the most important aspects of a technical leader is that they are able to demonstrate it by example. We’ve all heard the phrase “lead by example,” but I prefer, show, don’t tell. By design, a tech lead is often not a manager because they focus their energy on code, not people. So, it’s important to have the respect and trust of your team, which is best accomplished by demonstrating that you know your stuff.

Most leaders may find it hard to make time to write code, but it’s extremely important that you try to find time. I call it inventing time. Even if I can spend a little bit of time doing “grunge work” fixing annoying bugs or adding little helpful pieces of code here and there as needed, I will; it is more valuable to you than the code itself.

Actions

Below is a list of things that a tech lead often does to help move a project forward. It is far from exhaustive.

• Create and maintain launch, testing, and release plans.
• Host effective engineering team meetings.
• Make sure meetings are useful and brief as necessary.
• Help create and stack rank project priorities.
• Say “no” often to new or unnecessary features.
• Define best practices for issue tracking.
• Setup team fix-its, hackathons, or bug scrubs.
• Maintain cross-functional relationships.
• Create target milestone dates.
• Stay updated on useful tools.
• Coach other engineers.
• Recruit engineers from other teams.
• Host interns, make them successful.
• Review code in detail and give useful feedback.
• Read, write, and give feedback on design documents.
• Write the right code at the right times.
• Shield engineers from management as needed.
• Work with other engineering teams, especially dependencies.
• Identify technical debt.
• Explain why decisions are made.
• Fight for the right design decisions.
• Make time for addressing technical debt.
• Load-balance work among the team.
• Onboard new engineers and help identify other engineers as coaches.
• Course correct and refine target dates as needed.
• Maintain the definition of the project’s MVP.
• Evaluate architectural decisions and their implications.
• Ensure tests are being written for core functionality.
• Maintain on-call and onduty processes.
• Escalate blocking issues as necessary.
• Vet the product’s privacy and security concerns.
• Generate new ideas and elegant solutions often.
• Debug difficult production issues.
• … and so on.

There is no prescription to being a successful tech lead. The best are prolific coders with a ton of real-world experience shipping products. But think back to the best leads you’ve worked with and how much of what you’ve read above applies to them.

Be confident, keep moving, and always improve.

Love or hate this article? Let me know @davidbyttow.