From Cross-Functional to Cross-Purposes: Why Collaboration Falls Apart Over Time

Mihaela Draghici at UXDX EMEA. Video: https://youtu.be/TZsw2Ap1wKs

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.

A sequel about people, not AI

[00:00:09] Thank you, Chris. Hello everyone. Welcome back from lunch, I hope you enjoyed it. It's a great pleasure for me to be here back on the UXDX stage. And before I start, I have a disclaimer to make: my talk today is not going to be about AI. Sorry, bummer. It's going to be about people, and about people working together.

[00:00:40] It's actually a sequel to the talk I did at UXDX two years ago in Dublin, where I spoke about the actions we took in order to break down the silos existing between product teams and business teams. And today I want to tell you a bit about what happened after that, so what happened over the last two years. A few details of specific actions that we took and how things worked out for us, some of our wins as well as some of our challenges, what we learned when trying to understand why people still tend to drift apart even though they do their best to work together, and also some practical strategies going forward, things that we want to focus on to maintain alignment, to maintain collaboration.

The problem: silos between product and business

[00:01:37] Just for some context, the problem we identified over the years working in our setup, in cross-functional product teams building digital products for various departments of the Volkswagen group — I'm talking here about procurement, production and logistics, sales departments — were the silos existing between the product teams and the business teams that were meant to be working together. These silos made it difficult for the product teams to be included in decisions regarding the vision and the strategy. Usually these decisions are made in executive committees where plans are set, and we would be presented with these plans and expected to deliver against them.

[00:02:24] So there was very little room for us to negotiate on coming up with new solutions, new ideas, changing course based on data we collect on the products or based on user research. And at the same time it was hard to give clear visibility over the work progress, and sometimes also showcase the value of certain actions that we took, things like validating ideas with prototypes, things like setting up analytics tools to make sure that we collect the right data to understand how our products impact the users we build for.

[00:03:01] And last but not least, we noticed that it was difficult for us to actually advocate for what we were trying to push: our values, our principles of user centric product development, of outcome-driven product development. And in turn the business teams were reporting similar challenges: alignment on product decisions, better understanding of some of the work we do, but also better understanding from us over the work they do.

[00:03:30] And this happened because, as I said, on one hand we have cross-functional teams with designers, software engineers, product managers, data engineers and other technical roles. And on the other hand we'd have the business teams working with us, and here we'd have experts, domain specialists from different departments that we collaborate with. We'd have what we call a business PO, who is generally our interface with the corporate landscape. And these people would sync regularly, have planning sessions, keep each other updated on the work progress or on decisions made. But we noticed that over time they were working in isolation.

The solution: hybrid cross-functional teams

[00:04:08] So the solution we came up with in order to address these challenges and have a better ongoing collaboration with our stakeholders was to restructure our teams and integrate directly the business stakeholders in what we call hybrid cross-functional product teams. What that means is we would all work together on a product topic, have a shared ownership and also shared responsibility over the success and the failure of that specific solution. We'd have a shared vision, common ways of working, common tools, and try to push for a truly cross-functional collaboration and for promoting this change in mindset towards a more user centric approach and a more outcome-driven product development approach.

[00:05:02] What does this mean in practice? Rather than our product teams performing all these actions throughout the product life cycle in isolation and then presenting results to the business stakeholders and trying to get the buy-in, or giving updates on the work progress, we decided to actively include our business stakeholders, experts, domain specialists from the different departments we work with, into these activities, and work together at each stage in the product cycle. We would have what we call a working model agreement, and align on responsibilities and different activities that we perform in each of these stages.

[00:05:45] What else we did was to actively include our business stakeholders in common team activities and ceremonies. And in turn we were included in high level strategic steering committees, or high level management groups, where we would generally not have access to. And what we noticed over time was that this was helping people get closer together, build more trust, helping people get a better understanding of each other's side, and actually build more empathy towards one another.

[00:06:23] One other aspect that I would like to mention is regarding pairing. Our software engineers work in pairs as part of our extreme programming practices, so we decided to diversify these pairs and extend them to pairs of POs and PMs, or business POs and designers, or designers and engineers, and facilitate as much as possible contexts where these people from different functions can continuously work together and continuously exchange knowledge.

How we measured whether it was working

