The Balance Between Direction and Team Autonomy

Rory Madden, Sreemati Lalgudi Nivstrand, Matti Klasson, Mikaela Larsson at UXDX Community: Nordics. Video: https://youtu.be/IpSqbKW47H8

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.

Introductions and team structures

[00:00:00] Rory: Great to have you all here. What we're going to be talking about today is the balance between direction and team autonomy. It's the buzzword in the industry at the moment: you want to have empowered, autonomous teams who are going off and delivering real customer value. But what does that actually mean? That's what we're here to talk about today. I'm really excited for this conversation, and I hope everybody who's watching is as well. Before we jump into it, I'd just like to go around the table, or the Zoom call, and get everybody to give a quick introduction to yourself, but also talk about the team that you're currently working in and whether it's cross-functional, functional, that kind of structure. I'll start with Shree.

[00:00:41] Sreemati: Hi. I'm Shree, I'm CTO at BlueCall. We are a mental health startup. We provide digital mental therapies, but also digital tools for all the employees and managers to really take care of their mental health every day. At BlueCall we have a very small but still very cross-functional team of six. But we also have cross-functionality in the sense that if marketing needs to be there, then they are part of that sprint to drive and deliver value, because we believe in end to end. That's how we have structured ourselves at BlueCall.

[00:01:24] Rory: Great. And what kind of size team?

[00:01:28] Sreemati: The current team that I lead is a product team which combines different cross-functionality. It includes product, design, tech, and we have full-stack developers; we don't separate between them. That all includes about six. We're a team of six people.

[00:01:50] Rory: Great, excellent. And Matti?

[00:01:54] Matti: My name is Matti. I'm working as head of engineering management at Viaplay, which is a part of the Nordic Entertainment Group. I'm overseeing 12 cross-functional autonomous teams within the product side of Viaplay, the streaming product. We are currently roughly 80 developers and designers across those teams, divided into three different product areas. I also just wanted to say that it was a really nice talk to listen to with [?] and Kaja, and they talked about the career development framework for designers. That's something we have developed and implemented just recently at Viaplay, so if you want to hear more about that, just ping me. Happy to share what we have done in that area.

[00:02:53] Rory: I might take you up on that, because it's always interesting with cross-functional teams: what is the career path now? It's not as linear or as traditional as it used to be. And Mikaela?

[00:03:07] Mikaela: Yes, hi everyone. I'm Mikaela, I am the design lead within TV4 Media. I work with our streaming services, C More and Telia Play, but also our linear TV box for Telia. I'm currently design lead for about 11 designers. I come from a background of startups, and then I went to H&M with Kaja, where we had cross-functional teams. Now in TV4 Media we're doing a reorganization, so who knows where we end up, but currently the design team is a team itself. We're not part of any real product teams, like how I worked before, very agile. Hopefully we're striving towards finding some good insights, especially here in this discussion as well, to hear what's working and what's not and what I can bring with me.

Who people report to in a cross-functional team

[00:04:03] Rory: Excellent. That brings up a really good point, because in your design team, I guess, people report to the design manager, the design lead. How does that work in a cross-functional team? Do people still report to their functional leads, or do they report to the team lead? Shree, can you explain how that works in your team?

[00:04:22] Sreemati: In ours, the product leadership is given by the product lead in the team, so they make all the decisions around the product. But the individuals in the team report to their own direct managers. That is pretty much the setting that I've worked with in the past at Fishbrain, but also at Online Global [?] as well. Most of the cross-functional teams had product as the leader to decide the vision and direction of the product that they were leading, but all of them were indirectly managed by their own direct manager who had that specialty.

[00:05:00] Rory: Great, so kind of a matrix organization.

[00:05:02] Sreemati: Yes, exactly. Similar to what Mikaela does, we had a head of design leading all the designers, but they were still part of the individual product teams in terms of the product deliveries.

[00:05:15] Rory: Great. And Matti, is that the same structure for your teams, or how are you structured?

