Building An Autonomous Team Is Fun!

Anna Sitnikova at UXDX Community: Stockholm. Video: https://youtu.be/rMza0Q4tbCs

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.

Autonomy and the User Journey team

[00:00:10] It is like the fluffy thing, and it is something which is very hard to measure. So when it goes down to autonomy [?], for me it is three questions which the team has to answer by themselves: how the team decides what to build, how to build it, and how to work together, or organize together, while building it.

[00:00:40] Let me introduce you to my team. We are called User Journey [?], and we are cross-functional. We may be one of the biggest teams, I suppose, but definitely the most international one. We are right now twelve people. You have to understand that at iZettle [?] we have so many cross-functional teams, and all of them work differently. In my team I have developers, designers, I have test automation guys, I have analysts, product people. So that's something Rory was talking about: we all sit together and we work together towards one goal or set of missions. We believe that we work according to agile principles, but that's what everybody says. And increasing the team autonomy was definitely one of our focuses of improvement in the last few years.

[00:01:50] Our main product goal, from a user perspective, is to build the best possible registration and onboarding experience possible. Once again, you mentioned that teams started to organize around the customer journey rather than the product. I guess we are one example of this, because we don't have a product to own. We have part of the user journey, and that's what we optimize. Besides this, we of course have a very diverse [?] domain, and a lot of projects we do are not only customer facing but also internal systems.

[00:02:36] Since iZettle is a fintech company, we have compliance, we have risk limitations and all those possible things on our side. Because of that, we have to balance providing the best possible user experience for our users and not sending our founders to jail.

Engaged stakeholders

[00:03:04] 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. Every team has stakeholders, and we got more than 20, from all different individuals in the organization. Very quickly we figured out that the team had very low chance to focus, and they constantly got interrupted. So we decided to gather all the 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.

[00:03:54] It turned out that most of our stakeholders had no idea about the existence of each other, and also had very different and sometimes conflicting opinions about what the team should do and how to do it. At the same time, they had low visibility into ongoing things, and maybe that was the main reason why they were constantly coming, checking on the team, asking questions of developers. So we were kind of working like information engines. So we tried to work it out.

[00:04:30] The setup which worked was the following, and it is still in place: one highly engaged representative of each main department. What do I mean by highly engaged? It is basically people who work with us in very close collaboration. They don't miss any demo, they sit with us and they ask questions, and from time to time we even involve them in discovery, ideation and even testing. So they don't just know the business case and highlight the options; they see the reality. At the same time, they spread our values and way of working to their departments. So we achieve good understanding in other departments by basically investing in fairness [?], and they filter out a lot of unnecessary noise. So we kind of got extra hands, and those hands are highly skilled and very respected [?] and supportive.

Failing on one market, and iterating fast

[00:05:41] This is why I think having engaged stakeholders is very important, and I will try to show an example that hopefully illustrates it. On the graph you can see actual real numbers from one of the markets, and you can see different conversions. These are the steps which users have to complete in order to finish onboarding in one expensive product. The lower line represents the final conversion of the entire funnel, the entire flow which we own from the user perspective. As you see, there was a huge increase at every step, which resulted in almost doubling the final conversion.

[00:06:33] So what happened here? Last September we were testing a new concept of onboarding for Android, and it was meant to be for 10% of users. We were launching it as always, and on some markets everything went as expected. But on one specific market we figured out that there was some weird user behavior with this change. We figured out that we had missed one very specific and critical market difference that we had no idea about before launching. So that was kind of a big fail and an oops moment.

[00:07:21] In situations like this you always have a choice: roll back and cover the problem, or start iterating and fixing it. And what is important to mention is that since we work with onboarding of fresh users, it was affecting only incoming users, not the entire user base. After discussion with the team, we took a decision very quickly that we were going to iterate, and our stakeholders, including the local market, were very supportive, because it was a calculated risk. We knew how many users we were going to lose if we didn't fix it fast enough.

