Creating A Culture To Empower Your Team

Erik Devetak at UXDX Community: Oslo. Video: https://youtu.be/Qa1N9n5tIIM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Xeneta, and how you choose a team

[00:00:18] Xeneta is a price benchmarking tool for containers and shipping. We established in Oslo four or five years ago and we have grown to almost 100 people now, which has presented a lot of the pains that some previous speakers have presented. But one of the biggest pains that we have seen at Xeneta is really how to build a team. Not only how to build a team, but how to make this team empowered, successful, autonomous and ultimately happy. I'm going to present you a bit of a journey of my team building experience [?] in the past few years.

[00:01:00] The first thing that I always ask myself is how do you choose your team? How do you start building a team? How do you choose to hire? In the simplest form, you just need to think of all the needs that you have for that team and all the possible needs that might arise in the future. So you literally write a set of requirements that are going to be for the present and a set of needs that you're going to have in the future, and understand which people, what type of people you need, particularly when you come to product team. And if you also manage, like in my case, the UX department and technical writing, this ends up being a very diverse set of possibilities, a very diverse set of needs.

[00:01:46] So you very quickly end up with a team that looks a little bit like this: diverse. Diverse in skills, diverse in capacity to go in front of the customer, diverse in analytical thinking, diverse in reasoning, diverse in how they approach all of your problems that they see, and diverse in how they solve the problem.

[00:02:12] Diversity has been shown in many ways to be great for companies and great for teams. There's a lot of research based purely on ethnic and gender diversity that showed that having a team that is ethnically and gender diverse, at the highest level in this case, increases revenues, increases profits by up to 35%. And this is just a parameterization of diversity on, let's say, two components: ethnic and gender in this case. There's many more ways of looking at diversity, there's many more things that we have to look at, that we can diversify upon. And there's more and more research coming out year after year that shows that diversity, if properly managed, increases the output of all teams.

[00:03:06] So it's a book [?]. You go out, you look at the needs you have, and you look at hiring a team that fits the needs, that almost very finished [?] becomes diverse. It's as simple as that.

Cognitive biases in hiring

[00:03:17] However, there's cognitive biases. Whenever you are hiring a person you have a tendency of having a whole set of biases. You have a tendency of taking the person who's most talkative, you have a tendency of taking the person who you most like. If you are a football supporter and you like Liverpool, you're going to automatically, subconsciously choose a Liverpool fan before an Everton fan. It's just proven that this is the case.

[00:03:46] There's also significant research that these biases can form incredibly quickly. There's an incredibly high correlation between what people think about a candidate for a job after 20 seconds and the person that you offer the job to. Think about this: 20 seconds. You say your name, you shake your hand, you say where you're from, and it has an over 80% correlation between what people think at that point they're going to hire and what people think after a one hour technical interview. So how good is that? Why even do the interviews? Why just not say "hi, my name is Erik" and decide?

[00:04:23] So we have to, whenever we hire, whether it's externally or whenever we build a team internally, we have to think about this situation. Because otherwise what happens is a little bit of this [?], which was actually my first attempt at building a team: there was Erik, and there was Erik's team. Great job.

[00:04:44] I have many stories about this, but I told a friend of mine two days ago that I was writing this talk. This friend of mine is a mathematician that used to be an academic and now works for a bank, and he told me, "You know what, Erik, I've seen exactly this. I was hiring a team of six people and I tried as hard as possible to diversify the team, and after two years they all quit, and they all went back to academia to do a PhD." So they weren't so diversified people. That's great.

Getting past the biases, and the fights that follow

[00:05:15] So how do you get over these cognitive biases before building, before hiring this team? There's a whole set of things that you can do. First of all, it's very important to have the same interview process: standardize the interview process, standardize also as fast as possible the order, the questions, the order of the questions. Tests are scored in a much more objective manner, and there's a lot of proof on this, also from university admissions, that tests are much better at showing future performance rather than a simple chat.

[00:05:56] Perform blind CV reviews. Always try to be as blind as possible, not to experience obviously, but to their personal life, hobbies for example, which historically people used to put on the CV, not necessarily a good indication of what's that, and you probably should remember [?]. Involve potentially a diverse set of people in the process, potentially involve a few people that have a different experience and a different point of view of the world, because in this way they probably have different biases. And sometimes also perform personality tests, because that also gives you a different side of the person. And maybe you didn't like the person, and maybe it shows you why: because they're too similar to you, they're too different from you, and you can use that as well.

[00:06:47] So once you do all this, hopefully your team is going to look more like this, which is much better than the team before. And I'm thinking, I managed to build a team like this, I was really really really proud of myself. And then this happened. The first teams [?], while they're shown to be much more efficient and much better performing in the long term, they fight. And it's clear why. They tend to be a less effective group, they have a higher turnover, and they have much higher dissatisfaction levels. That's it? I'm off. I don't know about the next slide. Anyway.

[00:07:38] There's a lot of research that has come after the first research of [?] university that shows that a diverse team is going to be very dissatisfied. Just think about it. Just think about, let's say, political relationships in the world: different people from different parts of the world have different ideas, have different standards. Some people are loud, some people are not loud, some people treat other people differently. So it's obvious why this is the case.

[00:08:16] And hence half of my job has become more and more about conflict resolution. How do I take this team and make it work together? The first natural thing to do when you're faced with conflict is something very simple. It's point spark [?]. It's being the middle, as the manager, as the product manager, as the person who has the responsibility of this team, and saying "you're wrong". Present with rationality, try to present all arguments, and try to choose the arguments that are correct or not.

