Understanding the role of tech lead

I was nervously excited when I landed my first lead role. Previously of course, I had been led by many different lead developers. Each with their own way of operating. I knew what I had been brought in to achieve as a lead in this new role, but it's one thing to watch and another to do.

Now, after having done multiple tech lead roles it's clear to me what it means. The things you should focus on, and the things you should let go. I feel like I could write endlessly on this subject, so I've distilled my knowledge and experience into four sections. Managing the team, leading 'team-first', understanding process, and delegating work.

Managing the team and team members

Individuals

You should try to understand the strengths, weaknesses, and impacts of every single individual in your team. In order to do that, you need to build a relationship. That's what your one-to-one meetings are for. There is no one size fits all approach to how they should be conducted. I have a loose script I follow if there's a silence, or if it's a new team member that I'm beginning the relationship building process with. However I normally just listen. As the lead you're looking to understand how this person fits in to your team and where they're wanting to go with their skillset. Are they currently looking to bolster a specific skill? Are they coasting? Are they having problems with another team member? Your role here is to facilitate and adjust as necessary. Facilitate giving them the opportunity to bolster that skill they're wanting to. Or adjust their work load as needed. Perhaps you just need to listen to their frustrations so they feel heard. If you want to get the best out of someone, they need to feel like you have their best interests at heart.

The team

At first you're just going to have a group of individuals. Part of your role, is to shape them into a team. Since you're the leader you need to set and model the example of how the team operates. That means you need to focus on how you talk and interact with everyone involved in meetings with your team. For example, if you become snippy in meetings with another team or individual within your organisation. Your team may believe that's also okay to do. They could also be sitting in silence, uncomfortable at how a coworker is being treated. I think it's worth taking a step back and identifying how you want the culture to look. For example, I want to be in a team that is willing to ask for and provide support. So I offer it, constantly. Importantly in meetings and public forums. Because of course I want to help and secondly because that is the culture I'm wanting to build. Lo and behold, it will take shape. Others will follow the example you're setting.

Facilitating positive team bonding should be something you're getting the team to spend time on too. Does your team, or team members within it have the opportunity to bond and build a relationship with each other? There's many ways to help provide it. The best is hidden right under our noses, peer programming. Especially when you're a remote team, this is massive. We are all here to do a job at the end of the day and I like to think we're all doing our best at it. Setup and encourage team members to peer program with each other. When somebody raises a problem, instead of just writing paragraphs to and fro jump on a call instead. Perhaps even nudge a different team member to provide support, give them the opportunity to bond.

If you want to kill two birds with one stone. Once you've built up a knowledge of each team member's strengths and weaknesses, organise peer programming between team members where either one or both of them have something to gain from the other.

Something to keep in mind as well when either joining a team or having members join or leave is the 'forming-storming-norming-performing' model or process that naturally occurs. When a new person joins your team, how do you facilitate them building up working relationships with everybody else? And a reminder that you'll need to weather the 'storming' phase, this is where real decisive leadership is most crucial. Don't get discouraged, it is difficult.

Leading 'team-first'

My personal philosophy when it comes to leading a team is leading 'team-first'. What I mean by that is the decisions are made by the team, where I'm just another member. There's no ivory tower where I'm shouting orders, instead we're in meetings and voting in polls on the choices we want to make. I believe leading 'team-first' promotes autonomy within the team and creates a more dynamic environment. I may have an opinion on why we should go in a certain direction or make a particular choice, however it's on me just like it is every other member to create a compelling argument for it. At the end of the day, I'm not always right and there's no shame in that. It's part of how we as a team build each other up. I may outline a path however another team member may quite rightly provide a better one, in that scenario we all win. I learn and the team makes the better choice. As a result discussions can be more lively, well researched, and good natured.

"We're all in this together - we're a team"

A phrase I quite often throw out there during meetings. Our choices don't rest on any one person's shoulders, but rather us all.

There are only two scenarios where I may overrule the team's choice. That's when either performance or security is a concern. Security isn't something to be taken lightly, the impacts can be devastating for the wider business. It's not acceptable for it to be lax, or lapse. Performance too. Ultimately the product or service we're providing should be performing the best that it can. That means catching and handling errors correctly all the way to serving requests as fast as possible. Thankfully, it's rare that either scenario rears its ugly head.

Delegating

This is what I've struggled with the most in terms of understanding what this truly means. It's not just splitting up work and handing it out. It's also bringing people along on the journey. There should be no one person who is irreplaceable in a team. Because that, in other words, is a bottleneck. It was a mistake I made when first leading teams. I accidentally made myself into a bottleneck as I defaulted myself into being the person taking on the harder, more challenging work, leaving the rest to the team. I thought I was doing them a favour by getting it out of the way and making their job easier. However, it turned out they also wanted the challenge and I was depriving them of it. Yes albeit constructing the pipelines for our builds isn't the most glamorous work doesn't mean that there isn't somebody on the team who would like to do it. Because they enjoy it, or perhaps because they haven't done it before. The latter option, where someone hasn't done it before is important too. It ties in both delegating and knowing your team members. As a lead you want to provide team members opportunities of growth along with bringing them along on the journey. Kill a few birds with one stone, set up a peer programming session and work through the build pipeline together. With your team maturing they will also help divide the work up, and perhaps even put their hand up to tackle it. Which leads quite nicely into...

Being process orientated

Everything requires some sort of process to be followed, nothing gets done without it. Take for example your average Software team work flow. Requirements are created, they're agreed upon by stakeholders, then brought to your team. Your team needs to understand how to meet the requirements. Along with reviewing the work that's been made to meet it. It may also require some design or product review too. Then it can be released. At a high level, it sounds simple. But..

• What does your team need to know in order to accept work?
• If your team doesn't have what they need, whose responsibility is it to gather that clarity?
• How is work distributed to your team?
• If somebody wants to work in a particular piece of work, how they can earmark it?
• How does work get reviewed by your team?
• How are team mates made aware that a review is required of them?
• How does the team go about receiving these reviews that are external? (Think design or product review)
• How is this work then released for external consumption?

I know it's trite, but it's a factory line. Raw requirements come in, your team's process pushes it along the conveyor belt, then it's released for consumption. Your role is to help facilitate identifying what is and isn't working. For example, if team mates are constantly waiting for reviews you'll need to investigate why that is. Is there an improvement that can be made to the process? Perhaps a new column for work 'in progress' on your board, that way it's easily visible for everybody? Perhaps having reviews automatically assigned creates the accountability that's needed?

Putting the day to day concerns to one side. If a new team member were to join, how are they to understand the process of how work gets done? Do you have documentation to explain what the processes are, and how to do them? Matter of fact, do you have documentation? On that note, what about the process of your team implementing the work? Are there patterns, ideas, and rules that are being followed? Is that being documented for all to see?

Process is all an all encompassing concern. It's important to be clear over how your team works with others, along with how your team works internally. Although documentation costs time and can be dull - it pays dividends in structuring how things work regardless of who is doing it. Just as an example, if there isn't documentation on how to manage a release and the person who has been doing them is out of office. The release isn't happening, or at least, not smoothly. There's also the added benefit of being clear on expectations, you can share your documentation with team members and other teams as necessary. If you get asked "How can I report a bug?" You can follow up with a link to your documentation.

On a side note, documentation that relates to programming should live within the repo. It's a living document and all that, however it's also just that much quicker and easier for the team to update as required. Reducing barriers improves process adoption.