After 2 years in the role, I'm moving on from my position as a Technical Lead at Redgate Software. I'd like to share my reflections on that time, which I hope will be particularly helpful for new tech leads.

The tech lead role varies across the industry. At Redgate, it's a mix of line management, along with individual code contributions (when you have time). With that in mind, here are the top 5 things I learned as a new technical lead.

Enabling others to execute is now your job

As an engineer, you're mainly an individual contributor. Your performance is based on the things you do directly every day, which is mainly writing and reviewing code.

As a technical lead, things are different. The more you focus on completing tasks yourself, the less effective you'll be.

I've found that for a tech lead, your primary focus is all about enabling your team to execute. Your output is now the sum of your team's output. If they're all doing a great job, then you are. And if they aren't, well... then you aren't.

Ironically, as the team leader, you now have less direct control over how tasks are executed. It's up to individuals on your team to chop through the work - so they'll decide how to go about things.

When things go pear shaped, the temptation is to dive in and start fixing things yourself. However, leading like this is going to leave you overwhelmed and burnt out.

You have to trust your team to execute. Get off the critical path, and delegate as much as you can. If you aren't confident anyone on your team can deliver, then you need to start skilling people up rather than diving in yourself. You need to teach, train, coach, or mentor your people to be the heroes of the story.

Leadership is a skill, not magic

What do Augustus Caesar, Steve Jobs, and Atilla the Hun all have in common?

I have no idea - other than they were all leaders.

Some will have you believe there's some magic talent that unites all great leaders.

I've come to believe that's mostly nonsense. There's no secret sauce. I believe that leadership is a skill that can be learned.

Leading consists of concrete and well-defined skills - delegating, coaching, mentoring, presentation skills, business knowledge, technical knowledge, project management, defining goals, and so on.

There are many ways to learn these skills - books, courses, podcasts, or just having a go and reflecting on the experience.

I can recommend these resources to start with:

• The Manager's Path
• Good Strategy Bad Strategy
• Radical Candor

I may follow up in future posts with more thoughts about these books.

It's critical to understand people's roles

As an engineer, I only really understood what other engineers did. Product Manager? Product Marketing Manager? Development Lead? Pre-Sales Engineer? Uh...

As a tech lead, a bunch of people with unfamiliar roles are suddenly your stakeholders. I found it was critical to get up to speed with what these roles meant.

You need to get a sense of what their priorities are, what you can expect from them - and what they expect from you.

How you manage your relationship with people in each role must vary. For a direct report, like an engineer on your team, you have a right to shape what their role looks like to some extent.

For instance, if you think it's reasonable for a senior engineer to facilitate a team retrospective, then you can tell them to do that (whether they'll be willing or able is a different story).

For your peers, it's trickier - you can't just tell them what to do. You have to think about how to influence them, and conversely, you must be reasonable and sensitive to what they want out of you too.

Your Product Marketing Manager wants the team to write a new blog post for the newsletter every week? Ok, let's set some expectations about how much of the team's time I'm able to commit...

Given the array of roles you'll need to get to grips with, it's easy for mis-alignments to creep in. You'll need be pro-active in learning. There's no harm in grabbing someone for a quick chat just to make sure you're on the same page.

Get used to awkward

Disclaimer: Maybe I'm just a particularly awkward individual. However, I've found that as a tech lead (particularly doing line management), you're going to have some awkward conversations.

Telling people 'no' is awkward

Dealing with resignations is awkward

Delivering difficult feedback is awkward

Facilitating meetings with too many people and no one is aligned is very awkward

The list goes on. However, this is something you need to get used to.

It's the 'people side', right? The bit no one likes about the job. Doing this well is hard, and I wouldn't say I've quite cracked it.

You have to take such awkwardness on the chin. Be professional and gracious. Don't take it personally - it's not a reflection on you if you walk away from a meeting feeling a bit weird.

The more you have to deal with awkward stuff, the sting of cringe will begin to numb. You'll be more used to it, and eventually, maybe you'll just figure out how to deal with it.

Outcomes over everything

Finally, I've realized that outcomes are everything.

In tech, we're privileged in that ultimately we're employed to deliver business impact, not just meet some output criteria.

That's in contrast to some jobs that are very output focussed - say a Deliveroo driver who is paid in proportion to the number of meals she delivers.

In traditional manufacturing, the 'business' and 'production' aspects are probably more separate than in tech. For instance, when Ford executives decided to build the Edsel, it was just a case handing the design to the workers and cracking the whip on the production line to make enough cars to meet demand.

Tech isn't like that (or at least it shouldn't be). Things move way too quickly, and meeting user demand isn't a case of just outputting more units.

In tech, one small team with a sharp focus and good business understanding can have a massively outsized impact. Just look at companies like Basecamp or Slack - a few dozen to a few hundred engineers impacting millions of people.

Therefore, your work really needs to be measured in business impact. The 'outputs' of an engineer (lines of code written, commits shipped etc) aren't really a good proxy for value at all.

So, as a tech lead, I've learned that you need to steer your team to deliver on business impact, rather than meaningless metrics of productivity.

This is of course really hard. There are many approaches used in industry - Objectives and Key Results is the format we used at Redgate. It takes alot of collaboration with your team and stakeholders to zero in on valuable work.

I've written other posts that go into more detail about this. I'm sure it's a lifetime of learning to get even remotely good at this.

Summary

So those are my tips from 2 years of being a technical lead at Redgate. I'm thankful for the opportunity I've had to lead an engineering team. It's a great experience that will challenge and grow your skills like nothing else.