Is there a secret sauce for successful teams and products?

Matti Klasson at UXDX Community: Europe West. Video: https://youtu.be/OLwcDQMtYG0

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.

Introduction: Viaplay and the question of a secret sauce

[00:00:00] Hi all. Today we'll talk about how to create an environment for high-performing teams that can solve problems customers care about, and is there a secret sauce?

[00:00:14] So first a little bit about myself. My name is Matti, and I've been working with systems engineering for more than 20 years, and 10 of those years I have been working in an agile environment. I have experience from scale-ups in fintech, gaming and media, and currently I'm overseeing 12 agile teams across three product areas as head of engineering management at Viaplay. Those teams consist of 80 developers and designers, and I have a passion about leadership and creating happy and productive work environments.

[00:00:54] So first a little bit about Viaplay. Viaplay is a streaming service across the Nordic countries, and currently we expand our product across Europe and later this year also into the US. We are a tech organization and we develop the main part of our tech and product in-house. We're using agile methodologies and we're data driven. We also produce our own content, that we call the Viaplay Originals.

[00:01:21] So a little bit of what I will touch base on today. We will talk a little bit about functional versus cross-functional teams. I think it's important to set that a little bit in the context of where we are at Viaplay. Then we're going to talk about the current state of Viaplay, also some lessons learned we had so far, and what is the next step for us to evolve our organization. And then we'll end up with some key takeaways. So let's get started.

Functional versus cross-functional teams

[00:02:00] So, functional versus cross-functional teams. I think it's important to have that in mind. I'm sure that many of you are familiar with this already. But when you have a functional team, each function focuses on their area of expertise, which means you have lots of handovers and increased communication. The big risk is that things fall in between the cracks, and you will have longer lead times and lower quality, and unhappy customers and unhappy teams.

[00:02:32] So to avoid that, you will have everything in one team, like a cross-functional team. The team have all the competence they need to deliver the product to the end. Less handovers, reduced risk that things fall in between the cracks, and you will have reduced lead times and higher quality, and happier customers and happier teams.

[00:02:57] But what happens when the product gets more complex and the customer demands more? What happens with the team if you add more competences and expectations to your cross-functional teams, such as, hey, we need to have some machine learning, cloud infrastructure, or we need some continuous delivery competence in the team, or how about availability and such? Well, the communication and handovers between team members will increase, and lead time will start being longer, and the team over time will be slow. So we want to have small cross-functional teams that can deliver value at speed.

[00:03:43] So when you're growing and your teams are growing, you need to think about the supporting structure a cross-functional team might need. And these different team types that I'm going to just touch base on, you can read more about it in the book Team Topologies, which describes this really, really well, and I highly recommend that book.

[00:04:06] So you can have a subsystem team, we can call it a complicated subsystem team, that handles all things when it comes to machine learning and such. Or you might need a cloud infrastructure team that's acting as a platform team, as a service. Or an enabling team that helps the team to set up the continuous pipeline and such. So what you want is to reduce the complexity and the cognitive load for the product development team, so they can focus on bringing value to the customer at speed. So then you might need those kinds of supporting structures. So I think this is good to have in mind when we go into and talk about the organization at Viaplay and the current state, where we are at the moment.

How Viaplay is organized: product areas, teams and missions

[00:05:04] So at Viaplay, in the product organization, we have organized ourselves and our teams around our customer funnel, to maximize the total lifetime value of our users. We are organized in product areas and cross-functional product teams, as you see, and each team has a mission that is connected to the product area mission and our product strategy. And a team mission lives for about 12 months, plus minus six months, depending on the scope of that mission.

[00:05:43] And our mission system works like this. It has a few foundations that it's built on. So at the bottom we have the long-term strategic intent, and this is based on the Nordic Entertainment Group overarching strategy: what are we heading for as a company as a whole? And upon that we have the product areas and the product area mission. And those long-term strategic intents guide us when we set up our product area missions, and the product areas, and what kind of product areas we need across our customer funnel.

[00:06:26] In each product area we have the teams, and each team has the team missions that we talked about. And those team missions are based on a problem statement or business opportunities with some key metrics. And to unpack and explore a mission, the teams define bets that will prove or disprove a hypothesis around those missions. In most cases the teams start with a small bet just to get going and to collect the first data points, and then over time the bets can be bigger and bigger, because we collect more data, we know more about the customer and the problem we want to solve.

[00:07:09] And it also gives us an opportunity to see when we're going to end the mission or not, when we have done lots and lots of different bets. So I would say this is a very iterative process, and experiment driven.

Guilds as a learning structure

[00:07:30] On top of that we also have some other structure that helps us as an organization to learn across the teams. So we have implemented guilds. A guild is a community of practice. This is a group of professionals who share a common interest and passion in the area of work, and the community of practice allows participants to share challenges and experience and even create some best practices to follow.

