Promoting Cross-Functional Collaboration to Drive Your Organization Forward

Read the Full Transcript

The following transcript has been altered for readability.

Josh Berman: Hi everyone. Welcome to today’s Product Ops HQ Meetup. Thank you for joining us. My name is Josh Berman, and I’m the Head of Product Marketing at Dragonboat.

Today, we’re going to be focusing on the topic of promoting cross-functional collaboration to drive your organization forward. And this was a crowd favorite from a poll that our guest speaker, Maria, sent out on social media. So for context, if you haven’t met Maria before, she’s been involved in our events in the past. She’s a contributor to this community. She’s also a product operations evangelist with over 20 years of experience, leading teams in product management and operations. Maria excels in driving alignment and efficiencies across teams. We’re just looking forward to all the insights that you’re going to share with us today. So, Maria, please take the stage. Let’s kick things off.

Maria Van Wambeke: Hi! Everybody! Really good to see some familiar faces and names here. So again, based on the poll that I had put out about: “What keeps you up at night, what are the top concerns for product ops practitioners?”, we pulled together 3 highlighted areas of cross-functional collaboration that we’ll dive into.

But most of you know me. I like to set the stage before we go into the granular details. So getting like a perspective on what cross-functional collaboration actually is in an organization. Like, if you look at a very flat, level, not multi-dimensional definition, it is really about bringing different groups of individuals together, based on general demographics or different functions, right? And the idea is the power of this team, and the intellect of this team results in better decision-making.

But really, I look at cross-functional collaboration as a bottom line, even driven effort that helps teams to innovate. So what I look at is, if you, as a modern business, are going to adapt to consistently changing environments. You need to draw on a very diverse group of people, thoughts, perspectives, right questions, right people bringing up different risks, different mitigation strategies. Everything is the power of many versus the power of one. So a quote, probably somebody else’s quote, but I put it in quotes with “the sum is greater than the parts”, right? And we all know this through our engagement in this community. That was one of the huge things that you know, foreshadowed would come up on this slide so that sense of community.

So I like to pull together all these various parts, because when we conceptualize what cross-functional looks like, it differs by your organization, it differs by your matrix strategy. How are you forming teams within an organization? So this was just kind of a mind map or a data dump of all of the cross-functional teams that I could think about,right? And so this is just a way to instigate your mind going.

Wow! I’m only looking cross-functionally at 7 functions, right? Which are the most common. However, I oh, wow! I forgot about the you know, strategic communications team or the compliance team or legal team. I’ve seen that happen a lot in organizations where products are about to go to market, and then the legal or compliance pieces end up blocking something going out. So again, this is just that mind map or data dump. So that you’re always referencing and saying, Oh, yeah, this checks and balances. This team should be involved.

So why is cross-functional collaboration so important? And then how does it lend itself to our success as product ops practitioners, but also, more importantly, or equally as important, the bottom line, right? And that innovation and growth of an organization.

So key things, and this is all based on industry. The best practice is it enhances productivity. We’re able to streamline processes across multiple functions which speeds up time to solution and time to decision. You can get to a solution or a decision by meeting individually across functions and aggregating viewpoints and ideas and decisions. But imagine getting everybody in a room? A 1 h meeting is going to cost the same amount as 12 individual meetings over time.

So another thing is time to market, right? So everything is expedited. But you’re also breaking down silos that would interfere with that flow of process and the streamlining. The biggest thing is it powers innovation. You’re pulling in diverse views, and different domain expertise. Imagine how many people are on your teams that are coming from different industries and backgrounds. You reduce bias. You’re thinking about things from a different perspective of everything, everything demographic, cultural, different ways of communicating.

One thing that I like to share is we were working on packaging and pricing for a product at one point. And if you’re not testing messaging right, you generally through a product marketing team, you don’t really understand the full scope of how individuals might perceive language differently. So that’s a perfect example of reducing bias, right? And gaining multiple perspectives by having all these individuals involved.

And, as I said previously risks. We can identify risks ourselves, based on kind of what matters most in our function. But when you pull in others they’re gonna poke holes right in the things that you’re doing, the solutions that you’ve identified. And I think that’s a real key to, not disrail projects.

