What Real Madrid can teach us about leadership

TL;DR for those who don't want to read the whole note:

If people think about you as a leader, you should be extra careful about what you say in public, regardless of whether you meant it or not, because:

1. Leaders' words, by definition, have a big impact on a team's mood and a whole culture
2. If this impact is negative, there are not many people to improve the situation

If you hate football, bear with me for a couple of minutes – the second half of the note is about programmers. If you don't like programmers either, it's better to watch a crazy video about the cat who does not like bananas.

Part 1: Football

13 February 2019, UEFA Champions League

Round of 16, 1st leg

Ajax (Amsterdam, Netherlands) – Real (Madrid, Spain)

89 minute of the game.

Real Madrid logo from https://www.realmadrid.com/

Everything is perfect for Real Madrid: they lead 1 – 2 in Amsterdam, about 5 minutes left to play before the 2nd game at home stadium.

And this second game must be a formality now.

Why? There are several reasons:

1. If we look at the UEFA Club Ranking for the past 10 years, we'll see that Real ranks first, when Ajax is 21st.
2. Real won 4 trophies for the past 5 years. During the same 5 years, Ajax has never passed the group stage. Actually, for the last 3 seasons, they weren't even qualified for the group stage.
3. According to transfermarkt, the total cost of all Real players is $1,13 billion. Ajax – $0.43 billion, more than 2.5 times lower.
4. Teams in playoff stage of Champions League win only 26% games if they play away, which is 2 times less than their chances to win at home (52%).

But it's still 5 minutes to play and Ajax attacks.

Real Madrid captain Sergio Ramos decides to foul to prevent Ajax from scoring. This foul looks reasonable and legit, but he gets a yellow card, which means that he has to miss the second leg in Madrid. However, he doesn't have a possibility to be suspended later, in the quarterfinals.

Sounds like a wise thing to do, and when journalists asked about this incident, he admitted that he got the card in purpose:

I would lie if I told you that I did not force the card.

It is something I had in mind, it is not to underestimate [Ajax] or think that the tie is already over but I have decided [to be booked] so I can rest in the return, although I will be in the stadium to encourage the team.

---

When you see an interview like this, you immediately understand that something unusual happens.

It's not about a yellow card – players do this all the time when they know that the game is not important, they won't be included to the line-up, or they don't want to fly somewhere with a team. But nobody talks about it.

What do we usually hear from coaches and players?

"The next game is always the most important", – everyone, ever

"Yes, we won 7 – 0, but nothing is done yet and we should be prepared for the second leg. Everything may happen", – everyone, after they won 7 – 0

Of course, they don't always think like this. But nobody cares about what they really think. They can think that their next opponents can't play football, so it will be an easy win. It's absolutely fine, if they keep training and do whatever is necessary to reach the goal.

But when it said in public, it's different. Now everybody in the team knows, that the leader doesn't consider the next game important. He doesn't think it's necessary for him to play, and he probably thinks that it'll be an easy win in any circumstances.

People, who like cheap detectives, weren't surprised when Real lost the second leg in Madrid 1 – 4 – a classic twist.

Part 2: Programmers

People can argue that it isn't about Real, it's about Ajax playing very well in the second leg. This is true, but it doesn't make any difference. Now I'll try to explain why this situation is remarkable, but we need to change the subject to do this.

Imagine a small development team: 2 juniors (Jane and Bob) and 1 senior engineer (Lucas). They all work on the same project: write code, test it and deploy to production.

Leader wears glasses. Bob has hands

At some point, Lucas decides to deploy new changes without testing. These changes are small (just a couple of lines of code) and urgent, business needs it as soon as possible.

In the end, we may have 2 different situations: the system broken by this commit, or everything is ok and works as expected. From the other side, he may want to tell the team about his decision or to think that it's to minor to mention.

Let's draw a matrix of these variants because every article about leadership needs at least one matrix.

The Lucas Matrix

Let's go through all the quadrants and compare them by two criteria: short-term result and long-term result.

1. The system works well, and nobody knows that Lucas didn't test code

No doubt that all short-term goals achieved : Lucas deployed important changes and avoided any possible communication overhead. The team doesn't know that he skipped testing, so we may expect that Jane and Bob will continue to test their code.

At first glance, nothing should affect future performance: juniors were busy with their work to notice something unusual, Lucas is an experienced engineer: he knows well when testing is necessary and when not.

But teams never work in isolation, and cutting corners tends to lead to false expectations from stakeholders. Especially if it comes together with a lack of transparency.

Let's imagine that this task has been done for 1 hour. Just a couple of situations like this, and everyone will know that 1 hour is reasonable time budget for similar changes: if you spend more, you do something wrong. Eventually it leads to more short-sighted decisions.

Another aspect is Lucas' behaviour – I said that he is an experienced engineer, but it doesn't make much difference. Sometimes, even the best swimmers drown, and overconfidence is one of the worst enemies for programmers. Frequently enough, less experienced people are more careful because of their fear of breaking something. For our imaginary Lucas, situations like this strengthen his opinion that he knows better when to ignore the rules.

2. The system is broken, and the team knows that changes weren't tested

This situation is a great example of instant karma in action: Lucas says that the changes are too small to test, deploys them and ruins the whole system.

Instant karma

In fact, this quadrant describes well the previous example about Sergio Ramos and Ajax – the captain had said that the second leg should be an easy win, and the team lost the game, same instant karma.