[00:05:23] Matti: No, we're structured in a slightly different way. I'm used to working in that kind of environment as well, but what I've seen from my experience is that it means you have lots of communication going on around that team to make sure of what's happening in the team. For example, you have several managers for different people in the team, and then you have maybe an agile coach that helps out within the team, and then you have a product manager or something like that. We have tried to simplify it at Viaplay, so we have just one manager for everyone in that team. It's the engineering manager that's taking care of the team members when it comes to individual growth and how they can develop in their roles as developers and designers. So the designers in the team report to the engineering manager. Then all the teams have product managers that bring the clarity to the teams on what to do and such. And then we also, of course, push down as much as possible to the team so they can take the decisions themselves and be empowered.

[00:06:31] Rory: That sounds like a great structure, but is there ever any conflict? Does the engineering manager force more of an engineering culture? I guess one of the arguments for having the different leads might be that there's more of a balance in the team.

[00:06:54] Matti: Yeah, you can argue that you cannot be leading people when you don't have a deep understanding of that domain. I would say it's more about having someone that supports you in how you can grow and thrive in your role, and is that sounding board to balance ideas and such, having more of a coaching stance. That said, I think it's super important to have a good foundation to stand on. Therefore I think having a career development framework for engineers and designers and other roles in the team is super important, so you have a clear expectation of what is expected from you in your role.

[00:07:40] Mikaela: Can I just come in, because I think it's a good approach. I think it also depends on how senior you are or how long you've worked. That's a good approach if you're like, "Okay, I'm very comfortable in my role, I mostly just need someone to bounce ideas off, someone to hear me out," to be that kind of coach. But if you're earlier in your journey, it might be that you actually want someone to give feedback on the actual design or the actual development, or you're learning something new. When you're in that part of your career, maybe you need a bit more of a buddy system than just having someone to bounce ideas off and redefine your own thoughts, or structure them in a way, when you still know what you're doing, if that makes sense.

[00:08:31] Matti: Yes, I totally agree. The mechanism we have for that is a community of practice structure, where the designers meet up and can do the kind of thing you talked about, Mikaela: bounce ideas and have someone that can actually review what you're doing when it comes to design. We have that mechanism, and we have it for all the different crafts, so to speak: for mobile developers, back-end developers and so on.

Keeping communities of practice alive

[00:09:02] Rory: Great. Let's jump on that topic, communities of practice, because that's often what people say is the counterbalance to a cross-functional team: you still need that community that focuses very deeply on a particular craft. But one of the experiences I've had is that without having that built into the organization, it might start off really well. There might be three or four get-togethers, everybody's really enthusiastic, but then it just fizzles out and they disappear. What do you do in order to make sure that doesn't happen in your organizations? I'll give that one to Mikaela.

[00:09:45] Mikaela: Oh, putting me on the spot. I think it's a trial and error kind of thing. It's all about iterating. If you try something and you do it four times, but then people start to fade off, or if there is no value in it anymore, then you need to rethink it and maybe tweak it a bit or do something else. I think it's super dangerous to get stuck in "we need to do this four times a week" if the people are not getting what they want from the situation. We need to change it up a bit. What I'm trying to do is approach it and say, let's try it for three weeks and then we can evaluate: can we do something more, do we need more time, less time, and what do we want to focus on? And sometimes you have to stick to it to get more experience, and be more experimental, and see what works and what doesn't and what people are interested in.

[00:10:39] Sreemati: Yeah, exactly. Let the team decide what is valuable, what they want to learn more about, that kind of stuff. And I think if you have a guild or a chapter, it's very important to define the purpose, and that should come from the members of the chapter and the guild as well. What I think can be dangerous, or what we felt was the challenge when I was working at One Line [?], was that we had an engineering manager setup where all the different technical competencies and other competencies were led by one engineering person. What we started to realize was that all the QA people were like, "He doesn't understand what end-to-end QA is. When I try to talk to him about what is important for me, he doesn't get it." Then we did exactly what Mikaela said: we created chapters. But then we saw there was a conflict, because the chapters set certain rules on how to do really good QA, how to do really good design, but then it came into conflict with the product priority. So it's good to experiment, but it's also very important to define what the different purposes are, and what you want to learn from it, so that you don't start to conflict those different channels: the product team, who is the decision maker around what and why, and then, if you have chapters and communities, what is their purpose and how do you incorporate that learning into your different product teams. I think that is very important. We should be very clear about what we are trying to learn and how to incorporate that in our existing channels, so we don't create those conflicts.