And then, finally, it engages employees, everyone feels involved. Stakeholders are satisfied, people feel heard, they feel validated. This is just the human part of business, and it really helps to maximize that and, in the end, you see higher retention, morale, this constructive learning environment again, all words that we’ve talked about today. And like the Product Ops community which is ultimately, cross-functional in itself. So a good illustration of the power there.

And then, fostering a culture of collaboration, right? What? How do we do this? And why is it so impactful? We’re powering innovation by again bringing more expertise and all these different perspectives together. And I think when people think cross functionally, they’re thinking functionally. I don’t particularly like the name, I don’t think it’s correct because it’s limiting on function. But really what collaboration is, is bringing backgrounds, demographics, ideology, different communication styles different learning styles all together under one roof, so to speak, to expedite that decision-making and power innovation.

So I put this out there to broaden how we think cross-functional collaboration, what it represents because it isn’t just about function. So then, secondarily, it brings teams together with this amazing sense of shared purpose. One of the main things about product success and project success is building that buy-in transparency and trust and alignment amongst a team. So again, you’re streamlining through decisions, you’re working together, you’re all working on the same path to the same outcomes.

And then, of course, it breaks down those information silos. How many times have you found out about something through a sidebar or on accident, and so, if we can all join together with shared purpose, right with a broad range of perspectives, we can then break down any communication silos that might cause, you know, disagreement further down the road. The whole idea is how do we reduce the railing of project or product and rollouts and process, and cross-functional collaboration is really instrumental in doing that.

This is going to be in the deck. This is a lot of information. I want to make sure we have time to do our cross-functional or excuse me our collaborative discussions. So this is just, through my experience, some of the things that have worked really well with managing diverse viewpoints. One of the main things that derails cross-functional collaboration is all of these viewpoints, all the people getting together and humans are humans. We will have disagreements and disagreements are healthy. It is just how we constructively resolve them. So again, that alignment is really important.

The other thing is an immense amount of flexibility. As a facilitator I see the product ops role as being the facilitator of aggregating all of these viewpoints and getting people to work in harmony, to make decisions.

The other thing that I just want to point out before we progress that has been really valuable is when you’re extremely focused on solutions and the conversation is derailed. The best thing to do is to go back really to the basics of the “Why?”. “Why are you there? Why are you all together in a room?” And if you can go back to aligning on that shared purpose and then get into the weeds, that generally is a way to put the conversation back on track. So it’s probably quite obvious, but it has always worked for me in professional and personal life, right? Aligning on what matters most to the org.

So I just wanted to throw out a little tactical one really great tool that is completely old school is the RASCI to identify roles and responsibilities cross-functionally. It can be by function, by team, whatever the structure of the formation of the the project that you’re working on. I like this expanded RASCI that includes support. And the reason is that there’s often times, and I’m sure every one of you can imagine a time when the support team or the individuals responsible for supporting something after it was rolled out, were not really informed of the nuts and bolts, or weren’t really involved in the creation of a process or a project. So the expanded rasci includes not only the responsible, accountable consultant and informed, but it also includes the supported role, which I think is really valuable.

Most of you that know me, know I love templates, and I love sharing templates, and they’re all just part of me sharing with the community. So if you want a RASCI expanded template, just ping us, we’ll put it in the notes, I think after. But I have a Google sheet that you can just, or a PDF version, you could just make a copy and use it.

So then, finally, why we’re here today. And the 3 areas that we’re gonna talk about with cross-functional collaboration. I want to come up with a new word or a new phrase for this right now. But I’m just gonna call it maximizing communication is aligning strategically across functions, teams, people. It is imperative for that. It’s imperative for prioritizing work and work streams, right? If you can rely on the why and the what of like, Why are you working on certain things as an organization? Then you’re going to work more productively across functions when it comes to implementing.

And then, finally, I’ve said this before, harmonizing is a word that you know, I just started using when I worked on this presentation. But I was like, Wow, that really is for all the teams that deliver. If you can work in harmony with the design, the engineering, the product teams and that kind of heartbeat or rhythm is harmonious. That’s when things are effective and things are rolling out features and products. So these are the 3 areas that we’re gonna talk about today. Given the amount of time, we’ll probably spend about 10 min per section. And Josh is gonna facilitate so that we can answer questions and have an interesting conversation.

