How To Manage Transversality In An Agile World

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. So, today I will talk about Transversality, and hopefully, address a big pain that most of the startup and scale-up have nowadays. That is how to implement properly and efficiently transversal topics. Like, topics that will require the work of several squads with all the pain that come with it. Interdependencies, delays, lack of ownership, et cetera, et cetera. So first, let me introduce myself. I'm Benoit Terpereau**, **I'm currently VP Product at Deezer, and building digital products since more than 15 years now. And I'm really passionate about product stuff. So, I am what you can call 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.

So first, let's back up a little bit. In 2014, in the Spotify Engineering blog, Henrik Kniberg, that funny enough, was with us this Monday for a great talk. So, he was a giant coach at Spotify at the time and published a first part of what will be known as the Spotify model. So, soon it will be followed by a part two, and it introduced strong agility concept with the Tribes, the Squads, the Chapter, the Guilds, et cetera. And for good-bad reason, six years after, most of the startups and even big corporation adapted this model, or often part of this model. So, what does it mean concretely?

One element that we pretty much all adopted is the concept of Squads. We now all regroup all the relevant people to implement a digital product in a single team. So, with PM, with devs, with QA, with design, and sometime with PMM also, et cetera, et cetera. And, you know, it brought in 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. You’ve probably all experienced it now. And teams are much more aligned than before, and especially if you plug alignment framework, like OKRs, for example.

But squad driven organization also have downside. And the biggest one is, to me—well, explained by the Melvin E. Conway that you see on the slide. So, that said “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” So, what it means for digital product is that squads may bring UI or UX inconsistency to your digital product. And why? It's because squads will probably act as siloed organization with its own logic, and build different user experience or different interface. And user will feel the difference between different squad and will be able to see in your interface whose squad is building what, and this should be avoided at all costs, in my opinion. And there are solution that we'll see later to avoid that.

Also, Sprints. Sprints are now in the center for Agility rhythm. We are now all in the never ending vortex of Sprints that we feed with features and features and features. So, don't get me wrong, Sprints are awesome and I really love it, it really changed everything in terms of momentum. It drives high paced, high velocity in building digital product, and it's also really good to bring back the power and the autonomy back to the team that now can decide what they will put in the Sprint. And so, it's really in the center for Agility rhythm.

But Sprint also have a downside, especially in multi-squad project context, they will make release date more fuzzy, less reliable. And why? It's mostly due to interdependencies and possible delay. So, 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—for example, if Sprint one have just one or two days of delay, the second team will have the work in Sprint three. So, for one day of delay or two day of delay, you will probably have at the end a Sprint or two of delay. And just imagine if you have a lot of teams, it makes things much more complicated. So, imagine that you run an organization that scaled with more than 10 squads or sometime 20 squads, and you have interdependencies, deadlines, inconsistencies, failure is just around the corner.

But why, really? Beside what I just explained, a lot of time, if you meet PMs, and if you have a global priority that is, you know, your transversal project that you want to push as a product leader or as a CEO, you meet with PM's and everyone will agree, that is something that is really important for the company success. And the issue is like when they come back to their squads and they discuss with their peers within the squad, suddenly it becomes less of a priority. And, it's because when you are a big product and tech organization that promote ownership as a strong value, you will soon realize that there is a clash between global priorities—so, often, transversal priorities and local ones.

So, why? Let's deep dive. What do I mean by that? A global priority. So, a transversal priority that should be addressed by several squads, for example, is something that is pushed at the company level. For example, redesign, a new module, a new market to target, et cetera, et cetera. Where a local priority is a priority that matters within a squad, a feature implementation, a funnel optimization, et cetera, et cetera. So, 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 squad and it is complicated to enforce within each squad.

And unfortunately, when you push a global priority in a squad, again, it will become less of a priority. Because for the squad leaders that truly knows what they should do to move the needle and to have an impact on the company business, if you ask them, the global priority will be always—will have always a less weight than a local priority. So, it's really a question of ownership, alignment. And we touch, basically, with that—the limit of ownership versus alignment. But, we can't stop having global projects and global priorities and transversal products. It's what tied a company together and makes sustainable—and make company more sustainable.