[00:08:58] This is what most people intuitively do. It helps absolutely nobody. You have a team, and you're just alienating one more person, because you're going to try to assign blame. Or, let's be positive, you're trying to assign who's right, and indirectly you're blaming somebody every single time that you do that.

Trust, and corporate culture as a set of rules

[00:09:16] The most important thing in this case is trust. Your job is really to build trust within the team. Your job is to make sure that these teams trust each other so that they can work together. If you manage to build trust and you manage to build, let's say, the right processes, then your team is more and more going to start working autonomously and efficiently. Makes complete sense, right?

[00:09:44] Now, how do you build trust? How do you build trust? There's many ways of building trust, but there's two important things. First of all, there's corporate culture. What's corporate culture? I've been always very negative about corporate culture until I really understood what it means. It's really a set of rules of how to interact together. It's really a set of rules that say how are we going to behave towards each other in this company, and what's our vision, what's our goal, how are we going to achieve it, and what are our basic principles?

[00:10:21] If you think a little bit more, what corporate culture does is essentially the same as what law does. Everybody is free in Norway, there's individual freedoms in Norway, yet there's laws that tell us how we should behave, and there's social law that tells us how we should interact. Very similarly I believe corporate culture is a way of having goals of other [?], curtailing partial individual freedoms just like the law, and having a capability at the same time to express these differences.

[00:11:03] I believe it's incredibly important for companies, if you have the chance to influence, to have corporate structures that foster diversity, and to have a corporate culture that effectively enables and presents a set of reasonable rules and enables people to work together.

One-to-one relationships and the size of a team

[00:11:19] Now there's other things with the trust. Inherently, trust is a property between two people. You can trust an organization, but ultimately if you trust an organization you're trusting the people working for them, you're trusting the actions of these people. So it's incredibly important to start with one-on-ones. In order for a team of yours to work smoothly together, you need to foster one-to-one relationships, and you need to make sure that in all these one-to-one relationships people trust each other and they're happy to rely on the autonomy and efficiency of other people.

[00:11:57] And again, I'm not going to dwell into the research, but there's a lot of research that says that this also limits the maximum size of things. If you think about it, if you have a team of five people, there's ten one-to-one relationships. If you go to nine, there's 36. It's not a linear problem. If you arrive at 15, you already have over 100 one-to-one relationships. It's almost impossible for 15 people to all trust each other, because there's way too many combinations.

[00:12:29] So when you build teams, you have to build nuclei that are small enough that they're able to trust each other. If you want, I can send you references, but a lot of research says that this is approximately the order of eight or nine people. Anything much bigger, stretching above twelve, and the team never functions very well, because of trust issues and also because of other issues, communications issues and so on and so on. But basically you have way too many one-to-one relationships.

Waste time before you introduce processes

[00:13:05] So how do you build trust? In many different ways. First of all, waste time. That's my first suggestion for people who build trust. I've had a few of my employees who are incredibly efficient. They came in and they said, "Right, I'm going to do the agile processes, I'm going to choose a specific methodology, and I will, bam bam bam bam bam." That doesn't work.

[00:13:30] Some of these processes are perfectly designed to be efficient, they're perfectly designed to be fair, effectively and indirectly to depersonalize, so not to build one-to-one relationships. So my suggestion is to use standard sales techniques. It makes a big difference if you start a discussion, even a work discussion, where we have a one-to-one relationship, if you ask somebody about something that's important. What was the difference? Because they open up, they open up.

[00:13:58] If I say "hey, your project is late, can you turn the WhatsApp [?]", you don't really get, you get a defensive answer. But if I ask about your dog, I ask about your children [?], and I spend two minutes on this, and then I start discussing your project, all of a sudden you will see a very big difference. And you also need to cultivate this from an organizational perspective, in this relationship.

[00:14:28] So before you introduce processes, and I am a big fan of a lot of processes, don't get me wrong, but before you introduce processes, I do encourage people to use salesmanship and to build relationships, and then just after that you build processes. Because at that point you have established relationship, you have established trust, and you are able to function efficiently and follow the processes efficiently. And this means that you are building an autonomous team.

[00:15:01] And finally, there is also a discussion to have about, and it is a standard statement that you hear every person saying, over-promising. At the beginning you need to under-promise and over-deliver. And it is a great idea. If I always could go to my boss and say "I'm going to under-promise this week, and next week I'm going to commit to one layer comma [?], and next week..." that's not going to work. What I encourage people to do is to start by under-promising and then slowly tighten up the screw. This of course also works very well with understanding your team velocity, because then you can always use the first few cycles to understand the velocity of your team.

[00:15:55] So this is great. But my personal experience about this has been, and I'm a cynic, has been very good: whenever I finish this process, somebody quit on me and I had to start everything from scratch. That's it for me. Any questions?

Q&A

[00:16:12] Audience: Why did they quit?

[00:16:16] Erik: I don't know. What I'm trying to say is, it's not that people quit. What I'm trying to portray here is that there is, regardless of what you do, a natural cycle of people quitting. So regardless of what you do, you have to keep on doing this process on an ongoing basis. You have to monitor trust on an ongoing basis, because teams change, people arrive, people quit. So it's a continuous revision of your trust and of your processes in parallel. Does that make sense? Any questions? All right, thank you very much.