So what I did here is, we have the deep dive area number one. And again, this is the 1st time we’re doing this format. And I added some questions that might help us to do a bit more of a deep dive or engagement on the subject. So these are just ideas that might get your brain going. You know your mind going. But if you want to choose something very separate from this, please go ahead. So the way this will work is, we’ll go off of mute. You can either answer directly, we’ll start the conversation, or we’ll even do it in chat.

1 – Strategic alignment across functions to connect the dots between strategy and execution

Maria Van Wambeke: The first area that we’re going to dive into is strategic alignment across functions, across people, across disciplines like, how are you aligning? So you’re connecting the dots between strategy and execution, which is, I feel, like one of the core tenants of what product ops is and what it does within organization. So let’s kick it off with the deep dive one.

Josh Berman: And folks before other people chime in there, if you have any questions about the format, or anything, feel free to hop off mute and and ask those, as well. If there’s any questions there.
Can we get any takers for maybe addressing one of the questions in this deep dive number one.

Chris Compston: I don’t mind jumping in. Hey, Maria! Lovely to see you presenting and thank you. Firstly, everyone, I think I joined one of the first ever Product Ops HQ meetups, and I think it was like 4 or 5 people there. So the fact that it’s grown to this level is incredible, so well done for that. It’s really cool.

I think one of the biggest challenges I’ve seen, and I’m gonna take like a really long term view on this, like, I know, Maria, you said you’ve been like 20 years in building products, and I’m probably around 15 years, I would say, and in that timeframe I think we’re way past the stage now, where most organizations have been through their digital and tech transformations. Most companies are now building software or heavily using 3rd party SaaS tools. We’re also like way past agile software development, right? Like most organizations are doing it. Let’s say some are doing it “good”, and some let’s just call, “not-so-good”. And I think one of the biggest challenges with today’s agile software development, which was not the intention, is that it creates these role silos, it creates functional silos which cause collaboration to be a real challenge.

And we’re now in this place where we have an introduction of OKRs, like everyone’s been through the OKR transformation now, right? Like everyone’s using OKRs, some good, some not so good, which silos roles even further. So I think when you look at an agile software development team in the maybe “not-so-good” category, it’s really really hard to collaborate. Like designers have a 2-week window to understand customers and design products. Developers have a 2-week window to deliver something of value, which is very hard to do, and because of that you end up putting very strict handover points in this “not-so-good” agile development teams, right? And I think that’s one of the biggest challenges that I see.

I think, as we move into a world where we’re focused less on project model output driven closely managed by some team leader work, that we’re doing to a product model where we’re thinking about outcomes and more collaborative work, that’s going to help. But we need to shift that mindset to get there. It feels like we’ve come from, I was a designer 15 years ago, and I used to collaborate all the time. I used to work with people all the time, customers, clients users, engineering teams, front and back end full stack engineering, product, project people all the time talking. And then agile came along, which was gonna make his way more efficient and effective. All of a sudden those roles change significantly, and those boundaries came. I think that’s the biggest challenge I’ve seen over that time period.

Jackie Orlando: I would, yes, end that actually, to your point of OKRs being a very big framework. That’s kind of taken over. Yeah, I see that a lot. I see a lot of “analysis paralysis” and overthinking on how to structure OKRs effectively to actually give the teams enough direction, but not too much specification. That is something that I see wheels spin on a lot.

Kate Mortenson: Actually would like to participate in this conversation a little bit. First, I agree also thank you for having a platform for us to be able to come together to do this.

I’m relatively new in my product career prior to this as a sales engineer. So you know, coming in and just learning some of this stuff. Currently, I sit as a product analyst in my organization. And one of the things that we’re trying to tackle is how to report back the success on those OKRs, because now everybody understands what they are, but what I’m noticing is that people are having a hard time seeing how their individual contributions cross-functionally, roll up into that wider OKR.

So what we’re trying to do, or what I’m trying to do is we have some core success metrics that we track for various releases that roll up into the OKR and releasing it out into the business 30 days out, 60, 90, etc, etc. over and on.