[00:08:08] So we started to iterate. It was very fast cycles: coming up with a hypothesis in the morning, building something during the day, releasing something by the evening. Then, at the moment when the specific local market woke up, we were leaving the office, and they were actually gathering real feedback from end users. So by the morning, when we were coming back to the office, we already had feedback and insights to take a decision with information or start validating. That's a bit extreme, but during those fast cycles we figured out several improvements, not just for these 10% of users but actually for a hundred percent, and fixed it very quickly. And this resulted in those growing conversions. It's a great example, because this story illustrates the importance of decisions, and of taking the decision inside of the ownership domain.

No consensus, question everything

[00:09:21] Okay, in Sweden, my question is: how many pickers [?] do you need to take with your team in order to achieve consensus? It will work when everyone agrees with your product initiative, with your solution. But what will happen if someone disagrees? How many will you end up taking? Well, my answer is zero. Instead of reaching consensus, try to build the hypothesis and validate it together with the team. Because even if part of the team disagrees with it, you will move fast enough and gather enough insights and data in order to convert it into something great, and there will be no blaming [?], because opinions are out of the picture.

[00:10:33] What else is helping us to make more autonomous decisions and experiment? First, one of our mottos, which sounds like: question everything, especially legacy and long-term existing things. Sometimes you need to ask a hundred times why. Why was this decision taken? Why was it built in this way? Especially when it comes to features or setups from five years ago. And sometimes the answer will be just because five years ago somebody decided so. So it's very challenging, and you should keep asking why, why, why.

[00:11:19] And you know what else is challenging? Actually ignoring weak signals. By weak signals my team means things like the highest paid person's opinion, for example, or industry trends, or anything which is trying to affect our decision or iteration process. We actively try to avoid it, but believe me, it's very challenging. So try to build all of your decisions based on your own experiments and not someone else's.

[00:11:56] Experimenting wouldn't be efficient by itself without easy access to data, and this access should be for the entire team, not just for developers or UX guys. It should all be visualized. In order to have it set up for the team, use the product to prioritize tracking initiatives, and make sure that you actually focus on this. What else is important? Well, as a small class [?], because you might have a lot of data and then nobody will go into it. But try to attach specific dashboards to all the team goals. So, as I mentioned, the team should have decision power.

Explaining your way of working, and releases without drama

[00:13:05] Remember the story about the lion's cage and stakeholders? What we learned from this situation is that not everyone in our organization is familiar with the same thing. When I say "Scrum" or "stand-up," the people who arrived at the way we work, believe me, it's not clear for them. They just hear blah blah blah. This is why you should keep repeating your team's working principles all the time, especially for outsiders. Team slang evolves these specific terms, which might be everyday routine for you, but the outsider of the team is just getting lost.

[00:14:06] It's also challenging because there's sometimes huge drama while releasing. Does this sound familiar to anyone? In order to increase the team autonomy and confidence, you should, and it's pretty obvious, but what helped us avoid drama is actually investment in test automation. It's one more goal, it's not a fast start, but it's definitely going to pay off.

[00:15:07] Another thing which we tried is involving outsiders in our project testing. It might sound like a waste of time, but in fact, once again, you will actually build a better understanding about your features internally in the organization, and you will gather a lot of feedback. Our last collaborative testing, if you can call it that, happened yesterday, and my team, while I'm on the stage, is actually releasing. So no drama. Everyone is participating in this release, every team member, even the designer, even if it's a microservice. So try to engage people inside.

The discovery framework

[00:16:09] We discussed the very quick reactive cycle when we were iterating after failing on one of the markets. But in fact we also have a proactive cycle, and we call it the discovery framework. What is the 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 is it important? In my opinion, your team is the main expert in your domain. Nobody knows your domain better than you do, and the team will definitely come up with the best possible solution for the problem.