[00:06:59] Now, how did we want to see whether this is working or not? Firstly by collecting feedback from the teams through regular health checks. We have feedback sessions, we actually run interviews and surveys amongst our teams, just to understand how things are working and where we need to adjust. We wanted to look also at product success: how the products that we deliver are being used, do they have the impact expected, do they bring the business value that we expect. And also to look at future investments on the products that we roll out, so for future improvements on these products, but also investments on upcoming product initiatives.

[00:07:41] Some examples of what happened over the last two years. We managed to successfully roll out several products across sales, procurement, production and logistics. Quite complex, I would say. We managed to introduce continuous discovery practices across a couple of our products, across a couple of our teams, and we also managed to have team-led experiments that brought a lot of business value.

[00:08:12] To give you an example, for a product that we built last year for the production department, so for the factories: within the team, pairing with one of the IT specialists working in the factories, we managed to create a tool, a box, that simulates a machine connected to the factory, so that we create our little testing lab in the office and are able to test ideas and experiment little by little before actually investing in building a full-on solution.

[00:08:48] And as I said, we look at feedback from the team. Actually very recently, I think it was about a month and a half ago, we ran a series of interviews across several of our teams working in these models. And also by collecting feedback throughout the last couple of years, we've seen a lot more confidence coming from the people working in the teams around understanding the problems that they are solving, understanding the people that they are solving those problems for. We've seen a lot of engagement and involvement from our business stakeholders, who are generally very responsive. They're very willing to contribute with their expertise and their knowledge and provide really useful insights that help us all together come up with better solutions for the problems we find.

[00:09:42] And in turn we've also seen a lot of appreciation from our business colleagues regarding the openness of, let's say, our software engineers or architects or designers to better understand how things are working in the procurement department, for example, or how things are working in a factory, why certain processes exist, why certain things are done the way they are done.

Why collaboration still falls apart

[00:10:07] Now, with all these changes and positives, we've seen that over time collaboration still falls apart, and we wanted to understand why. Our key takeaways from this were around three points that I would like to discuss. Hidden structural forces pull us back to the old ways. They define habits that in turn create mindsets that are much more difficult to change and take a long time to change. And at the same time, we don't even notice, we don't really speak the same language, and I'll talk about this in more detail in a second. And all these misalignments of perceptions, misalignments of expectations create communication gaps, communication problems, that lead to lack of motivation, lack of engagement and lack of trust in many cases.

[00:11:13] I'm going to take them one by one and go into a bit of detail so that you understand some examples from our context. First of all I would like to talk about processes, whether it's regarding budgeting, governance, anything around in a company. Actually Rory mentioned this earlier in the morning: processes exist, and they're necessary, and they exist in every company, and they're there because they're meant to help make things work, but sometimes they also create challenges. We do have internal processes that we need to take into account.

[00:11:46] Just to give an example: budget planning cadences versus product planning cadences. Business departments usually approve budgets annually, sometimes over three year or five year periods of time. And these approvals happen based on waterfall-like style project milestones, like a preset list of requirements that are expected to not change. Whereas the product team works quarterly, and wants to leave room for experimentation, for iteration. So the result is friction, obviously. The business wants commitments, we often hear, oh but we already promised this to our management, we have to deliver it. And in turn the product team wants to stay lean and adaptive.

[00:12:44] There are of course processes that are essential for business operations. Again, we live in an industry that has a lot of regulations and a lot of limitations and restrictions that we need to take into account. So, for example, working on products for the production and logistics departments, there are a lot of limitations that we need to operate with and we need to take into account when building products. So it means that we need to be aware of those from the very beginning.

[00:13:15] And because we work in a very big organization with a very complex structure, we've noticed that sometimes we don't have a clear understanding over people's roles and responsibilities. And in that complexity, sometimes we understood that people have, or are expected to do, the same tasks, have the same responsibilities. So in some cases we'd be duplicating work or even competing with each other, trying to achieve the same thing. So we realized it's very important to align and have a lot of clarity over the people involved, the roles involved, but most specifically what each person does and what is expected from each person to do.

[00:14:04] And also, because of the complex structure and the fact that it's a big organization, when it comes to decision-making we have a lot of steering committees and groups, and generally a lot of people involved in decision making, which makes that a very slow process, whereas people in the product team want to move forward very fast. So again there's friction on this side.

[00:14:34] And because business processes dictate ways of working, that builds up habits and mindsets, and we've noticed that the project management mindset is still very strong. We often hear things like, well, this is the set of features, we just need to deliver it, and once that's done we move on to the next topic. There's no discussion about it.