But what I’m encountering here, and I’d like to open this up to see if anybody has advice for me. But I agree that those challenges persist, and one of the things that I’m struggling with the most is having, like faith in my organization, that the work that’s being done cross-functionally rolls up into those OKRs like, I still feel like we have people who self silo because they can’t find the work that they’re doing in the metrics that I share, if that makes sense. So I don’t know if anybody has experience with that, and how to talk through it, really.

Josh Berman: Yeah, Kate, I think that’s a great add. I think that’s something that I would identify with as well. Like if you’re doggedly focused on one narrow metric to drive the work that you’re doing and others aren’t aligned to that as well in some way, shape or form, you can easily take things off the tracks, or you can find where there’s these friction points between different teams. So I can definitely understand that.

Does that ring true to anybody else’s perspective, or anything else that you would like to add on that topic, or the topic in general of how siloed work is becoming a big challenge, or is remaining a big challenge for these types of teams?

Haley Campbell: If I could hop in, I’ll have to actually jump off to get to a cross-functional meeting in a second here, but hopefully they’ll be recording. I am brand new to products like not even a year. So I’m very, very grateful to have this resource. Wanted to plus one everything that you all have said.

And I think if I could sum up, it feels like with OKRs, and in fact, many reporting structures, the balance is, are we adding value or are we adding complexity? Because there is absolute value and necessity, and reporting what we’re doing, and why. But in my organization, where OKRs are relatively newly implemented, it feels like we have a lot of complexity and a lot of overhead. In part, because we’re quite new to them without bringing a ton of value. And I wonder if some of that could be potentially mitigated by planning out our rollouts a little more thoughtfully and considering what structure are we implementing here. Who is reporting out, and what do we need to get out of this reporting itself versus just OKRs. We got to do okay OKRs, right?

Maria Van Wambeke: What comes to mind to me is the like an E old school erp system, right? Remember the hierarchy of data right where you have it at the extremely granular level, at the individual OKR, right? And then the team level. And then, ultimately the company objectives. So I’ve seen this work really well, with aligning with the business transformation office in a larger org or whomever is orchestrating, sending out the main objectives and doing a drill up.

So you’re not reporting individually at the team level unless that’s data that people want to see. But it’s about, how is everyone individually from a team base fueling, right? The objectives themselves. So it’s not isolating by team. But it’s aggregating by org about the impact, right? Each individual team has on the objectives themselves. And I’ve seen that work. But again, you have to have that trust across organizations that everyone’s doing their part to feed into that bigger part.

Josh Berman: Do any of these other topics striked a chord with anybody, or you’d like to take a shot at giving a response? Or does this bring forth any other ideas that you’d like to share with the group? I see there’s some chats online and apologies for missing some of those. Let me see if I can catch up on those.

Derya Tavozar: Hi, hi! This is Derya! I’ve been in product operations for a while now. And one of the things that comes to my mind on this cross-functional alignment topic is priorities. I work across 10 different products, supporting all of them in product operation function, and not including the business side of the organization.

It becomes difficult when we have a strategic goal, but the roadmaps and the priorities of each group has already been set for that quarter or the next quarter, and it becomes really difficult to get everyone aligned on the delivery date, getting them to work through that deadline and making sure that you know it’s not being disruptive to their other works which are client specific, right delivering product, specific features versus a lot of the strategic alignments that we want to do. They may not be client-specific, but they could be internal, operational goals that we want to set for us, and that could really compete against some of the features that each product team is trying to get out.

So it seems like more of a dance between, you know, dancing through the priorities, dancing through negotiations and like, Oh, can you do this? But then we’ll take this off, and it just becomes, I think, it becomes pretty difficult to figure out how to hit those goals and to report on those goals in a timely matter when each of these groups could have a different goal set in mind.