Returning to Lucas' team, the system is down – no need to say that short-term goals aren't achieved. It isn't that clear with long-term goals though.

As I said before, the situation with Real Madrid is very important because it clearly shows the consequences after an action. One thing that makes it better – it's an example from real life, not a hypothetical story about 3 programmers.

The difference is huge: it's a well-known fact that people learn from mistakes better than from learning best practices (this is why tests are so effective in education, and why it's important to make more errors). It doesn't mean that you need to go and drop your production database instead of reading this article, but in case if someone drops it, you need to make sure that you turn this situation into common knowledge and procedures preventing this from happening again. If it's done in a proper way, the long-term effect of this mistake will be positive for the company.

It looks like Real did it as well: they fired the coach, mainly responsible for the atmosphere in the team, and convinced Zinedine Zidane to return to the club. Zidane has exactly what the team needs - an enormous authority proved by his career as a player and a manager.

Sergio Ramos apologised and admitted that the yellow card was a huge mistake.

UEFA, in turn, banned him for 2 European matches, which means that similar situations will be rarer.

It's time to return to our programmers and look at the 3rd quadrant.

3. The system is broken, and nobody knows that Lucas didn't test code

This situation has a lot in common with the previous one:

1. Short-term goals – bad
2. Long-term goals – good, but only if the team has good processes for post-mortem retrospective, otherwise it'll be really difficult.

The trickiest part here is that we don't have a clear correspondence between an action and consequences, and there is always more than one thing to improve.

Imagine, that Lucas, Jane and Bob came together to discuss the problem and how to avoid it in future. As we know, the main problem was that the code wasn't tested by Lucas. But usually, only teams with a healthy atmosphere and a good level of trust can bring it to the discussion.

For Jane and Bob, it's necessary to feel safe to be able to ask "have we checked that the code runs locally?" when they know that more experienced engineer worked on it.

At the same time, it's important for Lucas to know that admitting his mistake doesn't affect his position and ability to lead the team.

If the team doesn't have this safety, people may not touch the actual problem but still come up with reasonable suggestions, for example:

1. Write autotests for this part of the system prevent deploying incorrect code
2. Review each other's code to increase chances to spot an error
3. Implement the system that would automatically revert changes if something goes wrong, so downtime would be minimal

One more reasonable improvement

All the elements from the list above make sense and it's worth to implement them. Although, it's quite possible that without addressing the core problem, they may lead to a higher level of overconfidence and, as a result, to different manifestations (e.g. I know that my code will be reviewed by someone else, so I won't even run it to check that it works).

4. The system works well, and the team knows that changes weren't tested

This is the worst possible scenario because it represents the situation from #2 but with absolutely different outcome.

In situation 2, Lucas says that there is no need to test these changes and immediately breaks the system.

In this case, he says the same, but everybody sees that it goes well. Every time this happens, it reinforces similar behaviour and encourages people to work like this in future.

It's important to see the difference between leader's and other's actions. Let's consider 2 examples.

Example 1: Jane decides not to test the code.

In this situation, it's the team's responsibility to validate this decision and object it. Most of the time, it's enough to ask "Why do you think that we shouldn't test this change?" to undercover all the disadvantages of this approach.

If the team didn't pay enough attention to it, it isn't necessary that it became part of team culture. The reinforcement line is a bit longer in that case:

Decision → Validation by the team → Action → Reward

Jane asking for feedback before making a decision

It's usually necessary to have several loops like this to affect the culture, so the team will have more chances to provide feedback. At the same time, there are more people to give constructive feedback to Jane and much more attention to her actions because she is less experienced than Lucas.

Example 2: Lucas decides not to test the code

This example is different because:

1. Usually, there is less critical thinking about leader's actions
2. It isn't common to object leader's decisions in teams with lack of safety
3. While Jane is supposed to get feedback after describing her plans, Lucas' plans automatically pass validation, so the reinforcement line become shorter:

Decision → Action → Reward

Less time needs to pass before Bob and Jane start using the same approach in their work. Then, even if Bob makes a mistake and ships incorrect code, it doesn't mean that Jane will learn the lesson :

Lucas' influence is too strong

There is the same Lucas Matrix with our thoughts about short/long-term outcomes:

Green – good, yellow – depends on the team, red – bad

---

Final thoughts

So what exactly we can learn from Sergio Ramos' mistake?

1. Leaders' words have an enormous impact on team morale and culture If someone else said the same, Sergio Ramos would be the one who should talk to this person and make sure that the team keeps focused. The example of Jane and Lucas illustrates this difference.
2. Despite the fact that teams win and fail together, leaders are responsible for their mistakes. Two main reasons for it:
3. It's easier for their actions to affect the team
4. Usually, there are fewer people to challenge their position, so they don't encounter the same level of criticism other people do
5. "Instant-karma"-mistakes are one of the best sources for growth Real Madrid changed the coach, the team learned the lesson and UEFA created a precedent of punishment for a deliberate yellow card
6. It's significant to build procedures to help people learn from mistakes , such as retrospectives and post-mortems
7. Good psychological atmosphere and safety are necessary for progress. Leaders should be able to admit their mistakes, as Ramos did. At the same time, the whole team should be able to challenge a leader's position.
8. If nobody can challenge a leader, we need more leaders This is what Real has after they returned Zidane as a coach.