So, now that we have a clear vision—at least, I hope I give you a clear vision of the problem—let me walk you through three solutions that I had the chance to test myself in various organizations and topics. So first, there is the Virtual Team, then the Part-time Ownership, and finally is the Rise of Product Ops.

Let's dive in. I will start with the Virtual Team. So, instead of using your regular organization to implement a transversal project, you will create a temporary virtual team to do it, and you will put all the necessary, all the needed resources within this team. So, organization should be plastic, meaning it should evolve according to the company objective. And the issue with the squad setup that we all have, it is complicated to change as of today. Because a lead tech doesn't want to see some dev away or a lead head of product doesn't want to have one of these PMs to changed team. And usually people don't like change that much. So, that's why the virtual team is a good solution for that matter.

So, let's dive in, and coming back to the company I was mentioning about. And this is the global priority, this transversal priorities that required to work with squad one, squad two, and squad three. So, 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. And you take all the relevant people from all the squad where you need some work to be done. So, in our case, squad once, squad two, and squad three. Your obsession should be to avoid dependencies. So, once the virtual team is created, no one in the other squad should have to work on this project. So, 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. And so, 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. So, 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 like normal.

On the pros, it is a good solution to boost velocity. No dependencies means high velocity here. So, it's really good to meet deadline and go fast. You will see that it will really boost collaboration. Even after the team is dismissed and everyone is coming back within their squads, people across team will continue to collaborate and will collaborate better because they understand each other. They understand the issue that the other may have, and they will better collaborate. And it did, it killed the dependencies, which means that if you used to manage dependencies, it’s the best news you because it's way easier to manage a product that way, let's face it.

On the cons, it will mathematically reduce the squads’ bandwidth as you will take some of their developers. So, local priorities will be slowed down, basically, this is one of the downside. It will also probably complexify maintenance as the team that implement the priorities, those—the virtual team, virtual squad—will be no more, won't exist. So, the squads will inherit of bugs that were not implemented by them, which is always a pain for the teams.

So now, the second solution, it's called Part-time Ownership. So, what do I mean by that? What you will do for this solution is to empower a product manager as a part-time owner of these global priorities, this transversal project, in addition to her or his squad work, and she or he will lead and coordinate the priority. So, this PM basically, on top of his PM role and on top of his responsibility within this squad, will do the discovery for the priority, will push it across the board and across other teams, and report to you on the progress.

So, let's come back to the diagram of our company. And as you can see, the PM of squad one is the leader of the priority, and he will enforce the priorities in squad one, two, and three. And he will be responsible to manage the scrum-of-scrum board, if you have one, for example. So, he will make sure that dependencies are treated in priority and solve issue, if any. And he will also report on progress, which is again, as a product leader really convenient for you.

On the pros, you keep the organization as is, so no change management to do here. Always good, people don’t like change that much so it's good for you. I didn't explain that before, but adding a PM in charge of a global priority helped to have a strong discovery process. So, if your transversal topic, if your global priority is a problem to solve that will involve several squads, then a PM is good to manage that because he knows how to do strong discovery process. Also, he can pair with a tech lead. So, the tech lead of his squad in this squad, in this example—for example, the tech lead of squad one, and if there is some technical things to be done, the tech lead can coordinate with other tech lead. So, it's always good for master product and tech collaboration.

On the cons, you need to be careful because you don't want to burn the PM in charge. You don't want him to be overwhelmed with everything that was going on, in addition to his regular work. So, you have to relieve some of his daily work. And you will have probably a mixed feeling of ownership, because sometime PMs doesn't like that another PM come back and work with them on the backlog. So, you have a bit of change management to do in this area, and making sure that the PM have a strong—I mean, the PM have strong willingness to work with this one PM. And this PM has some addition from various squads.

Then the final solution, the last solution is the Rise of Product Ops. So, what is a product ops? If you don't know, the product ops is kind of a new trending positioning in product that is really raising, especially in scale-ups. So, basically, a project ops usually do several things. Make sure that PM processes are working and are sustainable. I mean, we all push a new process in product that we thought could be really great, and suddenly people stop using it. The project ops will really make sure that the processes are sustainable and it's really great. Make sure that it will also—he or she will also make sure that every PM at the right data to work—will work with data, will work with engineering—so everyone has everything that is required to work, especially around data. And he will also work on transversal project and global priorities, which is good for our problem that we have today.