Josh Berman: Yeah, it’s clear that there’s a common set of challenges across the group here, all kind of connected in different ways. And you know, it’s encouraging to hear that we’re all trying to solution towards addressing these problems and tackling in different ways. And I appreciate everybody’s perspective. I think we got a lot out of this deep dive, and if there’s anything else that comes up, feel free to bring that into the conversation, but in the interest of time I do want to move it forward and and see if we can start looking at from the perspective of our deep dive 2, which I’ll put on the screen now. Maria, do you wanna tee up this one? Or would you like me to? Just share a little bit about what it’s about, so that people have some framing.

2 – Prioritization of work streams and agreement on why, what, and when

Maria Van Wambeke: Yeah, I think it’s actually a extremely good transition, because it is merging in from the last conversation. So how do we align our priorities? I use the word workstreams. It could be anything across teams, right? To your point, Derya, that we are agreeing to “the why”, “the what” and “the when”, there will always be times where teams have independent work that is not aligning to company objectives, right? In my practice generally with software development, you will have 80% of work tied to strategic outcomes and 20% held for customer escalation plus tech debt, as an example. So it’s not going to be a hundred percent of the workstream for a team. But the majority would align to those company objectives.

Or if that’s the structure you use. What have you done right? What methodologies, frameworks, approaches have you tried that have worked or not worked in aligning teams and their priorities, so that you can work as marching to the same goal. But independently in your teams to not disrupt those processes too much.

Ada Johnson: I can go. I took over my team about a year ago, and I think one of the common threads was like, we’re overworked. We have a lot on our plates. We need help. Prioritizing product is giving us all these things. We’re struggling with ops needs, product needs, and I was trying to understand if it was like a feeling, or if it was actuality, and I think like just having the exercise of having them write out all the things that they were working on into like sort of a centralized place for us to start to see that, and then starting to label them under specific priorities, that exercise in itself like kind of demystified, like the work that was sort of in people’s heads versus what the actuality was.

And so I think when we started doing that and having a process around how we tracked work and how we reported our work out. A lot of those things started to go away, because again, they were dealing with their own kind of work in their own heads. I think we didn’t have a formalized way of being able to centralize that for the entire team to be able to see. In those scenarios in which certain team members were overworked, I think I was able to have a conversation around like: “Okay, what are all the things that are on your plate? And how do we sort of deprioritize some of these things to make it more of a manageable size?”.

But I think, for the most part a lot of those discussions, or all of those conversations went away when we started doing that, and it was pretty simple.

Melissa: Plus one to that! Making all of the work visible is step one, whether you use Jira, Airtable, where is all of the work, because once you aggregate that, and you’re able to say: “these are your top 2. It’s just these. Everything else can fall to the wayside. So let’s push these to completion and get them out.” It takes down that stress level. It enables people to actually focus. And then you’re able as products, like, I report back, here’s what we’re working on.

Then I don’t have a 50-page list of “here’s everything we’re trying to accomplish”. It’s like “team one is on this, team 2 is on this, team 3 is on this, the end. You’ll hear from me next sprint”. So it actually really does tighten up all of those lines of communication. And then it’s very clear to marketing. You’re not getting this delivered right now. But when we say you’re getting this delivered, it will actually come, because it’s our one focus.

Ada Johnson: Great!

Josh Berman: I’ll further that, and that you’re driving towards the right outcomes, too. You’re making sure that folks are focused on the right things that are going to drive the business forward, and all the other points that Melissa and you added to that topic. So that was fantastic. Any other thoughts or any other responses to the questions that you see on the screen here?

Julia Smiley: I can jump in. Hey everyone! So the second question, “how have you addressed resistance?” So I found that as a product person working on my own on a big initiative that touches many parts of the org, I kind of experienced, slower progress, and like a struggle to get buy in. But what I found was that if you find the teams and people from other areas of your organization that may be working towards similar goals and kind of team up with them to drive the same outcome, it allows you to move much faster because you have diverse perspectives, and you also have the folks that are going to help you get buy in from across the org, and it’s no longer up to you. So that would be my advice for encountering resistance.

Josh Berman: That’s great. Thank you for adding that. I’m curious about this last question. We’re all faced with this challenge continuously. But has anyone just fallen completely out of alignment, and nothing seems to be going right. What have you done to dig yourself out of that and get the teams back on track? Any good stories here?