[00:12:25] Matti: Yeah, I think it's super important to set a clear purpose. And I think it's also really important to say that a community of practice is not the place where you do work. It's not your second team. If you say that the work that doesn't really fit into the product teams or the cross-functional teams will happen in the guild, then you are on a dangerous path, I would say. Because then you expect people to have two belongings, in two teams, but they don't really have the accountability or the mandate to do the work in the community, so to speak. You are on a dangerous path, and the cognitive load for those people could be really high. So you need to have other supporting structures. For example, if testing is super important for you, then create a supporting team that just focuses on enabling the product teams to do testing in a good way. You need to create that kind of supporting team.

[00:13:33] Sreemati: It's awesome to create those structures when you have a big team of 80 members. I think what happens with us in startups and scale-ups is that it's not possible. What we try to incorporate in our teams is shared knowledge: share your pain, share your understanding, share where you want to be, what that brings to the team and what that brings to the business goal, so people have that respect and that understanding. That's how we are creating it. We don't say that it's just for the product team; we are doing it across the organization, so you understand that it's not just delivering the product. It's also how you're able to sell that product: what pains do they have, how to market that product, what pains do they have, and how we can incorporate that to make the product better for our customers, for our business, but also for our internal teams. That's how we are doing it at BlueCall, to create that shared understanding of our pains and our aspirations.

Enabling teams without becoming a bottleneck

[00:14:31] Rory: Great. I love that example. I guess in startups you're expecting people to wear more hats and take on more, whereas in larger enterprises you can have more dedicated people for that. One thing I wanted to pick up on is that dedicated testing team, that kind of structure. It's becoming quite popular with design ops, with product ops, with those kinds of centralized teams. If I go back to the waterfall days, there were PMOs, and that function helped everybody set up their projects in the most efficient way and avoid inefficiencies. But what ended up happening was they became a huge bottleneck or a huge overhead themselves, because they enforced a process that didn't fit everybody, and then there was a lot of box ticking. Matti, with your example of the testing function, how do you ensure that doesn't become an overhead for people, a big bottleneck where "we have to tick all of these 100 boxes because the testing function have told us we have to"?

[00:15:38] Matti: To clarify, it's not a team that does the testing for you. It's a team that's going to enable the product team to do testing more efficiently: setting up the framework for how you're doing unit testing, that kind of thing, to make it easier for the product team. Not to mandate how to do testing, but: "Here is our support, and here is how you can do testing." Or it could also be that they need to coach the team on how to do tests and such. It's more about a team that enables the product teams. It's not dictating or taking over the testing from the product teams.

[00:16:26] Rory: Great, so I guess a servant leadership type: they're there to support rather than...

[00:16:30] Matti: Yes.

What empowered and autonomous teams mean

[00:16:33] Rory: Great. That leads into a good bit. We started this all about empowered and autonomous teams. What does that actually even mean? If I asked 10 different people, I'm sure I would get 10 different answers, so I'm going to ask three people. What do you mean by empowered and autonomous teams? I'll start with Shree.

[00:16:52] Sreemati: For me, it's a very clear understanding of the why and the what, supported by the company vision and the strategy. It needs to be very clear to everyone what we are doing and why we are doing it, and it needs to connect the dots from the top to the bottom of the team. What I see a lot of the time is that we have grand visions and strategies, created in meeting rooms probably, I don't know how they come up with those strategies, but then they tell you, "Go, team, implement this," and there is a huge discrepancy in how do I really do this. So I think it's the why and the what: why you have this vision, what this strategy is about, and how you really internalize that into the teams that will deliver it. The approach that we have at BlueCall is that we do a top-down and bottom-up approach. We do very shared learning and hypothesis-driven learning. We say that our vision is very strong, but our strategy is adaptable and a work in progress. I think that is the most important part of an empowered team: that it's very clear to everyone what the why and the what are, and it's connected throughout, from the top leadership to the person who is delivering value, till the very end.

[00:18:24] Rory: Great, so it's give the direction and let the team go off. Is that it? Do you just let the teams figure out what to do? Matti, do you have anything to add on that?