[00:16:57] So try to avoid prioritizing solutions as a manager or as a stakeholder. Try to avoid handing down solutions; teams get allergic. Instead, product managers should try to prioritize problems, and when stakeholders come with a solution, you should try to convert it into a problem, and this is what you will present to the team, not the solution. When discovery is done in the right way and all team members participate in this process, then building your solution will go very smoothly. There will be no handover whatsoever. And this is also a cheaper way of validating ideas, because through this constant process you will have everything ready to develop and start building.

[00:18:03] This is how the discovery process works for us. First, we go hunting for problems. Most of the time we don't really need to hunt for them, because they come to us through signals from users, or from support, or with ideas from people who work directly with customers. As the outcome of this problem hunting, we end up with options. I really like the word options, because the team never committed to solving or looking into this problem. It's just options. It's just there, and it's discovered.

[00:18:46] Then we start this big cycle, which internally we call the cooking process. I don't know how we ended up with this name, but in our calendars we have a cooking meeting every two weeks. During this cycle, not necessarily in that order, we go through problem validation, ideation and idea validation.

[00:19:12] As the outcome of problem validation, we end up with prioritized problems, and the prioritization is done based on many different components: business outcome, how many users we're going to affect, how much maintenance we need to do, and stuff like that. We do it through data analysis, user interviews and by collecting insights.

[00:19:38] Inside the ideation cycle there's of course brainstorming, prototyping, drawing something on the whiteboard, and that's how you end up with alternatives. During the idea validation cycle, we try to build surveys, maybe do more user interviews, try to run different experiments. And the fun part is that the whole team participates in this. Our developers are really sitting and writing surveys for customers together with our UX designers. And it's very important, because the team is responsible for what we do, not a specific person.

[00:20:24] Here you end up with a list of validated ideas or initiatives, and it's still options. Those options become ready for development when you document them, visualize something. You might run this presentation with outsiders of the team, or you might not, but still it's all options, and we call them cooked because they went through this cooking process. With those options, the team still didn't commit to deliver, but they're there.

[00:21:02] Sometimes we might even share these cooked options with other teams, which is not super, how to say, efficient. But if you discovered it well and very fast, there might just be another team actually picking it up on their own. And don't forget that a lot of stuff from every cycle actually gets thrown away. Most of the stuff which goes into this ends up there, and only the stuff which is very valuable and brings value comes out.

[00:21:35] In order to keep my team autonomous [?], we have a list of things which are ready for development and ready to build, but we constantly aim for 20 percent or maybe more of items to be discovered. It's also very challenging, because people usually tend to focus on something which is already discovered, already set, instead of focusing on something unknown. So it is always a decision, and usually we present them something which is already decided. So once again: autonomy of taking your own decisions.

Umbrellas, funnels and the leaders around the team

[00:22:37] Even if the team is super duper autonomous, leadership in the team is very important. So the question for you: what kind of leaders are around you and your team? I have met three types: the shit umbrella manager, the shit funnel manager and the shit amplifier [?] manager. I would say that definitely having shit umbrella managers is much better for the team.

[00:23:11] Why is the umbrella so important? Because it helps you filter irrelevant stuff and helps the team focus: focus on their goals, focus on their discovery process and on their initiatives. In this case, it's not just the leader of the team playing the umbrella, but also the engaged stakeholders.

[00:23:42] However, there's one type of feedback that shouldn't be filtered, ever, and it is customer feedback. The entire team, no matter who they are from an expertise point of view, should also hear it. That's why our developers also participate.

[00:24:10] What's the difference between them? Well, to define it straight: the first one is like accelerating it into the teamwork, amplifying negative feedback and emotions and stuff like that. The funnel is actually trying to follow it, to filter at least something. And the umbrella is trying to make people focus, and protect them.

How to identify autonomy

[00:24:38] So autonomy is still a fluffy concept. However, I think these are the questions which you might ask in order to identify it. How many meetings [?] before you start acting? How many solutions actually came from outside entities and were not discovered by the team itself? How many hypotheses did you really validate last month? And how often does your team get interrupted?

[00:25:24] So I shared my experience; please share yours. Any questions are welcome. I'm not sure if I'm able to say that we are hiring.