Chris Compston: I think like, to some degree, if a team is falling out of alignment, and it’s happening continuously or let’s just say, often, is it okay? Like we do want? We do want. I know, we’re all operational people, right? So very operational mindsets. And we like standardization and scalability. But there’s definitely times where we need our teams to be creative, flexible, adaptable to needs, etc. And maybe sometimes it’s okay that certain teams are flexing a little bit depending on what they’re finding out. And maybe that alignment isn’t quite right for that type of team. If it’s been seen like more regularly.

Raghad-Maqsam: Hi everyone! I actually have a story to share. First of all, I’m joining you all the way from Jordan, so lovely to be here. In my region of the world, there isn’t many product ops people, so I’m very happy to be meeting with all of you.

A story from my line of work, where we have completely fallen out of alignment, was between product and tech, which I’m assuming is a very common thing to happen. A while back we were working on migrating our UI into a new framework. Basically, we’re a cloud communication solution provider. And we had some plans to migrate into a new framework but for some reason we hit a wall. And because of that we couldn’t really progress at all.

So we have almost like 20 different pages or 20 different URLs that we had to migrate, and it took us almost a year to just migrate one page. I’m not joking like one entire year to do that. It was a huge, huge misalignment, and mainly because we realized a while back that maybe we need a mediator to mediate the conversation between design and tech.

We’re relatively a new startup. We were learning everything as we were moving. And we couldn’t really, until we realized that the main issue is that like designers are addressing one point, tech are addressing or the development team addressing the exact same point. But each one of those people are just speaking in their own terms which led to a huge misalignment and things sort of spun out of control like development team would not want to proceed with what designers wanted to bring through, because they just felt that design were being too concerned with be being pixel perfect, while the designers were like tech, they simply do not want to put the work and effort which is obviously very, very problematic, because at the same time we were not being we were not able to ship any new features.

How we got back on track, it’s similar to what Julia just said. You need to sit down with people who have the same objectives or the same goals. Obviously it took a lot of involvement from a lot of different parties, and the sort of alignment was extremely expensive, and from time point of view from joining like meetings and planning how we wanted to move ahead with things.

And eventually we set down a very detailed process from the moment design picks up work to the point that tech or development handsets, hands product back work. And we actually build it. It’s extremely detailed. I’m not joking like you need to scroll, maybe like 20 times to end up the whole process. Usually you wouldn’t want to be this detailed, but I think for the sort of problem that we ran into. We had to just think of every possible scenario and make sure that all of us are aligned. And we’re all thinking about the good of the product.

We just want to migrate to the new framework and get going as a result, after, like the past 2 months, we’ve been implementing this past process, we managed to migrate 5 pages while it took us an entire year to migrate a single one. So I guess that’s a measurable success for us. I think my advice would be to just find someone exactly like what Julia said. Find someone who sees the same objectives as you are, and get everyone points of view and have a discussion like grownups. Actually just be all on the same page and address the the problems and all with the intention that no one’s having like have a no blame policy. No one’s there because they’re with bad intentions. Everyone’s there, they’re speaking different point of views, and it’s your job to mediate these point of views into actionable items.

Josh Berman: Oh, that’s great. Thank you so much for joining us from Jordan, it’s just a testament to the fact that we have this global community, there’s folks from all over the world present on today’s call and and our past events.

But the information that you’re sharing here. We had 2 perspectives, right? Chris’s perspective, where it’s like, you could have some sort of tolerance to the challenges that you’re facing. Maybe it’s acceptable for one team or two teams you’re gonna work through that. On the other hand, like you’re sharing. Maybe this is something that you gotta face head on, because this is a stopper for business. So I think we picked up a lot of great tips with both perspectives and the other feedback that we’re hearing from everybody else. So in the interest of time, let’s move on to deep dive 3. And, Maria, do you wanna kick this one off as well?

3 – Harmonizing processes for teams that build and release for customer impact

Maria Van Wambeke: Yeah, so this is very specific to our teams that are producing value for customers. Or I call, you know, the producers. This would be the design, engineering and product teams. So what processes? And again, the example that we just had was a really very good one. Again this natural transition into deep dive 3, harmonizing processes, or things that I’ve worked right to help these teams be more productive and constructive in building and releasing for customer impact.