So, in our case, a project ops will pilot all the transversal projects and will make sure that the execution is done with efficiency and speed. It's a solution that is a bit like solution to the co-ownership, but the main difference is that a project ops is much more a project manager than a product manager. And, you know, as product people we’re not that good usually to manage project, we are better to manage product, so it's good in that matter to bring more project management in our operation.

So, coming back to my diagram and my company, the product ops will play the role of master coordinator, will kick off the project, enforce dependencies, report on progress, 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, to me, can give the project to kick off the product and making sure that everything happened at the right time. So, just take a step back and be in my shoes as product leader, imagine that your CEO comes to you and ask for a transversal product or a global priority, and say, “Okay, you should—we should do that. Please work on that.” To whom you will assign it to? Because by definition, I'm the only transversal people in the group, everyone is in the squad. So, if I come back to one [Inaudible – 17:39] or one PM, he will say, “Okay. 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 that can help you on the transversal side. And the product ops will really solve this issue for you.

On the pros, indeed, you can keep your org. as is. You won't burn any PM, you won't overwhelm any PM. So usually, you will have a strong project management with product ops. For complex projects, this is good. Reporting is strong, because it's at the core of a project ops skills. And under cons, a product ops is not a PM, meaning that if there is some discovery to do, he won't do it well. So, you will have to pair him or her with a PM. Also, you will need some kind of buying from the team that may be reluctant to welcome a transversal project manager within their scope. The same way sometimes they don't like to have a PM to play with their backlogs, they won't like a product ops neither. So, you will have to do some education about this role.

So now, you know everything. I have basically nothing to teach you left or tell you left. But, I wanted to give you some food for thoughts about all of this. So, the first thing that sounds so obvious is about how you sell the project. So, sometime leaders come to squads, and say, “Hey, you have to do this. It's mandatory.” And from my—in my opinion, it’s not the right approach at all. You should sell the project at something bigger, like an opportunity to contribute to something bigger, like, “Please, you should contribute to this project. Everyone will talk about it. It's going to be huge. We'll do PRs. You will be able to tell your friends.” Or stuff like that. “So, do you want to be part of it?” And it's really important to create this positive cycle, also to celebrate after as a global team. So, the squads feel—can feel that they contribute to something bigger, and they are not only part of their squad their team, but to a global company and global team.

Also, that sounds obvious, but you should use visual management to better understand where you stand in terms of performance. So, this is scrum-of-scrum board. And if you want to understand what's going on, you should use it. So, for example, when you have the interdependencies, put strings before—between sticky notes, and you will easily identify those interdependencies and possible point of failure. And usually, you review that every week as a global team, and it's way easier to collaborate between each other. I like Jira, I like Trello. But let's face it, real-life visual management is way better to understand where you stand.

Please, please, please, please. Only one transversal project, only one global priorities at the time. A transversal project should be the norm—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. They will lose their feeling of ownership. So, it is a weapon that you should use carefully. So, if you are doing too many, then it means that your organization is not the right one, and you need to change it.

Also, you should implement a design system. So, I won't go deep in the design system. It's well documented on the web, and you probably already know what it is. But remember the Melvin E. Conway I was talking about before, the design system is the best tool to avoid the siloed squads, user experience and user interface discrepancies and different philosophies. So, you should build one and enforce it across the team. So, if someone is changing something within your product, he should add the design system, also. Every time you do it, then you will reach easily 60, 70, 80, 90% of your product covered by your design system. And it's going to be much more easy to avoid those discrepancies, and the user experience, the user interface will be way better for your user, which is the end goal.

Finally, the same way you should test your prototype, your product—now, we are product people—we should test our solution. The solution that I gave you before, maybe one is not right for your organization. So, tests, try, and after, please share your thoughts with me and within the community. I think, you know, project management is still something new. It's a new field of expertise. And today's methodology, maybe obsolete tomorrow. So, you should never stop learning and testing new things.

So, to sum up, when you need to push a transversal topic, a global priorities, I give you three possible solutions that I think you need to try. First, you create a virtual team that will help you to really boost velocity. Then, you can nominate a PM as a part-time owner for good discovery and good product management, or you could hire a product ops for awesome project management. So 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 after on the web. Thank you very much. Bye-bye.