Building An Autonomous Team Is Fun!

Building An Autonomous Team Is Fun

**Anna **00:11
It is quite the fluffy thing and autonomy is something that is very hard to measure. So when we go down to practicality, for me, it is three questions which team has to answer by themselves is like, how to decide on what to build, how to build it, and how to work together or organise together while building this.

**Anna **00:41
So let me introduce you to the world, my team. We are called user journey, and we are a cross functional team, maybe one of the biggest team in iZettle, but definitely the most international one. So we are in our now 12 people and we come from nine different countries across the world and you have to understand that in iZettle, we have so many cross functional teams, and all of them works differently. So in my team, I have developers, I have designers, I have test automation, guys, I have analysts, product people. So that's something what Rory was talking about when we all sit together, and we work together towards one goal or set of missions. So, we believe that we work according to Agile principles, but that's what we do and increasing the team autonomy was definitely one of our focuses of improvement in the last few years. So our main product goal or the goal from user perspective, is to build the best possible registration and onboarding experience to iZettle product. Once again, you mentioned that right now teams are starting to organise around customers journey, rather than products. And yes, we are one example of this because we don't have a specific product, we have the part of the user journey and that's where we optimize. So besides this, we of course, have a very diversified domain and a lot of projects we do are not customer facing only, but also internal systems and internal improvements, but I guess it's almost impossible to focus on new users, at least in our situation. So, since iZettle, is a FinTech company, we have compliance, security, risk limitations, and all they're constantly on our assets. So because of that, we have to provide the best possible user experience. So, end users, and not sending our founders to jail.

**Anna **03:05
So enough about my team. Let's talk now, about what exactly we tried to improve in order to be more autonomous and provide better results as an outcome. So, every team has stakeholders and when I started, my team was just four people and we got more than 20 very demanding individuals in the organization and very quick, we figured out that the team has very low chance to focus and they're constantly getting interrupted. So, we decided to gather all stakeholders in one room for the first time. And stepping into this room wasn't so easy. Basically, it felt like stepping into the lion's cage. It turns out to be that most of our stakeholders have no idea about existence of each other, and also have very different than sometimes conflicting opinions on what should team and what should team do, how they should do it, and what they should do. So, at the same time, they have low visibility into ongoing things. And maybe that was the main reason why they were constantly coming, checking on the team asking questions from developers. So, we kind of were working like information engines. And so we tried to work it out, and ended up with a setup which works for us the best and even now, so one highly engaged representative of the main departments. What do I mean by highly engaged? It is basically people who work with us in very close cooperation. And they don't miss any demo. They sit with us and they ask questions and from time to time, we even involve them into discovery, delivery and even testing. So they're no, they're just the business case and highlight the functions. But they're here actually for delivery.

**Speaker 2 **05:10
And at the same time, they streamline our well use and way of working to their departments. So we achieved a lot of understanding in other departments by basically investing in their understanding of how we work, and to filter a lot of unnecessary noise. So, we kind of go extra hands, and those hands are highly skilled and very motivated, and supporedt. So, this is why I think having engaged stakeholders were important and I will try to run an example that hopefully illustrates. So on the graph, you can see it's actually real monitoring is one of the markets and you can see different conversions. These are the steps which users have to complete in order to finish onboarding, responding, for example, products, and overlying represents the final conversion, so of the entire funnel, or the entire flow, which we own from the user perspective. And as you see, there was like a huge increase of every step, which results in almost doubling of the final conversion. So what happened here? Last December, we were testing a new concept of onboarding for Android users on a card. And it wasn't meant to be for 10% of our users and we were launching it as always with ABS. And on seven markets, everything went as expected. But on one specific market, we very quickly figured out that there is some weird user activity with this change. So we figured out that we missed one very specific and critical market difference that we had no idea about before the launch.