I can start since it’s quiet. So in my my previous role we were actually handling a PDLC or SDLC in more of these isolated ways. So design through a pass off, right? Product would do their part, PRD, pass it to design, design would do its part, and then pass it to engineering. And with this, there was all the feedback back and forth. That would have to go back to the drawing board, right?

So we lost a lot of time, and everything, to Chris’ point, felt like it was a rush. We were systematically rushing through because of the constraints that we put on ourselves with these pass-offs. So we overhauled this, and everything was done with this trifecta, I called it. It was product, engineering, and design that worked as one. So there may have been more meetings and more cross-function and more collaboration over time. But with these 3 groups working together through each of the stages of the process, we were able to streamline right and create harmony. With these 3 teams working as one it also provided a wonderful way for us to work through, like pushback, right on solutioning product may solution and design may have a different view, and engineering will have a different view if you’re all under kind of one roof, so to speak.

Then you can hash these things out with immediacy instead of again these silos that then you need to punt information back and forth. So that’s one example of what has worked for me in the past.

Raghad-Maqsam: I’d like to share, maybe. Regarding the second point, when rolling out a new process, if everyone needs to agree, I think this is something that we’ve been doing across our company, where we do have a set of principles that normally guide us but one of them is called “disagree and commit”, meaning that if we actually had a discussion, and we realized that this is the new process that we wanted to follow, even if we disagreed or I thought that something was maybe it doesn’t work, I need to just disagree and commit to this new process, but we will circle back and just improve it later on.

I think this has helped us all agree that these processes are not set in stone. So even if we have this long process of handover being implemented now, we might discover something not functioning well, and we’re just circling back and fix it. The most important thing is to just get going and not really block on anything or not bother. Spend too much time perfecting the process because there isn’t such a thing as a perfect process. You just need to find something that works for you and deliver the outcome that you are committed to delivering. So just having this in the back of your mind, meaning that I will disagree but I will commit, and we can circle back later will really help to bring the viewpoints together.

Josh Berman: I love that. I think too often we get caught up in the details, and sometimes just saying, you know, we’re reaching towards the same goals here. We’re trying to accomplish the same thing. We might have a difference in opinion about how that gets done. But we know we all have our best interests in mind. We’re gonna press on and see what we can make of this, and we can always adapt and change that as we go along. Any other thoughts?

Melissa: The two people who spoke made me think of iteration but from different points of view. So in first iteration, in bringing a hundred percent agree on bringing the design, engineering and product together. It just allows you to move so much more quickly. And I think that’s partly because of the iteration that’s happening and the short feedback loops between is this going to be usable, feasible, it’s going to provide value. So there’s that aspect of iteration.

And then in the process aspect, it’s trying things. Sometimes you have to make broad strokes in making a big process change, and sometimes it can be little things. But I found that when you bring people into the discussion and kind of co-create with them as much as possible. And then also approach things like, okay, this is an experiment we’re going. This is our, we think that this is going to help. For these reasons, we’re going to try it out, and then it’s not going to be set in stone forever. We’re going to iterate and adjust seems to be most effective in getting people to even be willing to try something.

Josh Berman: I think we’re running short on time now. But are there any last minute adds or anything else that folks wanted to address with this deep dive 3?

Martina McKee: One super quick thing I was gonna add is, I agree with a lot of these like, set out the goals, get design, engineering, product into the same room. And we’re going through a large change at the minute around our release process. So we need to get a lot of buy-in across the organization.

And one thing that worked for me recently was I had already kind of firmed up where I thought we needed to go with it, having spoken to a lot of different kind of stakeholders and a lot of different functions but I ran a session, for the group leads specifically of the different of design, engineering, and product, and to kind of walk through where we were thinking of going, and with the release process, and we did it in Miro, which was quite useful.

And then what we did was, you know, I talked through the stuff, and then we had people have ad stickies to the different areas and think about highlight, what they liked and what we had presented, where they had questions and suggestions and what they had concerns about. It was a very quick way of getting a lot of feedback from people. So we talked about it.

