Building Autonomous Teams

Marcel Putina at UXDX Europe. Video: https://youtu.be/clgVk5JBBmI

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.

Five years ago I was sitting in this room

[00:00:01] It's both humbling and an exciting experience to be here, and in this exact hall, to be giving this speech, because I was exactly five years ago in a spot right there somewhere in the room, listening to Drew Houston, the CEO of Dropbox, giving his speech on the way Dropbox operates. And I remember that it was a very relaxed sort of environment, and the way he explained everything, at least to me, felt that every decision they're making is sort of handcrafted and personalized to Dropbox as a company.

[00:00:51] So it's kind of interesting that this matches with the way I wanted to approach this presentation and talk to you, because I wanted to do exactly the same thing. I wanted to open a discourse, to have sort of a conversation and to open some ideas, rather than have a prescriptive way of how we do things at DEGIRO. It would have been not a nice experience if I didn't make my flight yesterday, because when I arrived at customs they told me my passport is expiring, and then I had to wait for another 20 minutes until they figured out that actually in Ireland you can go with a passport that is almost expiring. But yeah, I'm here.

[00:01:38] When I was thinking about the topic that I would present here today, I was thinking about something that would be both relevant and sort of applicable to multiple contexts, not something that is very specific to my journey and my experience. And if you're curious about my journey, I don't want to get too much into that, but I was born in Moldova, and I specifically put it on the map for those people who always confuse it with the Maldives. No, we don't have those, but we have great wine, so keep that in mind.

[00:02:19] So, born in Moldova, I got my first computer at 10, and sort of as a trade-off to that, my father was like, you know, you like a computer, you're not going to use it only for games, but there's some work for you to do, so you're going to have to type a lot of our paper documents. My father was running a company at that time, so what I had to do is I had to digitalize tons of papers, tons of records, into Excel and the Word document. And soon enough I was realizing, you can do stuff way more efficiently. So I was applying formulas, I was digitalizing their B2B client base, and sort of that was my first gig, that was my first job. And that's how I got into the love of computers, the love of software and how to build great products.

From FinLeap to DEGIRO

[00:03:12] At 18 I moved to Germany, where I did my studies, and in the last year of my studies I went to Berlin, where I joined as second employee one of the first fintech startups of FinLeap. For those who don't know, FinLeap is a company builder. It builds companies in the financial industry, and Savita[?] was one of their first companies. What we did is we created a marketplace for fixed-term deposits. And what is that? Well, a fixed-term deposit is something where you put your money in a bank for a certain period of time at a certain interest rate, and then you get it at the end of that period.

[00:03:58] So what is the marketplace for fixed-term deposits? What we created was, we gave the possibility for people in Germany to invest in banks all across Europe, so they were able to put their money at interest rates that were much higher than were available in Germany. After the company was sold in summer 2017, I decided that I'm going to move on to another great challenge, so I joined DEGIRO in Amsterdam. And at DEGIRO I completely realized that things are done completely differently there. They're really revolutionizing the way people invest, the way that people trade.

[00:04:41] What makes this company so unique, at least to me, is that we are a very user centric organization. And because of that, our success speaks for itself. We've been growing for more than 50% year-over-year on average. We're soon hitting half a million clients in Europe and we're the largest online broker in the Netherlands and one of the largest in Europe. And I'm very happy to announce that last week we released fresh new apps in beta, and they really are, in our mind and the way we think, the definition of how users can invest and can trade at their best.

Why do we need autonomous teams?

[00:05:32] Moving on to the topic of today, moving on to the idea of autonomous teams, I want to first address why do we need autonomous teams. Well, there is this idea in economics that comes from a very Darwinist view on competition, and it asks the question: how can a company stay ever competitive? How can a company be long-lasting and successful forever, without having to be really competing for resources and other things?

[00:06:14] One of the key findings here is that the company is everlasting not because it has the most money, the biggest market share, the best product or the best tech or the best talent, or even all of these together. The most successful companies, the companies that are ever competitive and ever lasting, are actually the companies who can adapt. So they can adapt to their environment and to the changes in their environment.