[00:08:02] And at Viaplay at the moment we have those structures for web developers, back-enders, Android developers, iOS developers, big screen, that is TVs and such. When they are in the product teams they focus more on how to deliver their part of the product, but in the guilds they can take the challenge they might have in the product teams to the guilds and discuss it and bounce some ideas and share some learnings and gain new knowledge. So this is our way to create a learning organization across our product teams and product areas.

What we have learned so far

[00:08:49] So what have we learned so far working in this setup? And we have done this for almost two years now. First and foremost, it's a learning, and we constantly need to evolve our organization. But here's some learnings that we will try to address with some next steps as well.

[00:09:18] So we see that it's hard for native developers to work on tech improvements within the product teams, because cross-team dependencies exist. For example, when you're working in the Android tech stack, that's a monolith, it's very hard for one Android developer in the product team to take everything into consideration when it comes to improvement of that tech stack, because there are so many different other teams that are dependent on that tech stack, it's a monolith. So what's happening is that that person might need to collaborate with many, many others to understand the complexity of that, and that increases the cognitive load of the team and that team member, and also slows us down.

[00:10:08] We also see that without clear expectations on the product teams versus the guilds, tech improvements happen more likely in the guilds, where you can bounce those ideas and challenges that you have, without awareness in the product teams. So we don't really know what is the debt we have, or the improvements that we need to do. So we might need to set some more clear expectations, what is the guild and not, for example some guardrails. We need to set that in place.

[00:10:46] We also see that the guilds can be a bottleneck when developers need to balance their time between the guild and their product team. This is the same thing with the expectations. Do I belong to my craft in my guild as an Android developer, or what is my belonging to my product team where we create new features for our customers? So it's very hard to see where should I put my time and when and such, if you don't have those structures in place. So we see it is very important to tackle those kinds of things when we're going to evolve our organization.

Next steps

[00:11:24] So this is what we believe are the next steps. We need to reconfigure the guild to be a true community of practice. Today many guilds are acting as a second team, and that also increases the cognitive load and complexity for our team members and such. So we need to do that reconfiguration of the guilds. And to be able to do that we need to also find what is happening in the guilds today that we could put in another place, find a new home for that.

[00:12:05] For example, we need to install some mechanisms to handle tech debt within the product team, so it doesn't end up in the guilds. And we also need to find ways to visualize actually what is the debt we have in the organization. So this is something that is currently ongoing, to install those things and reconfigure the guilds to become a community of practice.

[00:12:28] We also see that we need to install some guidelines regarding pull requests, or reviews of your code. We always believe it's good to have a second view on your code before you put it into production. So we have that, but that said, many times when you need a second pair of eyes you go to the guilds, because there are your craft people, your fellow Android developers or your fellow back-end developers. So we want to have it closer to the teams and closer to the product areas. So we're now installing those kinds of guidelines, how to do that in another way, so we can improve that flow, so to speak.

[00:13:19] The fourth thing we're thinking about, and that's just an ongoing discussion, is how can we deploy some enabling teams for our native platforms, because that is our pain point at the moment. It is a monolith, and we need to handle it as a monolith and not as a distributed microservice technology. So this is the fourth thing we're looking into, how we can evolve our organization in a good way.

Takeaways

[00:13:52] So some takeaways. We see that small teams trump big teams. Consider splitting your team when they grow, as I mentioned in that slide about cross-functional teams when they're growing, and put up some supporting structure. And that's something we're doing right now, to continue to have some enabling teams. We see that you need to do that when you're growing your organization and the teams get bigger and bigger, and you see the outcome of the team is slower and slower. You need to consider if you need some supporting structure, or you need to split the team.

[00:14:33] Make missions, if you're going to have a mission system, make them tangible and concrete. That's also something we have seen: if your team mission is too fuzzy or it's too big, you can fit almost everything in that mission, which means that it will never end. You never know when you're done with your mission and you can take on a new challenge. So make sure you make the missions very tangible and concrete, and have some clear KPIs that you want to push or change with your mission.

[00:15:15] And this is taken from Team Topologies again, that everybody needs a family, product teams too. So consider, when you scale, to have supporting structure with your product teams. As I mentioned before, this is critical when you're scaling your organization, that you have the right supporting structure, so you can keep your product teams as small as possible so they can focus on delivering products that the customer loves, and solving problems the customer cares about, at speed.

[00:15:48] And lastly, experimenting. That's critical. Find the local needs in your organization, try out small then scale out. Don't try to find one golden hammer or something. Experiment a lot, and always think about that: good enough now, safe enough to try.

[00:16:14] So, the last question: is there a secret sauce? You need different components to make the dish taste good. You need to balance those components to match your taste. And everybody's taste is different. So no, there's no secret sauce. Thank you.