We asked them then to deep dive and add their feedback, and then we talked we picked about, and some of those items. So it’s quite good in a very short period of time to get a lot of feedback in from a lot of people. And before we ended the session, we also had a barometer of where they felt, how they felt that the process could work, one being or 0 being, they completely disagreed with the direction or 5 being they really felt this was exactly what was needed, and then points in between. So we weren’t aiming. We’re not aiming for consensus necessarily, but just even getting that feel for okay, what’s the broad sentiment here was was super useful and has allowed us to kind of tweak things where necessary.

Josh Berman: Yeah, that a great add. I mean, we touched on a couple of different tools that people use in their day-to-day to manage the flow of work and and make sure that there’s transparency given. But we hadn’t talked yet about how do you guide certain processes or workflows around guiding decision-making or aligning teams.

So that’s really fantastic. I think there’s a lot out there for people to use. So if you need pro tips, the slack community that we have going for Product Ops HQ is a great place to start where you can get feedback from other people on what they’ve used before, or get advice on good tactics, such as what Martina mentioned, of how you can guide people through that process and also get a health check on how they’re feeling about it after you’ve decided on a path. Maria, I’ll kick things back to you. To see if we can talk through some of the takeaways that you heard from this lively discussion, and just in general.

Insights and Takeaways from the Community

Maria Van Wambeke: Yeah, we have a lot. We’ve had an iterative process here. I’ve been updating the slide. So we have a ton of stuff. Again, I like people to have the slide deck. This is not a format in the most beautiful way, but we’ll work on it. I aggregated a lot of the things that we talked about today.

So in creating the right culture of communication and transparency, how do you share progress across your teams or across functions? We discussed OKRs and really how to structure them. I don’t think there was any divisive outcome to that but that OKRs seem to be something that most of us are using, but they can be improved again. So we can share our priorities and share our impact at multiple levels. One of the things that came to consensus was probably customizing the output of metrics for the audience, so people are seeing the impact of our teams.

And how are we aligning strategy and execution. Transparency, and trust and delivery again after someone brought up a really good suggestion on going just through an inventory of all the things we’re working on. Some of us don’t even realize what we’re let alone what we’re working on. But what other teams are working on? And how do we share that? So we can focus on the right outcomes, and also report back this full communication loop. That’s Melissa, I believe you had suggested that, right? If we’re completely transparent about what we’re working on, but also showing really how we’re showing up for the org and producing the results that we promise there’s a lot of trust that’s then built.

And then how do we address resistance, teaming up with other individuals in the org. This is really the fundamental thing on aligning on values and shared outcomes, facilitating alignment across teams. There is always going to be power and facilitation. It’s old school communication technique. But it’s really getting down to the core of what brings teams together and then moving forward from there and then dealing with maybe disagreement and decision-making and how to move things forward. I loved this “disagree and commit”, not to block the progress of teams or organizations, but to say, Okay, I’m comfortable with committing to this, knowing that we will possibly look at it or improve it over time, or often we have to be okay as humans being uncomfortable with certain decisions that are being made, knowing that maybe we’re the outliers that are blocking things, right?

And then it was nice to hear the structuring of design, product and engineering working as one team to expedite iteration and also shorten that feedback loop. And to Chris’ point, where we’re not getting enough of that feedback in these more siloed, agile teams. This is really a way to break through that. And then also gathering feedback, iterating, listening actively. This is no different than any other process that we’ve rolled out.

If there’s anything I missed which I’m sure I missed a bit, why don’t we shout that out so I can put it on the slide? So we all get it in the recording and also in the takeaways.

Josh Berman: One other thing that we could do is take the conversation to our slack channel or other community presence on our different social media platforms. And that could be a great way to continue the conversation. So I encourage you to all join us there, like I mentioned before. Also, if you loved what Maria has shared with us today, which I’m sure many of you can identify with, please, connect with her on Linkedin as well.

Maria, thank you so much for putting together such an awesome and interactive session for us today, a great way to celebrate 2 years in the running, and thank you all for your support and participation in today’s session as well. We look forward to seeing you at one of our next meetups, and would love your feedback, so please do share it with us. Stay tuned for that recording! Hope you all have a wonderful rest of your day. Bye!