What Makes a Team Lead Great?

“Well, don’t you think that you as the commander have an obligation to create a vision for your command?” It was more of a statement than a question. “No, I feel that my job as the commander is to tap into the existing energy of the command, discover the strengths, and remove barriers to further progress.” The class supervisor looked at me as if I had three heads, but I knew he wasn’t going to fail me. - L. David Marquet, Turn the Ship Around

Ender's Game (Orson Scott Card) is one of my favorite discussions of leadership styles. It's basically a story designed to prove that small independent teams beat large top down teams every time.

Card might disagree with me about this, but you have Ender using independently managed small teams, to defeat traditional military hierarchy in Battle School, and then going on to defeat a hive mind (perfect top down control). That seems like one of the core thesis of the novel to me at least, and as a youth I loved that message. It's been with me ever since.

Within it's pages we have several different archetypes of leaders. There are emotionally abusive leaders, there are domineering leaders, there are humble leaders, there are incompetent leaders, there are excellent leaders, there are emotionally immature leaders. It's got as many types of leaders as you will meet in your career. From Bean who takes the backseat and guides things indirectly, to Achilles who dominates everyone around him.

Which one are you? And, for those of us that lead teams of teams, how do we know which one our leaders are?

The main answer is likely using something like a 360 review regularly to gather sentiment from the people being managed. You don't want to keep an Achilles around.

Now that we've cleaned out the Achilles though, how do we know which teams are happy, satisfied, and performing? How do we know which leaders are not only reasonably adjusted humans, but actually creating good teams?

The List of Measures

Here's the list, and then we'll discuss them in greater detail:

The Team:

• Ships things on time with minimal crunch time and stress. It should be boring.
• Has stable/increasing throughput
• Sets and achieves sprint goals
• Takes ownership of their quality and product
• Is engaged and understands what is expected of them
• Is learning and growing
• Team members can, and do, take vacations

The Leader:

• Understands the next steps for their team members in their career development
• Maintains reasonable individual throughput
• Is not running all the feature projects
• Can speak to the projects the team is working on, both technically and in terms of progress
• Is not taking blocking tasks (unless carefully considering trade offs)
• Team receives promotions in a time correct manner
• Can, and does, take vacations
• They care about their team members

The Team

So how do we measure a team? We're not going to get into how do we measure an individual developer, because for our purposes that level of granularity would actually be negatively useful. With a few small exceptions identified above.

If you are a team lead you should ask yourself if the list of items above is true for your team. Even if they are all true, the exercise will likely identify some areas for improvement for you and your team.

As Will Larson says... if you aren't measuring anything yet SPACE and DORA are the easy places to start. I tend to agree. SPACE will likely lead you to a similar list to the above points, and is a reasonable, if frustrating, framework for measuring engineering performance.

But let's talk about the items above.

Ships things on time with minimal crunch time and stress. It should be BORING.

When I was a teenaged in Austin, TX the dominant group of software developers in town were game developers. Game companies paid well, but were notorious for what we would today call death marches. They would work long hours, nights and weekends, as the ship date for a game approached.

That is what you want to avoid.

Delivering new code to production should happen often, and should not be a BIG DEAL. It should be boring, both in that it requires no special stress, and in that the team can be confident in the quality of what they are delivering.

Has stable/increasing throughput

The dreaded velocity talk.

Velocity is an imperfect measure.

But is is a good proxy for a lot of things if you use it in a reasonable way.

A reasonable way, means not comparing across teams, because no two teams will estimate the same way. It also means don't take it as the end all be all of the metrics. It, like all metrics is just the beginning of a conversation with the data and the people.

But as such, a team should be increasing in their velocity, or holding flat. This makes an assumption that the team size and makeup are stable. In the absence of that you might want to look at this as an average across the team members instead of the whole number for the team.

Sets and achieves sprint goals

The team is focused on what is most important and knows what that is. The purpose of a sprint goal is to guide prioritization of work, and the order that it is picked up by team members, and to provide a dopamine hit to everyone when they are achieved at the end of the sprint. They should be achievable THIS sprint, not next sprint, or the sprint after. They should be concrete with little wiggle room in them.

Missing them shouldn't be a huge deal, but it also is important to the well being of the team long term.

Takes ownership of their quality and product

Engineers, and engineering leaders, own quality. You may have a QA or SET team, but they are not there to catch your mistakes. They are there to assist you in proactively catching your own mistakes. Ultimately we are responsible for every line of code that goes to production, and no other group or team shares that responsibility.

Is engaged and understands what is expected of them

Teams that don't understand what is expected of them, are teams that aren't going to be very satisfied, and certainly aren't going to be growing in meaningful ways. Engagement can and should be measured organizationally, but team leads should know who is, and isn't, currently feeling engaged without them because of their proximity to the team and the work.

Make expectations clear in roles and in projects, and your team will be happier.

Team members can, and do, take vacations

This seems simple... but is actually complicated and important. Do team members feel like they have to carefully schedule vacation around projects? Do they feel like they can't take vacation because of the work that they are doing? These are symptoms of knowledge silos, or responsibility silos that indicate a team that is not functioning in a healthy way.

People need vacations, and the team should function fine without them being there, and without needing to page them/call them in the midst of their vacations. Make sure that enough people know enough to make that happen.