[00:15:01] Another point is around time and availability. We work with colleagues from different departments that have to dedicate more of their time to being involved in activities on the product. So actually this requires a lot of effort, a lot of dedication, so it's harder to sustain over time. So even though initially people are very engaged and very driven and very motivated, that kind of drifts away over time because it requires a lot of effort.

[00:15:37] And last but not least, we looked at the team rituals to try and understand: do people still find value in certain ceremonies that we do, or do they just do them because they're in the calendar, it's on the agenda, let's go to this meeting? Do people still see them as useful in helping them work better together, or helping them achieve their goals?

Language misalignments

[00:16:02] And last but not least, I want to talk about language misalignments. Because here it's not only about the fact that we have language differences, like speaking German versus speaking Portuguese or Spanish and English and so on. I'm talking about speaking different languages across industries, across domains of expertise or areas of focus. And when people working in the same team unknowingly speak different languages, obviously we don't understand each other, we don't get along, communication breaks down, expectations become misaligned, and collaboration really suffers from this.

[00:16:45] I want to give you some examples in our context. I hope you'll find them interesting and I hope you can relate in your respective environments as well. First of all, we come from different worlds and we have different realities, and the language that we speak in these worlds shapes these realities. So it's kind of wrong, and honestly unfair, to expect a software architect to know everything about what happens in a factory, or what specifically happens on the supply chain. And in turn, to expect from, for example, a sourcing specialist to know much about design thinking or extreme programming, or what test-driven development is. So it's important to be aware of these differences, and help people onboard and help people learn the language and the terminology specific to the world they work in, so that they can collaborate with each other.

[00:17:52] Another aspect we noticed was the fact that we still very frequently use words that carry a very heavy waterfall baggage, and that we need to be mindful of the context we use these words in, because they do influence the way we think, the way we behave, the decisions we make.

[00:18:15] And another point is regarding the fact that there are people in the same team working together using the same words, but actually meaning completely different things by those words. And I'm talking here about differences of anything from agile, to what experimentation means, or what the expectation is over feature done, or over an MVP.

Discovery and scoping mean different things

[00:18:40] I want to give two more examples of two specific terms that we're using very frequently in our environment that are being understood differently, and what that understanding misalignment creates in our environment when we work together. And the first word is discovery. It was mentioned already today several times. For the product teams it means the problem space: exploring problems, identifying problems, prioritizing them, coming up with some ideas regarding what potential solutions could be after we fully understand the user flows, the user needs and so on.

[00:19:23] But for the business, generally it means understanding what the requirements are, usually by going and asking users what do you want or what do you need. In some cases it means validating an already existing idea, just confirming, okay, yeah, this is how we want it to be done. And also it comes with the expectation that we already have a fully fledged solution and we're ready to develop it, if not development has already started.

[00:19:54] And we have an example from last year, when collaborating on a product for the sales department. One of our colleagues from the sales department was, let's say, pushing to start development, because we already know the solution, we know what we want, so why are we spending time planning for research? Whereas the designers and the engineers in the team wanted to better understand the context and better understand the user flow, to then confirm if some of the ideas we come up with could be feasible and could be applied in that context. So we spent a lot of time actually trying to align on whether we do research or not, instead of actually starting to do it. And we only managed to reach an agreement after we aligned on the meaning of discovery and what the expected goals are, so what the expected output is after this phase.

[00:20:50] And the second term I would like to mention is scoping. One word that we usually use quite frequently when we talk about a series of workshops that we organize before starting collaboration on any new products. And in these workshops we want to discuss overall the business problem, understand business risks, and ideally align on what the next steps would be. But for some of our business stakeholders this word means scoping of a project, or scoping of requirements. So even though we pre-align on what's expected from the workshop, we would still be presented with already fully fledged solutions. So we had to learn our lesson and try to rename these workshops, and adapt the name of the workshops depending on what we were expecting out of each of these sessions. So whether we want to talk more about the problem, or in some cases plan a project.

What we want to focus on going forward

[00:21:53] And I want to leave you with some points of optimism, I would say. Some areas that we want to focus on going forward, to maintain collaboration and maintain alignment, based on what we learned that works. First of all, invest in pairing, because we've noticed over time the value of these diverse pairs.

[00:22:18] Secondly, not assume that everyone has the same understanding of the words that we use in the workplace, of the words that we use when working together. So make sure that we have a shared glossary of terms, a shared dictionary that people can contribute to. So make that easily accessible and easy to update, so people can revisit regularly and contribute to it regularly.

