As an engineer who is primarily responsible for shipping code, taking the step towards technical leadership can be daunting. Every organization has its own spin on what it means to be a tech lead, as will you, and navigating this on the fly can be difficult.

In January, we launched a new team to build out our “Status Pages” product. This was the first time we’d split out a new team to create a totally greenfield product. It was also my introduction to being a tech lead.

Naturally, I expected to be leveling up my comms, my planning skills, and other things typically associated with tech leadership. In reality, I found that some of the most difficult things were challenges I hadn’t considered at all.

What does it mean to be a tech lead?

The definition of a tech lead can vary across organizations, and lines are blurred with other roles. At my company, my primary responsibilities include the following:

• Ensuring we’re shipping what we’ve agreed to, quickly and with quality
• Monitoring the technical landscape of our team to identify the key technical investment necessary to ship product faster, making sure it’s done at the right time
• Working with tech leads across teams to tackle issues that are slowing down the engineering team
• Being the first port of call if quality feels off, pace feels slow, or technical decisions have been miscalculated

Decisions at pace

Pace is the number one priority for our engineering teams. We think of pace as value delivered at speed, and we’re always optimizing for this.

For me, the most important driver of pace is knowing how to gather the right level of information, make the right decisions on the fly, and ensure the right people know about it. The way you make decisions varies from organization to organization, depending on appetite for risk and existing processes – and it takes time to grasp this as a new joiner.

Getting this wrong will cost you a lot of time

Spending too long on minor issues means you’ll waste time making decisions by committee and over-documenting things. Just winging the big decisions means you risk backtracking large pieces of work and having difficult conversations.

To mitigate these instances, triage the sort of decisions you make into three separate categories:

1. Just do it: These are low-stakes calls that you can make alone or run by the person you’re sitting next to. You’ll assume it’s correct and wait to receive feedback in a pull request or design review.
    
2. Make progress, but create space for input: This applies to slightly larger decisions that will impact your wider project. They should be easy to roll back if necessary, with an impact limited to the project itself.
   
   For these, you’ll want to write up a quick summary in Slack, detailing your preferred choice with a quick reasoning for your decision to give context. Give people the opportunity to disagree with you, but move forward with your plan in the meantime to make progress.
    
3. Requires explicit approval: These are the biggest calls you’ll make within the scope of a project.
   
   Decisions such as building or buying a solution, significant changes in scope, or calls that will have a large impact on dev experience or customers.
   
   For these, you should write a proposal that outlines what the project entails and why it is important for the company given the business context. Invest the time to be extremely clear and precise.
   
   You should clearly outline your preference, but also describe the alternative options and weigh up the pros and cons of each, helping to provide all the tools people need to make a decision quickly. If you are part of a smaller company or startup, you’d normally bring in founders for these decisions and pause work until a decision is reached.

Steer your team on these decisions

You’ll likely have had a good internal gauge for categorizing different types of decisions into the framework outlined above. 

If you’re not sure whether your triaging system aligns with that of your organization’s, I’d recommend explicitly calibrating with your manager, and writing down the product decisions you think would fall into each category.

You’ll now need to be able to clearly articulate why you think about certain decisions in a particular way to your team, just going by gut feel isn’t enough.

You are in the best place to spot when someone in your team is mismanaging decision-making. This could look like being afraid of making minor decisions without more senior input, or on the other hand making major team decisions without getting your buy-in. You should actively think about how your team is doing here. Getting this right ensures other teams across the business trust you and your team members, also assuring senior leadership that you'll loop them into the decisions they care about. It’s important to articulate your framework clearly when correcting your team on these calls, it will give them the tools to make informed decisions going forward. 

Delegating differently

Having led projects before, I felt pretty comfortable delegating work to engineers, including tickets, project areas, customer comms, and document write-ups.

But it’s so easy to fall into the trap of overcommitting and trying to do everything in order to learn. I wanted to take on stand-ups, weekly planning, important projects, cross-team comms, and also be in all the meetings that were now relevant to me.

Whilst all of these things are new and exciting, doing them all at once isn’t effective. 

In reality, the most important part of your new role is collaborating effectively with your engineering manager and product manager, using your collective skills rather than going at it alone. Not only will this help you do a good job, but it will reduce the likelihood of burnout. 

Trusting this leadership team to involve you in key decisions at the right times (and vice versa) is crucial for your relationship and important to talk about.

How do you set this relationship up for success?

1. Outline your default plan: Write down your collective and individual responsibilities as a group. Who is responsible by default for each of your regular tasks? What are the key decisions or topics to loop each other in on?
    
2. Break your plan: It’s really important that you have a clear idea of what responsibilities fall on you, but it’s just as important to be ready to flex them. You all have your specific skill sets, but you can probably have a good stab at some of your engineering or product managers’ responsibilities if things go pear-shaped and vice versa. Be ready to shift your plans to adjust in response to whichever one of you has the most on your plate.
    
3. Communicate early, clearly, and often: Actively find time to spend together on a regular basis to quickly check in and understand each other’s workloads and energy levels. Having a constant stream of communication means you can adapt quickly to reactive work and know who is best placed to tackle things.

Lean into feedback

Whilst giving feedback and maintaining a culture that encourages this is everyone’s responsibility, I’ve had to push myself to be more proactive here as a tech lead. In this position, you’re in the best place to notice what’s working for your team and what’s not. You’ll need to lean into providing that feedback, often in unsolicited scenarios, to make sure everything is running smoothly.

Additionally, it’s really important to ask for direct feedback from your team on a regular cadence. Here are some examples of questions I have asked to gain useful feedback in my first few months – the more specific, the better. 

• When I delegate is it clear what the task is and why I am doing so? Are there any tasks I do that you think I should delegate?
• How could I help us go faster? Do I encourage you in a way that energizes you? Does it ever feel stressful?

• What do I do that is good for team culture and morale? What do I do that is bad for it?

First-time tech lead? Be patient with yourself

Becoming a tech lead means doing a lot of things for the first time. It’s really important to give yourself the space to learn by temporarily stepping away from the things you find difficult or draining that aren’t part of your new set of responsibilities. Part of your role is delegating – do that, and prioritize the team over your individual delivery.

It can be unsettling to be shipping less to customers as an individual. Your internal am I doing a good job gauge needs to shift away from how much code you’re writing, and towards what your team’s output is.

It’s easy to worry that you’re permanently stepping away from a more technical track, and losing the opportunity to be hands-on with deep technical challenges. In reality, all new experiences and lessons are incredibly useful, regardless of whether you want to remain on the technical track or not. This position will only make you a better engineer. It’s useful to frame tech leading as a hat you can wear for a while, not necessarily a permanent decision that will force you to move away from more hands-on engineering. 

I love being able to have a tangible impact on my team and our direction, that goes beyond the code I ship. It has allowed me to double down on things I was already good at and share them with my team, like making quick, tactical decisions with the right level of comms.

Final thoughts

Moving from the role of a software engineer to a tech lead can be a challenge. But, with perseverance and support from your peers, the journey can be both smooth and rewarding.  

Along the way, you’ll need to master decision-making at pace, delegate effectively, and communicate openly. Remember that people don’t expect you to get everything right the first time, but you’ve been chosen to do this role because people trust that you can get there. Give yourself the time and space to develop your own flavor of tech leading that works for you and your team.