Five things I did to build a killer team

Video Transcript

Why do some teams perform better than other teams? Why do some people inside of those teams perform better than other people? And why do some organizations know how to build teams while others just don't? Ooh, this is going to be a big one.

Uh I don't have all the answers, but I want to tell you a story about how I fixed a team [music] and built a dream team that I wanted to work with. There's also a secret number that I'm going to tell you about that I think you need to know about when you're looking to join a team, build a team, or work in a team. So, let's get into it. Chapter one, process, process everywhere, but no decisions to make.

A few years ago, I joined a fintech business in South Africa, and I was hired to come into the team as a senior product manager and basically fix a team that couldn't ship. We were building something extremely complicated and heavy. We were trying to build an entirely new design system for this company, and we were trying to build an entirely new app ecosystem that every feature needed to be moved into. The team was struggling to deliver.

It was 18 months into the project. They weren't shipping. The designers were waiting for the engineers. The engineers were waiting for the designers.

Everybody was waiting for instruction from senior management who was frustrated that there was no progress. Does this sound like your team? Well, then I think it's important you stick around so you understand why this is happening and how to fix it. I joined the team, and the first thing that I did because I am not traditionally trained in product management or corporate speak is I asked them what their work days look like.

I sat for a couple of weeks, and I just watched them all work. And there was one clearly obvious thing. They were too far apart as humans and individuals, and they had over-processed their work life, so we had daily stand-ups, we had sprint reviews, we had retros, we had planning sessions, we had technical planning sessions, we had alignment sessions, we had review sessions, we had a sessions to report upwards and sessions to report across the business, we had boxes to tick and documents to fill out. >> [sighs and gasps] >> Man, I'm tired just thinking about that.

There was too much work around the [music] work and not enough actual work being done. That's it. That was the problem. And as a result of this, the team being far apart, everybody waiting for everybody else, trust slowly broke down.

And foundationally, when a team doesn't trust each other, then nothing really good can be produced. It's It sounds so obvious and so simple when you say it out loud, but it's incredible how many teams miss this really simple thing. That the further apart you are, even if you're remote, that doesn't mean you have to be far apart. And our team was totally remote.

But the further apart you are, the less you get done, the less you trust each other, the more that trust breaks down, the more process you need to put in place. And that's where things get complicated. Chapter two, why organizations do this to themselves. The Netflix co-founder Reed Hastings, he said that the python of process tightens every time something goes wrong.

And that is exactly what had happened with this team. Every deadline that was missed, every commitment that they didn't get across the line, every time they made a mistake, senior management would look to them and add more process. And the more process that got put in place, the further behind they got on the road map, and on and on, the python just continued to strangle. And this is a very tough place to be for a team because unless somebody wants to jump in and pull everybody out, then it never happens and the team just continues to struggle and therein is exactly why I was hired in the first place.

And when I joined the team, I was introduced to the company with two words, benevolent dictator. And that's what I was allowed to do. I was allowed to be a benevolent dictator and as a informally trained product manager, read entrepreneur, the way that I did this was to remove process. We're going to get to how I removed the process and what processes I removed and what we kept in place to build this dream team shortly, but I want to move on to chapter three, which is the science of why these [music] things don't work.

And the one number that I mentioned in the beginning that I want to tell you about now is called the Dunbar number. Um and [music] a British anthropologist named Robin Dunbar found that there is a cognitive limit to the number of close trusted relationships that a human being can have. The numbers break down into layers and I'm sure that you'll recognize these layers in your own life and your own work environment. And Dunbar number is a really simple number that the average human being can only keep a close, deep, meaningful, trusted relationship with five people.

Teams of five. Teams of five people or less make the most sense because you can trust them. Then you go up to deep trust with 15 people, then a meaningful relationship with 50 people, and an active contacts with up to 150 people. Dunbar's number is the secret unlocked here.

As you get bigger, you put process in and then the process takes care of the flailing relationships as Dunbar's number comes into effect. But unfortunately, that's not how humans work. Active contacts with 150 people regardless of process is impossible to maintain on a day-to-day basis. And the converse is true, too.

If you have processes for 150 people on a tightly knit, deeply meaningful, and trusted relationship of five, then those five people aren't going to get work done because they don't need those processes to get their work done. They trust each other. And so this is the basis on which I built everything going forward, which leads me to chapter four, the right people and the uncomfortable truth. The truth here is not everybody can operate in a high trust, low process environment.

Some people need [music] process. Some people need to tick boxes. Some people's entire career is made by not shipping anything [music] but politically moving teams forward and showing people that they did the work. Now, one of the things that I do with all of the teams that I ever join is to institute radical candor.