[00:22:45] Another part where we want to keep pushing and invest in is rotations and work exchanges, to give our colleagues the opportunity to learn more about the realities on the ground. And here we're talking about working in different locations, so for example from Lisbon going to different locations across Germany, or the other way around, but also working with colleagues in their departments, spending some time with colleagues from the procurement teams, or the other way around, working actually in the factory alongside some of our colleagues, or the other way around. These exchanges really help people have a better understanding of what's happening in each other's domain, and get closer to one another.

[00:23:36] Another point is about regularly checking in with the teams to make sure that things are still working okay, and also understand what's not working, to be able to improve. And also revisit some of the things that we set in place at one stage. So for example the working model agreement: revisit it at each stage in the product life cycle, but also revisit it every time people in the team change. And the same with the role expectations and the roles and responsibilities: revisit those regularly, and not assume that whatever was decided in the beginning is valid for a period of two, three years.

[00:24:15] We were talking about processes and structures in place, and the idea was that we need to use these in our favor, and we need to adapt these depending on the departments we collaborate with, and the products we work with, and the people we work with, and not expect that we've set one structure in place and it can apply in the same way across all departments.

[00:24:36] And we need to continuously collect feedback. Look at team satisfaction, team engagement, look at the products that we build, and look at the trust that people have when they work together. So the idea is to continuously iterate and continuously improve this collaboration, to apply the practices that we do in building products also onto the ways of working. Because ultimately the best cross-functional teams are not the teams that don't have any collaboration problems, that doesn't exist. They're the teams that notice these problems sooner and address them faster.

[00:25:15] And I want to end with a question for you all. I am really curious to know what your collaboration challenges are in your organizations, and what you do to address them. So I'm happy to discuss this. Feel free to reach out throughout the day, I'm at the event today and tomorrow, and also feel free to reach out online. Thank you very much, have a lovely day.

Q&A

[00:25:41] Mihaela: Thanks, Chris.

[00:25:44] Chris: I propose we do something. Why don't you— okay, we already have some questions in, but feel free to share some of your challenges here, and you can vote up if you also have the same challenge. I noticed some very strategic future tenses in your presentation, right? These are things you're going to be doing.

[00:25:58] Mihaela: These are things that we have done, right, and we've seen are working, yes, and we want to continue investing in.

[00:26:08] Chris: Okay. So you feel like you have a roadmap to help break down those silos again, or can we expect the third part of this trilogy where you'll come back?

[00:26:14] Mihaela: Potentially I'll come back in one year or two years, yes.

[00:26:17] Chris: Okay. What are the early signs? How's it going, the changes?

[00:26:20] Mihaela: As I said, I think that the things that I showed towards the end are the actions that we took that we saw are bringing us value, are helping us in bringing people together. And just to share a funny side story, yesterday on my way to the airport I met with one of my colleagues on the street randomly, and he said, oh, tomorrow I'm going to Hanover to work with my colleagues there for two weeks, and he was very excited about it. So he's one of our data engineers and he was going to work in the marketing department with a team there. So he was very excited about that, because that is exactly what we're trying to do: promote this exchange and interaction between people, and bringing them closer together, and creating those contexts where they can better understand their own realities.

[00:27:13] Chris: It sounds like you have very thoughtful leaders, maybe, or something that really is lending a lot of patience to this process. And I'm wondering, what do you credit for the ability to break down silos and then see them form again? And maybe any advice you have for people of how to confront the cold start problem, if they're not in an organization like that.

[00:27:35] Mihaela: So who do we credit? It's truly a long-term process. And for us, I think it is generally a matter of regularly measuring things. So regularly looking at the team engagement, looking at the number of conflicts even, if that's reduced, and if things are working fine over time, if we get to release the products we expect to release on the time we expect to release. And if we then look at the products and we see, okay, they bring the value we expected, or sometimes they don't, but okay, how can we pivot and how can we come up with a better solution without spending too much time in agreeing on things and aligning on things. So it's qualitative feedback from people regarding collaboration, regarding trust, but it's also data and numbers, looking at the products we have and also the speed we work with.

[00:28:31] Chris: All right. Well, Mihaela was very nice to offer you all an easy in to talk to her later, so come to her with your challenges, she'll look forward to it. Let's give her another round of applause.

[00:28:42] Mihaela: Thank you. Bye.