Team leadership for high-performance teams

I've been working in developer leadership roles for the past 15 years. Over this time I've been noticing that, when some magic conditions happened, a few of the teams I was leading became amazing places to be. Some other teams always failed to shine. Over time I called the successful ones "dream teams", but over time I realized that what I was encountering was the mythical "10x", "rock star" team in real life. If you follow many developers on social media, as I do, you will find this is a rare occurrence, but nevertheless, it does happen regularly.

I have been spending a lot of time thinking about how to perfect the skill of creating such a high-performance team, and these nine qualities seem to be good predictors of what makes a team a 10x, high-performance team. They are easy to explain, but hard to achieve.

Teamwork

It's of the highest importance that a team act as a ...team and not as a group of individuals. Achieving a team objective is a matter of working organically and not as separated individuals. For example, when the team is faced with a group of work items to deliver, they will distribute them in order to achieve all of the items and not by having people pick something with no sense of responsibility for having the whole lot delivered. While people might deliver individual stories, in methodologies like Scrum it's teams that deliver sprints. "The team failed the sprint, but I delivered my stories" is meaningless. If the boat sank, it does not matter your corner had no leaks.

High-performance teams act as teams.

Negotiation

High-performance teams delay work until the last responsible moment. In particular, they do not work with a set of stories which are pre-written and prescriptive. This has numerous advantages, as of course, it's work not done if the stories are delayed or canceled, but it's also good because the amount of knowledge the team has on the project is a monotonically increasing function of time: every day that passes they know more, not less. So plans, estimates, architectures postponed by one day will be based on more information and because of this, be better. This is one of the key ideas of agile development: in waterfall, everything is decided months or weeks in advance and this makes change extremely expensive.

High-performance teams negotiate scope up to the last minute.

Focus

A high-performance team has focus ideally 100% of the time. Everyone should always know exactly what to do, why, and how to choose what to do. The job of a product development team is to negotiate how to deliver a story and build it. In other words: deliver story points (or stories, or PBIs). As I said above the team needs good teamwork. This is one of the desired effects of it. People should not be uncertain about what is expected of them right now. This makes them unhappy, because they are guessing stuff that they shouldn't be, and because they are not being productive. A team lead and/or scrum master should constantly verify that the team has focus.

High-performance teams know what they are doing and why.

Value

Your team should know the value of what they are delivering. Their job is to maximize the throughput of that value. Unless every story is perfectly clear on its value or this cannot and will not happen. Don't rely on a product owner to prioritize things for you. Expect the product owner to explain and champion the value of stories. Interact with them daily, hourly. Their job is to represent the user or customer and your team's job is to make the user or customer happy. The happier the better.

High-performance team maximize delivery of value.

Happiness

As you build high-performance teams, you need to foster a culture of high-performance individuals. This, of course, goes through selecting the right mix of candidates, but once you have your dream team, are you sure it's a dream team for them and not a nightmare team? You should always ensure that your team members are highly motivated and overall happy. There are many ways of doing this and most of them are basic: give them emotional support, listen to them. Some of them are a bit more subtle: give them a strong direction, set clear expectations and support to achieve them. Some of them are even unexpected: send them off to do stuff that improves their skills, encourage them to attempt risky things and stretch out of their comfort zones. Not every developer is the right fit for this kind of team, and this is a fact of life. You need to find people that truly love their craft and are willing to constantly grow professionally. It's OK not to, but then perhaps a team where this is the norm is a better fit.

High-performance teams are happy.

Performance

This is obvious, right? High-performance teams focus on performance. Duh. Except somehow there's the expectation that you can achieve high performance even if you don't.

• Are all your tools as fast as possible? Is your team spending time maintaining them and making them faster?
• Is your code as fast as feasible? Is it being constantly monitored and improved?
• Are your CI/CD tools lightning fast? Are you measuring and minimizing the off-time spent on compiling code?
• Are your tests minimalistic and fast? Are you constantly working on new ideas on how to improve that?
• Is your team focused on how to deliver more and faster? Are your retrospectives useful?

All of these things are fundamental. All of these things are fundamental. It's a mentality thing. You can either grow faster and faster or slower and slower. Not bothering means you are slow. Get fast.

High-performance teams minimize the cost of features for themselves, for their company and for their users.

Agile

We all screw up, we all operate in a lake of unknown unknowns. As such we either adapt or we will eventually fail hard. So - mistakes are corrected, without blame. Mistakes are learning opportunities -- in fact, you basically only learn through errors! Successes are terrible teachers. As such, recognize that there is very high value in changing your mind if you were wrong. Once you know that making mistakes is going to happen, then the speed of adaptation is what matters, not correctness. Nobody cares that you are "right" if you fail. So: adapt. This is agility.

High-performance teams embrace change and do not minimize it.

Non-rules-lawyering

Sometimes people get stuck in "bureacratland" where everything is difficult and long-winded. They spend more time doing stuff of little practical value, or little common sense, but of high in-company value. The company might officially value those TPS reports, but they are of really low value to the company. Delivering that story would be better. Of course, if your company is a hyper-bureaucratic nightmare you will never be able to have a high-performance team unless you change that. Based on personal experience, it's probably easier to find another job though, just being honest. Companies are super-hard to change. In any case what is most important is that a team be a force for good, focused on being pragmatic and low BS.

High-performance teams value pragmatism over rules

Ruthless

It's super common nowadays to hear that teams practice "collective code ownership", but in most cases, this is just a catch phrase. People should be able to openly criticize code without offending the author. We all write bad code, and we are all here to make it better together. Highly performing developers know this fact, they are good at their craft and expect everyone to be good. This is a positive trait and should be encouraged -- not in the toxic, blaming-people kind of way, but with the happy knowledge that we all put out work that can be better and that we are all learning. There is no need to be personally defensive.

High-performance teams are ruthless on the code but kind to people

Marco's test for high-performance teams

In the spirit of Joel's test, here is Marco's test for evaluating your team for performance qualities:

1. Does your team achieve goals by working together?
2. Does your team negotiate scope during development?
3. Is your team focused on delivery 100% of the time?
4. Does everybody know what value they are delivering right now?
5. Is your team happy?
6. Do you constantly measure and optimize performance of all aspects of your team life?
7. Does your team welcome and embrace change?
8. Do you have rules lawyers?
9. Is your team brutal on code, and this does not upset team members?