[00:06:46] And then this got me thinking about, well, what makes an organization adaptable? What is the thing that will allow it to always be looking at the changes that are coming towards the organization, and then being able to adapt and go around it? It turns out that one of the answers in the academic environment is autonomous teams. So if you want to stay ever competitive, if you want to be always adaptable, you have to implement autonomous teams in your organization. But as some of you probably already have experienced, and some of you have heard or know, autonomous teams are actually very challenging.

[00:07:39] So I began asking myself, how would I solve this challenge? What would be the building blocks of an autonomous team? How would I approach this thing and how would I go about it? And I want to ask you the same question, because that's sort of the whole idea of this conversation that we're having here today: basically, how do we set up autonomous teams?

Lenses: the problem is the way you look at the problem

[00:08:03] In order to best look at this problem, which is kind of a problem or a challenge, we all know that the problem is not really the problem itself, but merely the way we look at the problem. So the problem is not the problem, but the way we look at the problem. And for this purpose I want to introduce the concept of a lens, so as not to repeat always the same thing, but just say lens and we know what we mean.

[00:08:34] The lens is that thing that allows you to look at the problem or a challenge or a thing and say, well, am I looking at it from a distance or am I looking at it from very close? Am I having a wide angle or a narrow angle? These are kind of the perspectives that you work with when working with a challenge.

[00:08:52] So what is actually a lens in problem solving? In our context, because we have here a lot of great designers, product people and tech people, we use a lot of analogies when we try to solve something. We do design thinking sessions, or we reflect on really complex questions. And here I put some of my favorites. They're not mine, they're borrowed, but I really like to work with them.

[00:09:19] So for example the Toyota five whys technique, asking why until you really go and uncover the actual driver of something. Or questions such as, what is the biggest unknown that, if we knew it today, it would completely change our plan or course of action? Trying to think through those types of things really gives you the possibility to tackle the challenge in novel ways that you have never thought of before.

[00:09:45] Or one of the questions that I really admire, and it comes from the guys behind the PayPal mafia, is: how can we do this at a tenth of the cost? They have this 10x multiplier idea, that you can either solve a problem and you make it like 10 times better or 10 times cheaper. In the case of DEGIRO, we basically offer fees that are at least 80% cheaper than on the market. So you can trade with us and you pay 80% cheaper than with any of the banks. So it's a direct example of a product that is 10x better. And then one other question that I personally admire is, why doesn't it work? What have we tried? What have we never dared to try? So these are kind of the lenses and the ideas that we can use in problem solving.

An autonomous team is like an AI product

[00:10:38] But how do we actually set up an autonomous team? Well, an autonomous team, as management science suggests, is basically a team that self-manages its own work and can self-manage its own working practices. So they're able to go themselves, they're able to fly, there's no need for input, they will just handle it. That's sort of the nirvana of the autonomous team. That's what everybody believes and wants to strive for.

[00:11:19] If we take that and we look at it really closely, what we notice is there is a parallel that we can draw here with this other concept in sci-fi, where we know there's this idea of a computer that is able to solve any problem, is able to make its own decisions and can even reprogram itself when necessary. So we have this management science nirvana, which is about making a team that self-manages its own work and self-manages its own working practices, and the same parallel with science fiction about AI and machine learning, a computer which can make its own decisions and even reprogram itself when it needs to. So that's kind of the essence of what you want to have happening in a team.

[00:12:06] I've looked at this analogy and I began to ask myself more questions, and I thought about how I'm going to make it personal to you, because we are all used to building products or services. In this sense I thought, well, let's paraphrase the question and ask ourselves, how do we build an AI product? Because it's kind of the same thing as building an autonomous team. Let's uncover the main components and the main drivers of what makes an AI product work.

[00:12:47] As you probably know, an AI product has a set of trained models. So it has models that have been trained with a lot of data, and then it uses those trained models to perceive the environment, and then it tries to detect patterns. And if the patterns match, it basically goes into making a decision, executing. But if the pattern does not match, and if it's something novel and new, what it does is it flags it and says, hey human, I need you to help me label that new thing so that I update my understanding, I update my templates, my trained model, so I can go and run the loop again.

The team's trained models