The Leader

Let's talk more about the team lead now. The engineering leader.

It's harder to measure in some ways, but ultimately it is a function of looking at the aggregate data of those managed over time, a 360 like review on a regular basis, engagement surveys, 1:1s, and skip level 1:1s with their team.

If you are a leader of leaders you own the task of making sure this is happening. If you are a team lead, ask if this is happening, and if not do some of this on your own, or ask your manager to engage with it. This is important for your growth.

Understands the next steps for their team members in their career development

Do you know what the long term career aspirations are for your team? Do you know what they need to do to get to the next step on that path? If yes, awesome! If not, you have work to do.

My rule of thumb is that team leads should be having quarterly career conversations with the people that they manage. It's a good starting place and you can easily adapt from there.

These should be separated from 1:1s and focused just on career growth. Help them figure it out, share insights, find them mentors in your network, do whatever you can to help them progress in their careers.

Maintains reasonable individual throughput

As a team lead, you are still contributing to the daily work of shipping code. You should be in on-call rotations. You should spend at least 40% of your time shipping code¹.

You are also not just doing code reviews. You are writing and reviewing code. Share the load on code reviews so that others can grow, and so your team isn't deferring to you all the time on technical decisions.

Is not running all the feature projects

Speaking of deferring to you on technical decisions. Running feature projects is often the job of the lead. You should delegate it often. When you delegate it to a non-senior engineer this is a great opportunity for mentorship, either from you or another more senior engineer on your team.

Your senior engineers should be able to break down a project with little assistance, once your team has settled on what that looks like for them.

Can speak to the projects the team is working on, both technically and from a progress perspective

You know where projects are, and what is left in them. You know how they are being built, and why they are being built that way. Beyond that you can articulate both of those points well for your manager, and for other interested parties.

You should likely be talking about this in your larger organization meetings, as a way to get exposure, and hone your presentational skills if you are looking to continue growing up the management ladder. If you aren't, ask for it.

Is not taking blocking tasks

Just don't do it. If there is a really really cool technical problem, that is also a blocking task for the rest of your team... it isn't for you. Give it to someone experienced in that area, or fairly senior. Let them have it. It will be ok, honestly it will be better than ok.

Why? Because they aren't going to randomly get pulled into a meeting with stakeholders. You are. They aren't going to get called into HR to help with a random employee issue on your team. You are.

You should take tasks, just not tasks that get in the way of other folks on your team getting their job done.

This is hard, but so so important.

Team receives promotions in a time correct manner

Honestly I am still trying to articulate what this one means in concrete terms. The idea comes Turn The Ship Around by L. David Marquet but is harder to articulate outside of a military environment. If your company has clear expectations around the rate at which engineers should move through the levels of the organization, then this is easy. If you are trying to define the rates, good luck. It's important work, but takes a lot of upfront effort.

Assuming that it is done, and that the expectations for each level are clear, then look at your team and see if there is anyone lagging behind. Why are they lagging behind?

It's possible this is your responsibility to correct. I have had engineers who were fantastic, but hard to promote because the work that they did was hidden, and the organization's promotions practices made it hard to demonstrate the level of mentoring and pairing that they were doing. In that case it was on me to spend the time, prepping my manager, and finding the right way to tell the narrative to open the door for them.

It's also possible that they are under performing, which is also something you need to address. Just in the opposite direction. Instead of a conversation with your manager over time, this is a conversation with them. A clear, direct, conversation that sets expectations, but also delves into the causes behind the low performance. It may be that they have real things going on outside of work, that require support. It also may be that it is time to help them find other opportunities either in, or out, of the company.

If that is where you find yourself, then it is time to take that to your manager also.

Can, and does, take vacations

This one again! Does the team lead take vacation? Does the team function well enough without them? A well run team will function fine without it's lead there while they take needed vacations. This is not an argument for getting rid of team leads. It is just an argument for empowering a team so that it functions well without a lead present all the time.

They care about their team members

The best for last. But also probably the shortest.

Leaders must care about the people that they are leading. Creating an emotionally safe team environment, and ensuring that your team feels supported are some of the most important things you can do to create a high performing team². Creating this safety results in "higher levels of engagement, increased motivation to tackle difficult problems, more learning and development opportunities, and better performance."³

There are some really good insights into this in the footnotes, and you should spend some time reading those articles to understand how to create safety for your team.

You are probably going to need to do some work on you as part of this.

Understanding your biases, and doing the work to minimize them is important. You likely need some support here, and mentors and therapy should likely be part of your regimen was a leader.

So is just listening to your team. You don't have to fix everything for them, but you should be willing to hear about anything that is on their mind.

But really just care about them. They're people with hopes and dreams just like you. Support them, look out for them, help them, and be honest with them.

Now go do it

Always easier to say then to do.

There is a lot here, but hopefully it helps you have some ideas for areas that you can do better, or at least that you can be more aware of as you go about your day.

Being a leader can be extremely rewarding! Watching someone grow, and change is one of the most rewarding things that you can be a part of in life, and to lead is to engage in that process every day with your team.

Ground your leadership in data, focus it on the people through empathy, and take vacations and you'll be well on your way.

If you enjoyed this article please share it! Also, I have a newsletter that you might enjoy as well. Thanks! -Daniel