And said simply, radical candor is to care about the people that you work with personally and to challenge them directly. And that's what I do from day one. As you can probably tell, I am a very direct human being. I care about the work.

I care that you are a human being who does good work, but if you are in a team with me and you can't take criticism, then we have a problem because the work needs to be criticized all the time. And so the kind of person that I look for is somebody with low ego, somebody who is highly driven to do excellent work, somebody who's highly motivated, who has high agency, who has a natural dislike for putting too much process into their work, and somebody who's not too easily offended when they don't do their best work. Over time, the people who performed stayed, the teams that didn't didn't, and we eventually evolved into a space where everything was working well. I believe that high trust, low process teams outperform low trust, high process teams.

And this graphic is going to help us explain. You can see the graph on the left is trust and at the bottom we've got process. So, from left to right in the bottom right hand corner you've got high process and low trust. This is definitely not where you want to live.

You have slow decisions and political people trying to get work done but ending up really exhausted. In the bottom left hand corner we've got low trust and low process. This is chaotic and unpredictable and in the top right hand corner high trust high process functional but extremely heavy on process and good people feel slowed down by unnecessary friction. The good zone here is the top left.

High trust low process where fast direct decisions are made by energized people and this process brings people closer together. So, now that we've seen what we think the problems are, how do we how do we fix this? So, here are the five things that I did to build my dream team. The first was I brought people closer together.

By removing process, I didn't remove the closeness of the team. I gave them space to work. I gave them space to explore. I gave them the ability to team up and spend hours just iterating through the designs.

So, we needed to move rapidly. We needed to make fast decisions and the closer we brought people together the more likely those decisions were going to be made. So, instead of having daily stand-ups and all of the scrum agile things that I genuinely think waste more time than they are good for, I decided to bring people closer together in rooms where we could all make decisions quickly together. And so, we would have design jams that would spend two or three hours on a call together with designers and engineers and product people all together all making decisions.

Then we would go away and do the work. And then if they wanted to be closer together they could be. So, the closer I I people together the less process we needed the more trust they had in each other and in me. Communicating outcomes, number two.

I believe that in if you give smart people the outcome that you're aiming for and let them go do their jobs, they're going to move towards that outcome regardless of what it is you're trying to get them to do. Regardless of the processes in place. So, the key thing is to communicate often and communicate clearly what the outcome is that you're seeking. Now, the difference here is I'm using the word outcome and not output.

Because if you want to dictate the output that somebody has, then you're telling them exactly what to build. And I'm not telling you exactly what to build. I'm telling you where we want to go and then I'm letting you decide. That's trust.

I'm giving you the trust. And then while I'm doing that, I'm also trying to protect them from other people who don't trust us yet. That's going to come later in point number four. So, then on to number three, remove silly process.

I'm not saying remove all process, but story points are silly. It's a silly waste of time for smart people to sit and size stuff so that you can report upwards to management how long it's going to take for a piece of string to get built. I don't care. [music] You as management trust me.

If you trust me, let me build stuff. If you don't trust me, that's a different story. Then we can talk about micromanagement in point five later. But in the meantime, remove silly process.

Process doesn't make work better. Trust makes work better. Number four. Protect the team from bureaucracy.

This kind of feels like process, except it's not. Bureaucracy extends throughout the entire organization. It's when other people demand things from your team. It's when the whole company is looking for you to slow down and meet their laborious requirements for how work should get done.

Bureaucracy doesn't move products forward. My favorite one, I killed micromanagement. Before I joined this team, we had founders, senior managers, and strategy people all coming in and telling this team how to do what they were doing, what to do when, and why they do it. And that just doesn't work.

If you are spending money on expensive people and you're then telling them how to do their jobs, why? Why hire them at all? Why not just fire everybody and do the work yourself? It makes no sense.

So, that's what I did. I protected the team from micromanagement and I was the one that took the brunt of it. Whenever anybody had a question, it came to me. And then I would field the question leaving my team to do their work because I had the broader context.

And so, those are the five things that I think you need to do. Chapter six is about freedom, responsibility, and the AI kicker. In case you didn't hear, AI is a thing. In a world where the big businesses are using AI to push teams harder and faster with less resources, the only way forward is freedom and responsibility with small teams that don't break the Dunbar number.

Your teams should be five people or less, all wanting to ship, all with the freedom to do so, and the responsibility of understanding what the outcome is that the organization is looking for. And then, leave them alone to do the work. That's the goal. That's the deal.