[00:13:31] If we look at the team behavior, if we look at the stuff that's happening in the team daily, people kind of go through the same type of loops and the same stages of problem solving. They basically perceive an environment through their set of trained models. And the trained models in the team are basically something that we can look at and consider a little bit intangible: those are some shared understandings.

[00:14:03] The shared understandings are, for example, the business context in which the team operates, or the goals and priorities, or the values and ethics, or even the quality standards of the team. So the team has sort of a template for each of these things, even though it's not always documented, even though it's not always written, and it's maybe not always shared with everybody. There are those things in the team that sort of make a shared understanding that is then used to basically perceive the environment.

[00:14:36] And then the more tangible part that the team has in order to scan their environment is basically the current skills. So, is the team complete? Do they have enough people on the team to tackle the problem together? Do they have all the skillset necessary? There are existing artifacts, so looking back at, for example, the code base or some guidelines, the code styles. How can the team use this input in order to solve a problem? And eventually the resources and the budget. These are some of the things, not necessarily the entire list, but just to give you an understanding. This is basically how the team uses its input to perceive the environment.

[00:15:21] And then what happens next? Well, when the team is faced with a simple problem, the team takes all of this repertoire. It has all of these trained models and templates for actions, and it basically looks at the problem and it says, well, I kind of see how that matches, so I can use it in solving this problem, then I can use that other piece in order to fit the problem, and that other piece as well. So what eventually happens is the team goes through perceive environment, detect patterns, and then decide and execute. They go through this loop over and over, because the problem is simple, they know how to solve it, they know how to go around it.

[00:16:05] What happens when the problem is novel? Well, the team does not know how to solve it before, so they have to adapt. What's happening in this case is they're basically having to use characteristics of each of their trained models. So in that case they have to use the shape of a circle and the color of a triangle in order to fit the circle. And this is how they basically go about solving something.

[00:16:34] And then one of the things that also helps the team is their shared lenses that they look through. So basically what they do is they pick something that is existing, let's say it's an artifact, it's some piece of software that works in a certain way and it does one purpose, and basically what they do is they use their lens to repurpose that thing to solve the problem.

[00:17:00] And then what really happens is the team goes through the loop of, okay, we perceive the environment, we detect some patterns, and then in the course of action we update our understanding, and then we decide and execute, and then we go to perceiving the environment again. So these are the two loops that teams go through in order to problem-solve, in order to be sort of running autonomously. And because the team does not need, similar to a computer, a computer needs human input and it flags and it says, hey, please help me understand this information that I found here that is not fitting to my pattern, the team can do that thing itself. So one thing that is really characteristic to humans is that they can understand there is something different, and then they can even think how they can solve that difference.

Why understanding fails

[00:17:51] But sometimes this type of loop, this understanding, does not happen, so the team is failing to understand. And if the team is failing to understand, and if the team does not run through these loops, you basically don't have an autonomous team. You don't have something that runs itself, that solves the problem. And ghostly[?], these loops actually make something that you want.

[00:18:18] One of the things that we looked at was, why does it sometimes happen that the understanding fails? What we know is that there are two major things. One is that there is not enough enabling structure. There's not enough opportunity for the team to learn, because they're always in the execution phase, they're always going and going and going, they don't even take the time to breathe and to think, to reflect about the things that happen to them and the way they can use that in the future to be more efficient and better.

[00:18:57] And then the second thing, which is really funny, is that the team knows it has a set of templates, the way that they can use to solve a problem, and they view those templates as a hammer. And because they know they have a hammer, every problem that comes to them is a nail. So they will try to hit that and use the same tool to solve every single problem in the same way. You don't want that to happen. You want everybody, every single time, to be sort of personalized and tailored.

The foundation layer: making time to learn

[00:19:28] One of the things that we have done this year at DEGIRO to basically make sure that the teams have the time and the capacity to go through this learning experience that they really need is, we sort of designed a Maslow pyramid for how we want teams to spend time in the organization. So we asked ourselves very important questions such as, what are those tasks in our company that, if not performed today, will eventually lead to guaranteed failure? We asked ourselves, what are the things that teams cannot not do? They simply have to do them all the time.

