How To Manage Transversality In An Agile World

Benoit Terpereau at UXDX Europe. Video: https://youtu.be/2lbmyeZ1xI4

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.

Transversal topics and the Spotify model

[00:00:00] Hi everyone. I'm really happy to be here. Thank you so much, UXDX, for having me; it is always good to be part of this great community. Today I will talk about transversality, and hopefully address a big pain that most startups and scale-ups have nowadays: how to implement transversal topics properly and efficiently. That is, topics that require the work of several squads, with all the pain that comes with it: interdependencies, delays, lack of ownership, et cetera.

[00:00:31] First, let me introduce myself. I'm Benoit Terpereau. I'm currently VP Product at Deezer, and I've been building digital products for more than 15 years now. I'm really passionate about product stuff. I am what you could call a product geek, and I love to talk about product management, so please don't hesitate to reach out after the talk. You have my Twitter on the slide, and I'm usually really easy to find online.

[00:01:04] First, let's back up a little bit. In 2014, on the Spotify engineering blog, Henrik Kniberg (who, funnily enough, was with us this Monday for a great talk), an agile coach at Spotify at the time, published the first part of what would become known as the Spotify model. It was soon followed by a part two, and it introduced strong agility concepts: the tribes, the squads, the chapters, the guilds, et cetera. For good and bad reasons, six years later most startups and even big corporations have adopted this model, or often part of it.

What squads and sprints brought, and their downsides

[00:01:44] What does it mean concretely? One element that we pretty much all adopted is the concept of squads. We now regroup all the relevant people to implement a digital product in a single team: PM, devs, QA, design, sometimes PMM also, et cetera. It brought a lot of good things in tech. We are much more efficient, as all the people you need to achieve your goal are with you on a daily basis. It is quicker to implement features that way; I think it's proven, and you've probably all experienced it by now. And teams are much more aligned than before, especially if you plug in an alignment framework like OKRs, for example.

[00:02:44] But squad-driven organizations also have a downside, and the biggest one, to me, is well explained by Melvin E. Conway, who you see on the slide. He said, "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." What it means for digital products is that squads may bring UI or UX inconsistency to your digital product.

[00:03:10] Why? Because squads will probably act as siloed organizations with their own logic, and build different user experiences or different interfaces. Users will feel the difference between squads, and will be able to see in your interface which squad is building what. This should be avoided at all costs, in my opinion, and there are solutions that we'll see later to avoid it.

[00:03:43] Also, sprints. Sprints are now at the center of the agile rhythm. We are all in the never-ending vortex of sprints that we feed with features and features and features. Don't get me wrong, sprints are awesome and I really love them. They really changed everything in terms of momentum. They drive a high pace, high velocity in building digital products, and they're also really good for bringing the power and the autonomy back to the team, which can now decide what they will put in the sprint. So it's really at the center of the agile rhythm.

[00:04:28] But sprints also have a downside. Especially in a multi-squad project context, they make release dates more fuzzy and less reliable. Why? It's mostly due to interdependencies and possible delays. Let me give you an example. If one team is supposed to deliver a development in sprint one for another team to use in sprint two, there is a huge chance that if sprint one has just one or two days of delay, the second team will get the work in sprint three. So for one or two days of delay, you will probably end up with a sprint or two of delay.

[00:05:14] Just imagine if you have a lot of teams; it makes things much more complicated. Imagine that you run an organization that has scaled to more than 10 squads, or sometimes 20 squads, and you have interdependencies, deadlines and inconsistencies. Failure is just around the corner.

Global priorities versus local priorities

[00:05:34] But why, really? Besides what I just explained, a lot of the time, if you have a global priority, a transversal project that you want to push as a product leader or as a CEO, you meet with PMs and everyone agrees that it is really important for the company's success. The issue is that when they go back to their squads and discuss it with their peers within the squad, suddenly it becomes less of a priority.

[00:06:07] That's because when you are a big product and tech organization that promotes ownership as a strong value, you will soon realize that there is a clash between global priorities, which are often transversal priorities, and local ones. Let's deep dive: what do I mean by that? A global priority, a transversal priority that should be addressed by several squads, is something that is pushed at the company level: for example, a redesign, a new module, a new market to target, et cetera. A local priority is a priority that matters within a squad: a feature implementation, a funnel optimization, et cetera.

[00:06:55] As you can see on this diagram, the global priority is transversal, and in my example will involve squad one, squad two and squad three. It's outside of the squads, and it is complicated to enforce within each squad. Unfortunately, when you push a global priority into a squad, again, it becomes less of a priority. For the squad leaders, who truly know what they should do to move the needle and have an impact on the company's business, the global priority will always have less weight than a local priority, if you ask them.