[00:18:39] Matti: I think it's really great to have "here is the direction and the vision." But it's also important, from my point of view, that an empowered team has the information they need to do their job. It's both the product managers and other leaders in the company giving the right direction and setting the guardrails. I have seen so many times: "Okay, here is what we're going for. Now we have cross-functional autonomous teams, go ahead, figure it out." And that is too much freedom, to be honest. If you don't have any boundaries or any guardrails, then it's really hard to navigate that landscape, because it's so big and you don't really know if you're going to walk into some invisible fences. I think it's super important to set some guardrails, set some boundaries, and be explicit: here is what you can do, here is how you can navigate this landscape, and with time you can expand it. Give those guardrails and boundaries to the teams so it's clear how they can navigate.

[00:19:59] Rory: Do you have any examples of what a guardrail might be? Because I can see a lot of people going, "Well, I'm telling you what to build, and that's just the guardrails; you can work out the rest."

[00:20:09] Matti: Yeah, great question. For me, if you have a vision, you need to have a strategy to take you to that vision. That could be the guardrails: this is what we're trying to achieve, we're going in this direction, here is where we are right now, the current state, and here are some blockers that we see that we need to remove to go in the right direction. That could be the guardrails. And I think it's also important to say: this is what we're going to do, and this is what we're not going to do. I see many times that people talk about what to do, but not so much about what we're not going to do, and I think that's really important as guidance for the team as well.

[00:20:51] Sreemati: I think that's a great point, Matti. The guardrails are sometimes part of the strategy, but sometimes they can also be a supportive part of the organization. At BlueCall we have very clear priorities. We say there is a priority for the business: if this is the strategy and there is a conflict at any point in how you're delivering it, then we have very clear "this is exactly the priority, this is how you can make the decision if there is a conflict, or reach out to this person." But we let you decide the how, because we don't want to be part of that decision. You are the expert; we are not the experts to decide the how. What really works very well for us, and this is something our founders did when they started to expand, is having very clear strategic guidelines. These are cross-functional, cross-organization strategic guidelines. I think that probably is a reference to what you describe as the guardrails, because they set out very clearly what is the most important thing. Is it more important to be lean or not lean? Then you lean towards being lean, because that is one of our strategic guidelines. Having those kinds of guidelines, that it's more important to be user-centric than to be customer-centric than to be business-centric, means we've made very clear priorities with our strategic guidelines on what is most important for you to think about, not only in the product team but also for the whole organization.

[00:22:23] Rory: Great, so...

[00:22:26] Mikaela: Sorry, go on.

[00:22:29] Mikaela: I just wanted to point out, on this boundary, or what was it called?

[00:22:39] Matti: Yeah, yeah.

[00:22:40] Mikaela: That sounded horrible, like a little box that people get stuck in. But I meant it more like this: if a strategy has a very clear why and what, based on data from customer and business, where the business wants to go versus where the customer wants to go, and if that why is clear enough, then that is actually the only limit that the team should need. This is a dream scenario; usually it's a lot more complex. But if the why is very clear, then I think the team can solve the how, because they know why they need to do it and they know what needs to be done, but how they do it is up to them. If that's set and clear and laid out in a good way, I think that's a good guideline.

Setting direction and vision with input from users and teams

[00:23:31] Rory: It's a great conversation about that. We're not talking about teams having full autonomy to do whatever they want. You're still working for the company; you still have to adhere to the strategy or the vision of the company. How do companies set that direction or vision for the teams and ensure that they're not overly constricting or hampering the teams by setting a vision that might conflict with what the user needs are for that team? Actually, I'll get Mikaela, because your talk was all about setting vision, so I'll get you to answer this one.

[00:24:10] Mikaela: Again on the spot. For me, I think you need to involve users from the beginning. And the users are not just the users who are going to use your product or service; the users are also the people who are going to work in your company. Obviously not everyone; you cannot have 5,000 cooks in the kitchen. But getting feedback from inside the team or in the company when you set a vision, I don't think that's impossible, even though I'm at a very huge company now, and I was at H&M before, where there are thousands of employees. Collecting those small kinds of feedback to set a very clear vision also means that I've contributed to this vision, so I know what it's about. What I've said, my goals, combined with research and data from the customers, have all been intertwined into this strategy. My core belief is, and I think we all agree, that if the customer is happy, then we're going to produce good products. It's the same with our teams: if our teams are happy and feel like they have a purpose and can affect our strategy, then they're going to deliver great products and great experiences. That's where I am.

