High performing software engineers are often promoted into tech lead roles.
It’s hard to understand the changes in roles and responsibilities until you’ve spent time in that position.
To better understand those changes, we spoke with Mehmet Bolak. Mehmet started coding from a young age and, after graduating from his C.S. program, he worked at a hosting company, a software consultancy, and multiple startups before landing his first engineering leadership role.
Over the years, Mehmet has learned the skills and responsibilities that are required of a technical leader. In this article, we share the advice he has given to friends and colleagues that are considering taking on a lead position.
This conversation has been edited for clarity and length.
What should an individual contributor know before transitioning into a tech lead role?
This is a question I’ve gotten often. Both at my own company and from colleagues that I’ve worked with in the past.
It’s interesting because I think people have this idea of what a tech leader is, and what they do every day, but don’t necessarily have that hands-on grasp of the daily responsibilities that a tech lead has.
I think anyone thinking about making this transition should ask themselves a few questions:
- Do you like high-level architecture over granular code?
- Do you like writing detailed plans?
- How do you feel about writing tickets with product managers versus digesting those tickets and writing code against those tickets?
I think there’s a general misconception that tech leads are just architects who are writing code 60% of the time. It really depends on what type of tech lead you are.
How can an individual contributor get experience to know if it’s something they’d like?
My recommendation is to just ask your manager for a very small project to own.
It’s really hard to know if you’re going to like being a lead engineer or a tech lead without having some sort of firsthand experience. There are some things that take you by surprise.
New tech leads will often come to me and say, “Hey, I’m not coding more than 10% of my time. Is this normal?”
And I say, yeah, that’s normal. Your job is to make sure the projects we’re doing are going according to plan and that we’re building sound architecture.
Dipping your feet in and getting your toes wet without having larger responsibility is a great way to gauge whether or not you like it.
It’s also important to remember that transitioning into a tech lead position doesn’t have to be permanent. One effective career path is the pendulum career. This involves pursuing the tech side hands-on for a couple of years, then moving into a management position. The career track involves swinging back and forth between the two.
Searching for a new Job? Send us your resume.
What are some common pitfalls during this transition?
One common pitfall is people realize that they like coding more than they like managing projects.
They say, “Wait, I don’t really like this anymore.”
There are some other things in that realm as well. Like dealing with adversity.
There are a lot of different and interesting personalities that you can have on an engineering team. Sometimes leads don’t know how to interact with those different personalities. It’s different going from someone who’s just writing code and collaborating with engineers to jumping in as this figurehead that needs to shepherd the project through to completion and make sure people are implementing things in a sound way architecturally.
On top of that, you have to deal with cross-functional stakeholders. You have to explain why you’re making the decisions you’re making and negotiate with different business stakeholders on the priority of tasks and projects.
What are the different types of tech lead roles that are currently out there?
You can really split them into two different taxonomies.
One of them is the technical architect track with a little bit of project management and stakeholder management built into it. These are leads who are going to be leading projects and making sure things are on track, but not actually managing people.
The other is more like tech lead managers, which I find is a little bit more common in startups since you’re a little bit more strapped for capital. You don’t have the capital to have an engineering manager and a tech lead for every single scrum team or team of engineers working on a specific product.
In addition to this non-managerial role, the tech lead manager is also managing all of those engineers and dealing with their interpersonal problems and any personal issues you would generally find an engineering manager specializing in.
That can be pretty rough sometimes depending on how many engineers you have on your team. It’s a lot to bite off there.
If you find yourself in a company where the tech leads are also managers, I consider those two very different skillsets. Sometimes people have both, and sometimes people like both, but oftentimes the people who love developing engineers and seeing them progress aren’t the same people who are going to like going deep on a problem and expanding the system in a specific way. They’re generally two different career tracks.
We’ve seen the positions be defined differently based on what stage the startup is in.
There are certain times when a small, early stage startup doesn’t yet have a CTO in place. Instead of a CTO, they might actually need more of a VP of Engineering who is still a hands-on lead engineer because they’re not managing a large team.
I’ve seen that role also titled as Founding Engineer. Founding Engineer generally means you’re either the first engineer or you’re the first lead engineer. You’re really not the CTO, but you’re driving all of those decisions. That can be a lot more work than people are prepared for.
What are some of the intangible requirements of the role that may not be obvious?
I think of these the same way I think of a sports team.
When you’re naming captains of a team, which is how I consider lead software engineers, you generally want someone who can face adversity without letting it get to them.
As a tech lead, regardless of whether or not you’re a manager of the engineers, you’re a technical leader at the company. The way you react to adversity is the way all the other engineers are going to react to adversity as well. It’s something you really need to practice and work at.
It’s not necessarily something you think about when you’re jumping into the role. But the way you react to stimuli will definitely impact the rest of the engineering team, regardless of whether or not you’re their manager, because they look to you for that inspiration and leadership.