**Anna **07:16
So that was kind of a big, failed, oops, moment. In situations like this, you always have a choice, either to rollback, you know, cover the part, or start erasing and fixing it very quickly on real numbers. And what is important to mention, since we work with onboarding of fresh users, so that was affecting only incoming users, not the entire user base. So after a discussion with the team, we took a decision where we agreed that we're going to iterate and our stakeholders, including local market, were very supportive because they trust us. And since it was a calculated risk, we knew how many users were going to lose, if we're not fixing it fast enough. So we started to thread it, it was very fast cycles, like, we were coming up with a hypothesis in the morning, building something during the day, releasing something by the evening. And then at the moment, when the local market wakes up. We were like leaving the office. And they were actually gathering real feedback from end users. So, by the morning, when we're coming back to the office, we already have enough feedback and insights to take a decision or information or start validating the next hypothesis. That's a bit extreme. But while those past cycles, we figured out several improvements, not just for this 10% of users, but actually 400% of upcoming users, and fixed it very quick. And this results in those, you know, grow of conversions, which is a great example because this story illustrates the importance of a homogenous: is the ability to take decisions fast and they need to make decision inside of the ownership of their domain. Okay, in Sweden, we love fikas (a break to have a coffee and a chat). And my question is like how many fikas you need to take with your team in order to achieve consensus, right? It will work when everyone agrees with your product initiative or with your solution, but what will happen if someone disagrees? So how many fikas you will end up taking one after another when it comes to product development? Well, my answer, risk zero.

**Speaker 2 **10:02
Instead of reaching consensus, try to build a hypothesis and related together with a team. Because even if part of the team disagrees with this regional solution, you will move fast enough and gather enough insights and data in order to convert it into something great for your users. And there will be no panel bullying involved. So features out of the picture. But what else is helping us to make more autonomous decisions and experimenting? It is, first of all, one of our mottos, which sounds like we question everything, especially legacy and long-term existing things. Well, sometimes you need to ask 100 clients why, why this decision was taken, why it was built in this way, especially when it comes to features or setups from five years ago? And sometimes the answer would be just because five years ago, somebody decided so. So it's very challenging. And you should keep asking why, why, why? And no, you know, what else is challenging is actually to ignore big signals by weak signals. My team means things like highest paid person's opinion, for example, or industry trends or anything, we're just trying to affect our decision or iteration process and we actively try to avoid it. But it's, believe me, it's very challenging, especially when it comes to highest paid person. So try to build all of your decisions based on experimenting on your experiments, and not someone else experimenting. So experimenting wouldn't be efficient by itself without easy access to data. And this success should be for the entire team, not just on developers, or UX guys, it's all should be visualized. And in order to have it set for your team, you as a product manager should prioritise tracking initiatives and make sure that you actually focus on this.

**Anna **12:30
So what else we doing, what works well for us, because you might have had a lot of data, and then nobody will do it, right? But if you try to attach specific dashboards to all the team goals, and all of your team goals should be measurable, right? Put them in the middle of the room, and then believe me, everyone would be checking how are we doing? Like, oh, how is this commercial? Oh, look at this 500 explained, you know. So, as I mentioned, the team should have a mandate to take decision, even painful ones, and the team should have enough data around them and interested in checking this data. So, remember the story about the lions, cage and stakeholders, right? So what we're learning from this situation is that not everyone in our organisation understands our ceremonies or the way we work. They just hear bla bla bla bla. So this is why you should keep repeating your team's working principles all the time. And especially for outsiders of the team, because we all tend to run and covering slang and all of these specific terms, which we invent, but it might be obvious for team for the outside of the team, it's just getting lost. It's also challenging because you sound like a parrot, you repeat yourself all the time. But try to do it's going to pay back. So huge drama while releasing? This is sound familiar? Anyone been in a drama situation? Yay. Yeah, me too. So, in order to increase the team autonomy and improve confidence, you should release as frequently as that's pretty obvious price. But what helps us to avoid drama is actually investments in test automation. One more long-term goal and it's not starting to buy the dividend but in the long-term horizon is definitely going to pay.

**Anna **15:03
So another set of principles or whatever, which we tried is trying to involve outsiders into our collaborative testing. It might sound like a waste of resources. But in fact, once again, you will actually build a better understanding about your features internally in their organization. And you will gather a lot of feedback. So our last collaborative mock testing, if you can call it this way, happened yesterday. And they might seem while I'm on stage, is actually releasing. So, no drama, and everyone is participating in this release. And every team member doesn't matter designer, analyst, whomever they all participate, because they're all feel connected. Whatever reason, even if it's a microservice, so yeah, so trying to engage people inside and outside of the team into this process. So, we discussed very quick, reactive cycle when we were iterating, after failing on one of the markets, right. But in fact, we have more products in cycle, and we call it the discovery framework. So what is this discovery process for us? It is a process of seeking the best possible solutions for the problems that have been prioritized by the team. Why it is important, in my opinion.