[00:07:33] It's really a question of ownership and alignment, and with that we basically touch the limit of ownership versus alignment. But we can't stop having global projects, global priorities and transversal products. It's what ties a company together and makes it more sustainable.

Solution one: the virtual team

[00:08:00] Now that we have a clear vision of the problem (at least, I hope I've given you one), let me walk you through three solutions that I had the chance to test myself in various organizations and on various topics. First, there is the virtual team, then part-time ownership, and finally the rise of product ops.

[00:08:23] Let's dive in, starting with the virtual team. Instead of using your regular organization to implement a transversal project, you create a temporary virtual team to do it, and you put all the needed resources within this team. Organizations should be plastic, meaning they should evolve according to the company's objectives. The issue with the squad setup that we all have is that it is complicated to change as of today, because a tech lead doesn't want to see some devs go away, or a head of product doesn't want one of their PMs to change team. And usually people don't like change that much. That's why the virtual team is a good solution for that matter.

[00:09:16] Coming back to the company I was talking about: this is the global priority, the transversal priority that requires work from squad one, squad two and squad three. You create a virtual team for several sprints; remember that it should be limited in time. Ideally, you find them a spot in the office where they can meet and work day to day with each other, like a regular squad. You take all the relevant people from all the squads where you need some work to be done, so in our case squad one, squad two and squad three.

[00:09:54] Your obsession should be to avoid dependencies. Once the virtual team is created, no one in the other squads should have to work on this project. In this example, we take the PM from squad one and also one dev from squad one. We take two devs from squad two, one dev from squad three and the QA from squad three. Those people should have the right knowledge and the authority to implement everything that is required in their scope, so again, you don't have any interdependencies. It's much more lean, and it's way easier to manage your deadline, for example. And the other squads can continue to push their local priorities as normal.

[00:10:42] On the pros, it is a good solution to boost velocity. No dependencies means high velocity here, so it's really good for meeting deadlines and going fast. You will see that it really boosts collaboration. Even after the team is dismissed and everyone comes back to their squads, people across teams will continue to collaborate, and will collaborate better, because they understand each other. They understand the issues that the others may have. And it kills the dependencies, which means that if you used to manage dependencies, it's the best news for you, because it's way easier to manage a product that way, let's face it.

[00:11:28] On the cons, it will mathematically reduce the squads' bandwidth, as you take some of their developers, so local priorities will be slowed down. That is one of the downsides. It will also probably complicate maintenance, as the team that implemented the priority, the virtual team or virtual squad, won't exist anymore. So the squads will inherit bugs in things that were not implemented by them, which is always a pain for the teams.

Solution two: part-time ownership

[00:12:08] The second solution is called part-time ownership. What do I mean by that? For this solution, you empower a product manager as a part-time owner of the global priority, the transversal project, in addition to her or his squad work, and she or he will lead and coordinate the priority. On top of their PM role and their responsibilities within their squad, this PM will do the discovery for the priority, push it across the board and across other teams, and report to you on progress.

[00:12:47] Let's come back to the diagram of our company. As you can see, the PM of squad one is the leader of the priority, and he will enforce the priority in squads one, two and three. He will be responsible for managing the scrum-of-scrums board, if you have one, for example. He will make sure that dependencies are treated as a priority, and solve issues, if any. He will also report on progress, which again, as a product leader, is really convenient for you.

[00:13:25] On the pros, you keep the organization as is, so there's no change management to do here. That's always good; people don't like change that much. I didn't explain this before, but adding a PM in charge of a global priority helps you have a strong discovery process. If your transversal topic, your global priority, is a problem to solve that will involve several squads, then a PM is good at managing that, because he knows how to do a strong discovery process.

[00:13:58] Also, he can pair with a tech lead: in this example, the tech lead of his squad, squad one. If there are technical things to be done, the tech lead can coordinate with the other tech leads. It's always good for product and tech collaboration.

[00:14:21] On the cons, you need to be careful, because you don't want to burn out the PM in charge. You don't want him to be overwhelmed by everything that's going on in addition to his regular work, so you have to relieve him of some of his daily work. You will also probably have mixed feelings about ownership, because sometimes PMs don't like another PM coming in and working with them on their backlog. You have a bit of change management to do in this area, making sure that the PMs have a strong willingness to work with this one PM, who is adding things from various squads.

Solution three: the rise of product ops

[00:15:07] The final solution is the rise of product ops. What is product ops? If you don't know, product ops is a new trending position in product that is really rising, especially in scale-ups. Product ops usually does several things. They make sure that PM processes are working and are sustainable. We all push a new process in product that we thought could be really great, and suddenly people stop using it. Product ops really makes sure that the processes are sustainable, and it's really great.

[00:15:44] He or she will also make sure that every PM has the right data to work with, and will work with engineering, so everyone has everything that is required to work, especially around data. And he will also work on transversal projects and global priorities, which is good for the problem we have today. In our case, product ops will pilot all the transversal projects and make sure that the execution is done with efficiency and speed.

[00:16:18] It's a solution that is a bit similar to the co-ownership one, but the main difference is that product ops is much more a project manager than a product manager. As product people, we're usually not that good at managing projects; we are better at managing products. So it's good in that respect to bring more project management into our operations.

[00:16:45] Coming back to my diagram and my company: product ops will play the role of master coordinator. They will kick off the project, enforce dependencies, report on progress and put in place the right data so we can track progress, et cetera. It's also good for you as a product leader to have someone you can give the project to, to kick off the project and make sure that everything happens at the right time.

[00:17:15] Just take a step back and be in my shoes as a product leader. Imagine that your CEO comes to you and asks for a transversal project or a global priority, and says, "OK, we should do that. Please work on it." Who will you assign it to? Because by definition, I'm the only transversal person in the group; everyone else is in a squad. If I go to one [inaudible] or one PM, he will say, "OK, I love your idea, I love this transversal project, but it's not my role. It's not my scope." So it's good to have someone who can help you on the transversal side, and product ops will really solve this issue for you.

[00:17:56] On the pros, indeed, you can keep your org as is. You won't burn out any PM; you won't overwhelm any PM. Usually you will have strong project management with product ops, and for complex projects this is good. Reporting is strong, because it's at the core of product ops skills.

[00:18:19] On the cons, product ops is not a PM, meaning that if there is some discovery to do, they won't do it well, so you will have to pair him or her with a PM. Also, you will need some kind of buy-in from teams that may be reluctant to welcome a transversal project manager within their scope. In the same way that sometimes they don't like having a PM play with their backlogs, they won't like product ops either. So you will have to do some education about this role.

Food for thought: selling the project and visual management

[00:18:56] Now you know everything; I have basically nothing left to teach you or tell you. But I wanted to give you some food for thought about all of this. The first thing sounds so obvious: it's about how you sell the project. Sometimes leaders come to squads and say, "Hey, you have to do this. It's mandatory." In my opinion, that's not the right approach at all.

[00:19:25] You should sell the project as something bigger, an opportunity to contribute to something bigger: "You should contribute to this project. Everyone will talk about it. It's going to be huge. We'll do PR. You'll be able to tell your friends," or stuff like that. "So, do you want to be part of it?" It's really important to create this positive cycle, and also to celebrate afterwards as a global team, so the squads can feel that they contributed to something bigger, and that they are not only part of their squad, their team, but of a global company and a global team.

[00:20:04] Also, and it sounds obvious, you should use visual management to better understand where you stand in terms of performance. This is a scrum-of-scrums board, and if you want to understand what's going on, you should use it. For example, when you have interdependencies, put strings between sticky notes, and you will easily identify those interdependencies and possible points of failure. Usually you review that every week as a global team, and it's way easier to collaborate with each other. I like Jira, I like Trello, but let's face it, real-life visual management is way better for understanding where you stand.

One transversal project at a time, and a design system

[00:20:50] Please, please, please, please: only one transversal project, only one global priority at a time. A transversal project should not be the norm; it should be the exception. So just one at a time. Otherwise it will confuse people, your leaders will lose confidence, and they will lose their feeling of ownership. It is a weapon that you should use carefully. If you are doing too many, then it means that your organization is not the right one, and you need to change it.

[00:21:27] Also, you should implement a design system. I won't go deep into design systems; they're well documented on the web, and you probably already know what one is. But remember Melvin E. Conway, who I was talking about before: the design system is the best tool to avoid siloed squads, user experience and user interface discrepancies, and different philosophies. You should build one and enforce it across the teams.

[00:21:54] If someone is changing something within your product, he should add it to the design system as well. Every time you do that, you will easily reach 60, 70, 80, 90% of your product covered by your design system. It's going to be much easier to avoid those discrepancies, and the user experience and user interface will be way better for your users, which is the end goal.

[00:22:20] Finally, in the same way that you test your prototypes and your product, since we are product people, we should test our solutions. Of the solutions that I gave you, maybe one is not right for your organization. So test, try, and afterwards please share your thoughts with me and with the community. I think product management is still something new. It's a new field of expertise, and today's methodology may be obsolete tomorrow. So you should never stop learning and testing new things.

[00:22:53] To sum up: when you need to push a transversal topic, a global priority, I've given you three possible solutions that I think you need to try. First, you can create a virtual team, which will really help you boost velocity. Then you can nominate a PM as a part-time owner, for good discovery and good product management. Or you could hire product ops, for awesome project management. With that, thank you very much for having me. It was really cool to be with you, and I would be glad to talk to you either during this event or afterwards on the web. Thank you very much. Bye-bye.