[00:25:30] Rory: Great. How do companies handle that? Because in a lot of companies, traditionally, the C-suite go into a room, they come out, and then they just tell everybody, "This is what's happening." How do you get that bubbling up of feedback back in to influence the direction and vision?

[00:25:55] Sreemati: I think the only way to do it is to involve everyone. At BlueCall we have the vision set by the founders. When we did our strategy work at the beginning of the year, and we are continuously doing this, we always challenge: is this still a valid vision? Our vision is to make hundreds of millions of people happy every day by helping them improve their mental health. We question that: is that still a valid thing, is there unhappiness because of this? This particular vision came from all the founders experiencing that particular pain. To Mikaela's point, they were the users of their own product in the very first step. They couldn't access preventative mental health care, and they could see that they were unhappy, and this affected their own lives, whether at work or in their private lives. When you form the vision and when you're working on the strategy, you need to include everyone. Of course it's very easy to say for BlueCall, because we are all together, 12 or 15 people. But when we scale our organization, it's very important for us that we are really including everyone in this process.

[00:27:15] Sreemati: We did user and customer interviews to really solidify whether our vision is still valid, whether the pain points are still valid for what we're doing, and whether the solution that we offer is still relevant. That is the customer and the user's voice in it. But then we also included our team in that understanding: are you feeling empowered enough with the direction that we're going, how would you change something, do you feel really connected to this, and will this make you happy? And ultimately also including the business aspect of it: can we deliver this, can we operate this, is this reaching our strategic goals? You need to include all those aspects. It's easier for us to do at BlueCall, but I know that we did this at Fishbrain, so I don't think it's impossible to do. But that has to come from the leadership: it's important for me to set the vision, but be very adaptable, so that if I get feedback from the user, from the customer, from my team that this is not valid anymore, I need to reassess it. You need to be strong enough as a leader to say, yes, my vision is most important, but it's something that is relatable to my users, my team, my customers, not necessarily what I have coined. It can grow as well. I think that requires a lot of strong leadership.

Helping people through the change

[00:28:34] Rory: That's a great point. I guess the leadership needs to change and individuals need to change. I could talk to you for hours, because I'm really enjoying this conversation, but we are unfortunately out of time. I'm going to leave one last question; we're going to go a minute or two over. You talked about helping people change, Shree. Do you have any tips, Matti and Mikaela? There is a lot of change involved in this, and it's different for people. What can you do to try to help people make that change? What can leaders do, and what can be done for leaders as well? Matti?

[00:29:08] Matti: As we said here, it's always good to talk about whether we're solving a problem that the customer cares about, and also to create a strategy for that. Then it's super important to include people and also talk about it all the time. You cannot talk about it too much, I would say. You can find mechanisms for that: having town hall meetings, talking about it in demos when you demo what you have been doing in your products, and such. I think it's super important to do that all the time. You have to talk about where we're heading, what we're trying to achieve and what our strategy is, and also whether it solves a problem that our customer cares about. It also trickles down to the teams. In an agile team you have those ceremonies: you're always doing retrospectives, you have demos and such, and you need to scale that up as well. In my case we have 12 teams and 80 people, and that's just a small part of the organization. Then we have the bigger product, data and technology organization, which is 500 people. We do that all the time: we have those town halls and catch-ups with our CTO and CPO and such. It's super important to be transparent and always talk about what you're doing and how it's going.

[00:30:38] Rory: Great, thank you. And Mikaela?

[00:30:44] Mikaela: Yes, I'll be quick. I'm in a reorganization right now, and I did it at H&M. Changing mindsets from a business point of view seems super easy: "We're just going to change the way we work." But the hardest thing you can do is break a habit. I think empathy, and giving people time, and understanding that it is hard to change your mind, it is hard to change a pattern, a way of working that you've been doing for 10 years. In these reorganizations there's a lot of frustration; we want to run somewhere. But I think you need to give people the time and space to really breathe and land in it, and also to learn a new way of working. That takes time and energy, so I think empathy is super important in this kind of change.

[00:31:33] Rory: Great point to finish up on. I guess it touches on everything that we do. I always say that with software, the people are the hardest part of building software, and it's really about empathizing both with your team, as you were mentioning, and with your users. Thank you very much, I really enjoyed that. As I said, I could keep going for quite a bit longer. Thank you once more to Mikaela, Shree and Matti.

[00:31:55] Sreemati: Thank you. Bye.