Photo by Kobu Agency on Unsplash

Tech leadership is a mystery to many. As one racks up years of experience as a developer, there's often an assumption that one must eventually move into tech leadership to continue to grow. And while this may be true, given the structure and hierarchy of the company you work for, the jump from individual contributor to tech leader isn't always smooth. The two roles have some crossover in skills, but each also requires its own unique set of skills to get the job done as well.

I've been a tech lead of sorts for a lot of my career, from my time managing a development team to my side freelance projects, which often involve managing subcontractors. But it's only in the last two years that I've been at Happy Cog, where I've been a tech lead in a more official capacity. With that shift came a lot of trial by fire, and I've definitely learned a lot along the way.

There are always ways to improve, and I most certainly don't have all the answers. But here are a few things I've learned along my journey into tech leadership.

1. Leadership Isn't About Control

First and foremost, tech leadership (and any kind of leadership, really) isn't about the control you have over the project and team. You don't become a tech leader so you can be the boss and call all the shots. (And if you do, you probably won't be a very good one.)

Rather, tech leadership is about casting a vision for a future state (think project completion — or for a product, release) and helping others on your team get there. It's not about micromanaging the details or doing it yourself but helping to guide others' processes so they can end up where you'd have ended up had you done it yourself.

The thing is, when you're an individual contributor, your contributions can only go so far. While you can always continue to hone your skills and processes, at the end of the day, you'll always be limited by the constraint of time. When you've got a lot of experience, being a tech leader allows you to increase your own impact and output by helping others be more effective.

2. Unblock at All Costs

Anyone who has done any significant amount of programming work knows that it's easy to get lost in a problem, spending precious time going down a rabbit trail of debugging. Without coming up for air, it gets frustrating and demoralizing — and ends up wasting a lot of time.

As a tech leader, a blocked developer is one of the biggest risks to your project. And it's your job to help.

First, it's important to recognize the signs of a developer spinning their wheels. Are they asking lots of questions that seem disconnected or aren't showing progression? Are they showing signs of frustration? Are their status updates or commit messages vague and don't seem to be moving forward? Chances are if you're seeing these things that your developer is stuck.

It's time to jump in. But remember you're there to unblock, not fix the problem. I usually tackle this by asking a series of questions. Even if I know the solution immediately, I like to guide the developer through my logic of diagnosing the issue. I hope to help them not only solve their issue but also learn from it for the future.

Even if you don't know how to fix the issue, asking questions and talking through options with a developer can help get them out of their head and lead them to finding a solution. Don't be afraid to point a developer to other resources, whether those are code snippets, documentation, or even other team members who you know can help.

3. Communicate Confidence

A big part of my role as a tech lead is not only working with the development team but also communicating and representing the development team to the project managers and clients.

I will readily admit that there are many times when I'm thrown into conversations where I don't have a ton of knowledge of what I'm talking about. As a tech lead, my job is to be a generalist, to know a little bit about a lot of things. Unfortunately that doesn't cover everything, and so you have to get good at asking the right questions (or doing a bit of effective Googling) to be able get up to speed quickly and speak knowledgeably about a subject on a moment's notice.

Potentially, more importantly than me understanding what you're talking about is my ability to exude confidence when you're talking about the project. Your team is considered subject-matter experts, and it's your job to maintain stakeholder confidence in your team, ensuring them that you and your team have things under control. Sometimes you flat out don't know what to say, and for those moments, you have to train your reflexes to not panic. Instead, I suggest conferring with your team and getting back to the stakeholder with an answer later.

4. Project Budgets and Timelines Are Your Problem Too

When you're first coming into tech leadership, you may think managing the budget and timeline is solely the responsibility of the project manager. Certainly the buck stops with the PM for these aspects of the project, but as an often nontechnical person, they're going to be a at a loss for how to effectively manage them without input from someone with development experience.

Developers thrive on constraints. And so, when you give them a big project budget and a big project timeline, they often get lost in the details or lose track of time … or over-engineer at the beginning and run out of time and budget toward the end of the project.

You can help with this by breaking down the project into smaller chunks. Using your experience, you should be able to look at the requirements and group the project into workable chunks, grouped by features or the like that are easier to reason with.

Breaking projects down early helps developers know where you want them to spend their effort on the project. If there's a mismatch between your breakdown and how long a developer thinks a task or feature will take, then it can lead to a discussion to make sure you both understand the scope and how it should be implemented.

5. Don't Be a Hero

Everyone wants to be the hero that makes a project go perfectly or rescues a project from a bad spot. But that's not what being a tech lead is about.

You don't have to — and probably won't — have all the answers no matter how much experience you have. Sometimes, even if you do have the answer, you shouldn't say so in order to enable your development team to work through the project as well.

As a tech lead, your most important job is to be an enabler. Your role is to help the developers get their jobs done. It's a big shift for those coming from a role where they contribute as a developer, but the shift can be so rewarding.

You will get your glory eventually. It comes from watching your team succeed.