**Anna **16:41
So our team and I guess your team is the main expert in your domain, right? No one knows better the domain than you do and they will definitely come up with the best possible solution for the problem. So try to avoid prioritizing solutions as product manager, or as a stakeholder trying to avoid squeezing both solutions to the team because team gets allergic. And instead, as a product manager, try to prioritize problems. And whenever stakeholder someone comes with a solution, try to convert it, yeah, converted into a problem. And this is what you will present you're not the solution. So, when discovery is done the right way, and all team members participate in this process, then building your solution will go very smooth, so there will be no handover whatsoever. And also, there's a cheaper way of validating ideas. So you constantly as the outcome of the product discovery process, you will have constantly a perfectly come back, because this is what we all aim for right? Good backlog that anyone can pick up and start building, right. So this is how the discovery process works for us. So we first go on the problems hunting, most of the time, we don't really need to conduct because they come to us through signals from users, or through support escalations, or with ideas from people who work directly with customers. And as an outcome of this problems hunting, we ended up with the pool of options. I really like word options, because team never committed to the sole solution to this problem. It's just options. It's just there. And it's discovered. Then we start this big cycle, which internally we call cooking process. I didn't come how we ended up with this name. But in our calendars, we would have a cooking meeting every two weeks.

**Anna **19:01
So during this cycle, not necessarily in that order, but we go through problem validation, ideation and ideas realization. So as an outcome of problem validation, we end up with a nice list of problems and prioritsation done based on many different components. Business outcome, you know, how many users we’re going to affect, how much maintenance we need to do stuff like that, but we do it through data analysis, user interviews, if it's needed, and by collecting artifacts. So inside of ideation cycle, there is of course, team brainstorm, prototyping. I am drawing something on your whiteboard. And that's how you end up with these ideas. During the ideas validation cycle we try to build surveys, we might be doing more user interviews, trying to run different experiments. So our developers are really sitting and writing servers for customers together with our UX designers. And it's very important, because that's the team responsible for what we do, not this specific, individual specific subdomain, right. So here, you end up with a list of validated ideas or initiatives. And it's still options. So those options kind of becoming great for development, when you document them, or like your presentation, or something, you might from this presentation with the outsiders of the team or might not. But still, it's all options. And we call them hooked options, because it went through this cooking process.

**Anna **20:55
So those options, the team still didn't permit to do, but it's them, you know, sometimes, we even might share the scope options with other teams, which is not super efficient. But if you did discovery well, and very fast, there might be interest in other teams actually picking up on your results. And don't forget the load of stuff from every cycle or sub cycle is actually goes to the bin. Only stuff which is very valuable makes it through the process. So, in order to focus on this, we at least in my team, have kind of in the sprint, we have a list of things which are ready for development and be ready to build. But we constantly aim for like 20%, or maybe even more items to be discovered. It also was challenging, because people usually tend to focus on something what is already discovered, already set instead of focusing on something unknown.

**Anna **22:14
So as I mentioned, it is always seen decision to actually send stuff to trash. It's not like manager comes and say like, oh, I like this option. Usually, we present them something that you already decided, would be in the options, ready for development options. So once again, autonomy of taking your own decisions. Even if the team is super-duper, autonomous leadership in the team is very important. So the question for you: what kind of leaders around you and your team and I'm a three types, it is a …funnel, manager, …umbrella manager, and the …fed manager. So I would say that, definitely having …umbrella manager is much better for your team and why umbrella so important that it is necessary because it helps you to filter irrelevant staff, and helping team to focus on their goals, focus on their discovery process and on their initiatives. So in this case, in our case, not just the leader of the team is playing an umbrella, but also engaged stakeholders helping out by, you know, filtering this noise to their departments. However, there is one type of feedback that shouldn't be filtered ever and it customer feedback, of course. So, the entire team doesn't matter who they are, from their expertise point of view, they all should be exposed. In fact, that's why our developers also participate in customer, which might be very weird.

**Speaker 2 **24:07
Question.

**Anna **24:19
Well funnel is like this accelerating into the team, accelerating negative feedback and emotions and stuff like that. The funnel is actually trying to follow the filter and then umbrella is to strive to, you know, make people to focus on like, protect them. So, the team autonomy is still fluffy. However, I think these are the questions you might ask yourself in order to identify if you should focus on your team autonomy more or not?

• How many fikas before you act?
• How many of the solutions came from outside the team?
• How many hypotheses did you validate?
• How often does your team get interrupted?