[00:20:18] In order to create the balance between execution and learning, we created this thing at the bottom that we call foundation. And in the foundation, all the teams have the freedom to decide what they want to allocate their time on. So every single team can pick that foundation time and say, well, we want to spend the time on onboarding new people in our team, because we see that we have a lot of people coming in the pipeline. Or we want to spend our time in R&D, or we want to spend our time with something else. And this is really, in the organizational structure, we decide and we lock that time, and it's the time people can use to really make sure that learning is happening, understanding is happening, and to make sure that the time is really allocated and the enabling structure in that way is created.

[00:21:03] The next layer that we want to spend our time on, as a financial organization of course, is all the changes that are happening in the regulatory environment. And they're not little. There are a lot of changes happening every single day or year, because it's not that fast, but still a lot. It requires a lot of effort to tackle them, so we want to focus our time on regulatory matters. And then everything that's left, all the time that's left, basically we can use for new things, new initiatives and new projects. One thing that this tells us also is that the more initiatives and new projects we want to have, we should just increase the time in new, and we should really keep the time for the teams to learn and do the things they're learning always.

Upgrading retrospectives

[00:21:46] And then one of the other things that we discovered was that the teams usually see every problem as a nail because they have a hammer, because the retrospectives and the sessions we were doing were not quite up to date or fitting our organization, because they were just based on something off the shelf. You do good, bad, improve, and then you get a bunch of people in the room and everybody's putting sticky notes and things, and some people are feeling more comfortable with doing that, some people less, and you can tell that, and people feel like they're acting a little bit, they don't feel that much ownership.

[00:22:24] So we upgraded our way of doing retrospectives by narrowing down to a very simple set of questions. Those questions are simple, but in the way they uncover a lot of the learnings that can be implemented. So they are: what have we set out to achieve? What was the actual outcome? Was there a difference? Why was there a difference? And how can we implement the learnings? Very, very simple questions, uncovering an incredible amount of truth and objectivity and logic in the way teams can operate further.

[00:23:01] So I'm going to repeat them again, take a picture. What have we set out to achieve? What was the actual outcome? Was there a difference? Why was there a difference? How can we implement the learnings? And with this type of question, anybody can feel that they can contribute, because everybody was part of the loop and part of the team journey on solving a specific problem.

Open questions: how do you actually run this?

[00:23:25] So we have been looking at this way of how to set up autonomous teams and what are the main drivers, what are the main components. And what we've noticed is that the biggest question that still remains is, how do we run this? How do we make sure this is happening and this is going, and the team actually takes these behaviors and activities and they go through them and grind through them and stuff like that?

[00:24:00] We know that the team has to be autonomous from within, because there is no one single individual that can help the team perceive the environment, or can help the team detect patterns or update understanding. Because if you limit it to one single person, you're limited to one single lens, one single point of view. And what you want to have is diversity in the way the team is perceiving all of these processes, to basically make sure that the team itself is learning and the autonomy is coming from within.

[00:24:41] We know that this can be achieved through collective leadership, where this thing is not bound to one person, but the tasks in the team are shared among different individuals, where everybody can contribute to doing a piece of the puzzle that best fits their personality. We know that we need the team coach. We haven't done that yet, but it's still something we were considering, where the coach is working through the team and serves as a sounding board to make sure that the team is on the right path, and is there when the team needs them.

[00:25:20] And overall, one thing that we know is very important, that we still have to understand how we will implement and how this will be put in practice, is basically, how do we run this with a high degree of trust, and how do we run this with a high degree of logic and objectivity? Because what you can end up with is that there is indeed learning, some understanding is happening, but if it's not true and if it's not logical and objective, you end up nowhere as well.

[00:25:50] And then ultimately, we need to always be making sure that the team has a complete structure, the team has a very high retention rate, because only through a very high retention rate can you have this team memory and this team idea about running through these trained models. And ultimately there needs to be a clear resource allocation policy, where teams can know where they can go and ask and use those resources to basically power themselves.

[00:26:22] So, a lot of open questions still, a lot to learn, and we're still in the early days of figuring this thing out. I don't have an answer to all of them. This requires an entire talk in itself. So if you're curious about where this will lead and how this will happen next, let's stay in touch, or come even work for us, and let's do this together. Thank you.