B (4:23)

To be clear, there are pros and cons of both. The biggest pro that I see in working remotely is getting access to talent. In some organizations, that's their biggest challenge, just based on where they are geographically located or not, right? So being in tech hubs, talent is very competitive. And so getting access to talent at a reasonable price is a challenge for some organizations. So they choose remote. In fact, I worked at a startup before I joined SVPG where we were a hundred percent remote. And that was the. This is pre Covid. That was the approach that we took because we didn't matter where people were from a talent perspective. Having said that, I believe having worked in both environments personally as a leader, having, having everyone together, it's just faster you get better alignment, you get better culture, you move a lot faster, you make decisions. My rule of thumb is you should never be in a situation where you have to schedule a meeting to make A decision. The problem with some organizations is they can't schedule a meeting for another two weeks because it's so difficult to get everyone together with the time zones and where people are and the schedules and how packed they are, which we'll get to. I'm sure this notion of being in back to back meetings all day long, that's a challenge. If it takes me two weeks to schedule a meeting to make a decision, I'm already behind and that's not a competitive environment. But if I can be sitting near the people or at least mimicking that colocation and I can make decisions in real time, I guarantee you I'm going to be more competitive.

A (5:54)

You know, I've always told people things are not impossible remotely, they are just harder. And some aspects are easier. You know, if you want to get everybody in a room, there are tools now that make it easier. But you're pulling out some aspects that I want to make sure are not lost in things that get harder. Emphasize decision making is harder, problem solving is harder. And I think the big idea of what we call true collaboration, which is solving a problem together is harder. And I know there are tools that people are using to do this. So let's jump in because here's the reality. Some teams are hybrid. Some teams, even when they are co located, there are circumstances where you have to work remotely with somebody else or in different silos. Maybe I want to start with the rules of proximity. If you are a leader and you had to make a choice who should be together, how you want to kind of organize co located teams or not, what are some of the rules that guide you in that decision making and how do you prioritize proximity?

B (6:54)

Yeah, I mean I optimize for where the biggest gap is. So let's say that I have a product team that has a really hard time doing discovery in one of the key markets. I'm going to optimize to make sure that that team can get out to visit customers and spend more time with customers to understand their problems better. So I might optimize for discovery from a value perspective with customers. If I have a team that's struggling with aligning with the rest of the business or there's a complex go to market, I optimized to have proximity closer to the go to market team. So like making sure you understand contextually the biggest challenges, if you can bring the team closer to that challenge, you'll usually get a much better result. Now obviously that assumes a fair amount of flexibility. However, most of the time when you're defining your team topology, you can identify where those gaps are and optimize to remedy that particular problem.

A (7:53)

I like that. You know, I've always identify like you're optimizing for your biggest gaps. I've always thought for me one of the biggest gaps in many companies is even discovery solving the problem. And so, you know, I've always said I've always had a preference for the people solving a problem, product designer and engineer being together. There are many cases where it's sometimes okay to leave the delivery aspect of the other engineers alone and have them have space and put their heads down to do things. Then you kind of talked about proximity to your customers. I see that all the time. You know, it's like, oh yeah, we are building for a team out in Asia and you're building a product they don't use in Asia, they are none of your customers and you're building a product for Europe or North America and there's this disconnect between the people solving the problem and the people they are solving a problem for. So I always say, you look, I'm going to optimize. If I had my pick, of course I want the whole team together. But if I had to pick, I want the problem solving, discovery driven aspect of product design and at least a lead engineer together or some engineer that they can actually make those decisions faster. Then you know, I want them having maybe proximity to their customers, proximity to the business like you talked about to ensure proximity to the manager, optimize for what is convenient for them, that what is convenient to your point for the biggest gap or the best decision in getting an outcome. So I, I like that those principles around proximity roles on that I had.

B (9:21)

One team that, and this is I think a use case that we see a lot in organizations. Engineers were actually based out of Bangalore, India. Product management was based out of San Francisco. Design was based out of San Francisco. We made a conscious decision to move product management and design to Bangalore. So we opened headcount in Bangalore to make sure that we had proximity. In that geography we still had a gap where our biggest market was in the US So what we did is we took that core triad, right, the tech lead, the product manager and the lead designer and we ensured that we budgeted appropriately to make sure that they could come back at least once a quarter, not enough, but at least once a quarter to establish those customer discovery programs with key customers so that they could build those relationships with customers over time. If you are not co located, this is what you were talking about it's not impossible, it's just a lot harder and you have to plan for it. It's not just going to magically. You don't get any of it for free.

A (10:22)

Yes.

B (10:22)

And so you need to budget and plan for it appropriately.

A (10:26)

You're calling out. One of the traps I see with remote collaboration is this assumption of trust and psychological safety and that we know each other. I always joking, I the number of times I bring groups together and it's the first time we're seeing something in the person and it's like, Leah, you have legs. You know, Leah, you know, like I've seen your hands for the first time. You know, we had this idea of people in this box and we never see their non verbal communication, their cue. There's this heightened aspect of insecurity that we cannot overcome because we don't know the intent or people turn off their cameras in some ways. You know, one of the studies I was reading was showing, you know how you go into a meeting, people do small talk, you know, like, hey Leah, how was your weekend? How is family? That kind of thing. It was saying that what people are trying to do is build enough rapport. We unbills enough trust or psychological safety for the time block of the meeting. Like we've got an hour meeting. We need to act like we know each other or we like each other. And there's this indication that higher performing teams don't actually do that. You know, I'm like, so Leah, how was your weekend? Leah is like, what do you mean? We talk all the time like, you know, you were at my house last weekend, like why are you asking me that question? You know, like, let's get down to business, let's get down to doing work. And so it's almost like we recognize that people try to build the trust for a short period of time to get a tax done. And those are one of the things that are harder to do remotely. You gotta be very deliberate about building trust and relationships in order to strengthen millions. Okay, let's jump in because let us just play out. We are working remotely now. This is the reality of our organization, on our team. I need to understand what I should look out for. What are the best tips for ensuring that we can get good work done?

B (12:18)

Well, a couple things. There's meeting best practices and then there's alignment and collaboration best practices around working remotely. And Christian, you know this already. I always like to talk about the anti patterns first and then talk about the patterns to remedy it. The anti pattern one that I see that is quite pervasive is this notion of collaborating through an artifact. Let's say I want to put together a written narrative, I write my six pager, I send it out to the team, and we have no meeting. You know, this is just standard how we work in the organization. And everyone that I send it to, all of a sudden it's a barrage of comments on that written narrative, right? And Christian's in there and he's making sure that he's getting his comments in all throughout the particular narrative. And everyone else is doing the same thing. And it's more about making sure you get your comments in versus truly collaborating on the end. It almost becomes this asynchronous thing that's going on. I see this all the time in organizations and I call it out as an anti pattern because documentation, you know, with exceptions, it's about capturing a conversation and making sure that everything's been captured versus being the vehicle for alignment. Those are totally different things. And if I'm fostering a culture where the only way that you and I are interacting is through the comments that you're placing on my document, I've already lost the game. Right? And so this notion of being face first in our collaboration, meaning live on the camera, talking to each other, having a conversation, understanding what your challenges are, your objections, that's how we remedy that type of anti pattern. Because the former, right, the collaborating over that artifact is just detrimental and doesn't build any of that rapport, any of that trust, any of that credibility. And it's the opposite of that psychological safety that you're talking about. To the point where I've seen some organizations and product managers petrified of doing a written narrative because they're like, everyone's just going to jump on the written narrative and, you know, bash it and rip it apart, et cetera, how is that productive in the organization? It's almost preventing product from getting done versus supporting the product model. So again, that's one anti pattern. So we don't want to collaborate over artifacts. We want to make sure that we can, as much as possible, have face to face conversation with each other.

A (14:53)

I love that frame, you know, documenting the conversation versus having the conversation.

B (14:58)

That's right.

A (14:58)

They think that, you know, the artifact is having the conversation.

B (15:02)

That's right.

A (15:03)

Trying to document it. And maybe I take a step back because there's always this false definition of what collaboration is for me. And I think it's an anti pattern too, this thinking every meeting is a collaboration or kind of separating the Two. And I, and I often try to say, at least my definition is collaboration or true collaboration is solving a problem together.

B (15:23)

Yeah.

A (15:24)

The traditional sense of a meeting, you get, you know, status updates, information sharing, you know, clarity or, you know, communication. Those are kind of the goals of what people think they do in a meeting. And one of the things I try to coach organizations is moving from meetings to more collaborative walking sessions. And, and I tried to even describe work. I said, let me be very clear about what work is. You know, if you do work, you create work product. If I'm an engineer, maybe my work product is software or code. If I go into a meeting and I come out with code, I was working. You know, like if, if you, you know, if I talk to customers and come out with insights or data, I was working. And I thought people, that is, we want a lot of that in every culture. But you see these traditional meetings that either one way, you know, I'm just getting information or I am providing an update. And I said, okay, so what did we collaborate on? And I said, let's, let's think about the difference. You know, did we actually solve a problem? Did we actually get to decisions? Did we actually get to an outcome or a result? Or would that output in some ways, you know, well, the output is communication. I say, well, there are many companies that say, what's my biggest problem? Communication. How do we solve it? Too many meetings, you know, we have meetings, you know, what's the biggest? And we. Communication still doesn't improve. And so I love that you're calling out the difference between how you have a conversation versus how you try to capture a conversation. I think one of the things people default to is what they call collaboration tools.

B (16:55)

Yes.

A (16:55)

You know, what's your favorite collaboration tool? You know, and the substitute for actually having a conversation, it's a collaboration tool. You know, maybe. Tell me, how do you answer if I ask you what's your favorite collaboration tool? Or how do I use a tool to collaborate?

B (17:11)

Yeah. I mean, again, you're not going to like my answer. My favorite tool is this. You and me talking face to face. That's my favorite collaboration tool, which. I know it sounds ridiculous. It's. It's kind of like this notion of. And maybe it's a generational thing, but I don't even think it is to a certain extent. There is nothing more powerful than picking up the phone and having a conversation. Right. And the fact that we schedule a meeting to have a conversation is really a challenge for a lot of organizations. And it Slows everything down. Like, let me give you a great example. You and I needed to talk about something this morning. So what did you do? You sent me a text. No, you sent me an email, right? And then you called me. And so I looked at my phone. I'm like, oh, Christian called. It must be important. Christian called me. So I call you right back. You asked me the question, I answered the question. We had a quick conversation. Maybe it was 90 seconds. And that was even with me saying, oh, how are you, Christian? You know, that was 90 seconds. We made a decision and we moved on. And so, like, if you think about the collaboration tool, and don't get me wrong, like, I love using tools like Miro, I love using tools like Zoom. All these tools are really, really great, but it does not replace having a quick conversation. And that's really, I think, something that is the lost art. This company that I worked with, that we acquired when I was working at a large software company, the CEO of this company was talking about how much he loved his organization and his team. And he said in the party that we had to close the acquisition. He said, the best part about working with my team is that when I see their names show up on my phone, I'm always going to pick it up. Right. And so, like, that really speaks to, to the power and the rapport and the relationship of collaboration. You want to pick up the phone when your teammates call because those are your true collaborators.

A (19:09)

You saying that just kind of anchors out. There is some sense of rapport and trust and we know each other. We can actually get things done. I'm trying to break the cycle because I see companies struggle. We, like, I have never spoken to someone on the phone before. How do we even collaborate or like, they treat this work dynamic, like having a conversation is what you do with somebody you know and you know, you know, work dynamic. It's safer in an email because it's formal. It's safer. And I think we have to start to differentiate collaboration back to solving a problem together, getting a desired outcome faster. You are absolutely right. There's no better tool than talking about it and brainstorming. You know, let's talk about Zoom, because I do get people give me, you know, zoom fatigue and stuff. So let me tell you how I coach this because my favorite technique in discovery or remote team collaboration, I always call it the always on technique. So if, if you are with a team designer product, when you come to work in the morning, you log in with your computer.

B (20:12)

That's right.

A (20:12)

And you turn on your camera and your whole team turns on their camera and they're there. Zoom fatigue actually happens when you see yourself for so long. Yeah, yeah, that's not very normal. And we don't carry a mirror everywhere we go. So the technique is you actually turn off your self view.

B (20:27)

Oh yeah, that's a great idea.

A (20:29)

You don't see yourself but you see everybody else.

B (20:31)

Yeah.

A (20:32)

You keep on your daily life like you're walking, you're doing your things. If you have a question, you're just like, hey, Leah. You know, if Leah is not busy, she's walking, she's like, hey, what's up? Do you have this kind of stuff? Yeah. Well great. You keep going. If you need to go to the bathroom, you get up and go to the bathroom. That happens in the real world. You know, if you have a meeting, if you're in an office, you get up and go to the meeting. Everybody sees you get up and go to the meeting. Yet there is this black hole of my life is different. I don't know what's going on in your background. I don't know. So I don't feel I have permission to talk to you to ask you a question. And you called out something in the beginning. If you have to schedule a meeting to make a decision, you've lost the intent of true collaboration.

B (21:14)

Yeah, that's right.

A (21:15)

You can see the sequence and how long it takes in decision making. Like I said, it's not impossible, just harder and just longer now. Right. So what I do is when you have this always on, I can always see my team, I'm always available, we talk about stuff. Hey, I'm going to the meeting, I'm going to go pick up my kids, I'm going to go. And the team defends you. They know your availability, they know your schedule. But always on indicates I'm always available to collaborate in working hours. Obviously at the end of the day you leave work, you say goodbye, you know, you do the same thing. And I've found that pattern for me when I'm doing discovery or building products to really do what you talked about, accelerate decision making, problem solving, shared learning increases. Because I don't have to schedule a meeting to tell you what somebody told me from another meeting. You know, I just left, I come back, I'm like, yeah, I was speaking to Bob and he said this, you know, we just keep going. It takes to your point. You, you just, it struck me where you just said it took us 19 seconds.

B (22:14)

Yeah, we made a decision, we moved on. It was like, okay, not a problem, we got it.

A (22:18)

And I think many people devalue what that speed in decision making looks like in a company. On aggregate, that's.

B (22:27)

In aggregate, I think is a great call out, Christian, because it just adds up because that two week delay then becomes a three week delay and it just, everything slows down. And then all the teams that are dependent on that team, guess what, they just got faced with another delay and expectations are lost. I love, I love that you called that out. I worked in a startup where we had that always on mentality. Our office hours are always on. Hours were from 10am Eastern time to what was it, 6pm Eastern time. I was in California at the time and so that would basically mean from seven to three every day it was camera ready on. Which I think is another thing that. And I don't know if it's changed. Well, I think it has changed a little bit post Covid, which is people now actually believe that they're in work when they're on camera or when they're remote versus, you know, not.

A (23:20)

Yeah.

B (23:21)

And also I think that every video conferencing platform has great backgrounds, great ways to blurt. So it's not like you're intruding in people's homes anymore. I think it's critically important to have cameras on. I love that. Always on. And the self view. Never, never thought of that. I usually try to hide myself behind another window just so that I don't have to be tortured with. Because you can always tell when people can see themselves right on camera.

A (23:48)

Also, if you practice turning off your self view over time you will see how comfortable. Non exhausting. We are social animals. We are used to seeing people. We're not like it's exhausting to see somebody, you know, it is exhausting to see yourselves. Are you sitting right? How do you look? What's going on in the background? You know, the boss is there. Should I sit comfortably? You don't do that in the real world. And I always, you know, if when I'm doing a workshop or training to people and I joke about cameras, sometimes I'll just turn off my camera and keep talking. I say, do you see how awkward that sounds? I'm the key speaker right now and you just lost kind of all the nonverbal cues. Is he excited? Is he mad at me? Is he giving me the middle finger under the table? You have lost the intent and the nonverbal communication aspects.

B (24:30)

That same psychology, however, about seeing people's facial expressions, seeing the nonverbal cues that's another reason why collaborating through artifacts is not a great approach. It's also why email's not the best way because you're not going to get the intent. Again, I believe in assuming goodwill, but you're not always going to get that in an email. I mean, I've been misinterpreted in emails many, many times. I've been misinterpreted over Slack many, many times. And doing it in person definitely builds more trust and credibility.

A (25:03)

My kids text me in short form type of things and codes all the time and I have no clue what they are saying. I'm like, do you know I have to go Google what this acronym means before just say it, you know. And in person it's much shorter than even in text, you know. But I want to make sure there is a home for asynchronous conversations. And I love you called out written narratives, documentation and logs, you know, But I, I think where we go with collaboration, when you talk about using synchronous, seeing face to face, having a conversation.

B (25:33)

Yeah.

A (25:33)

Brainstorming, problem solving, debate going like that's what you're trying to do to get an outcome.

B (25:41)

Yeah. I'm so glad that you called up debates because debating is a natural part of product.

A (25:49)

Yes.

B (25:49)

Right. And collaboration doesn't mean consensus.

A (25:52)

That's right.

B (25:53)

Which I think, you know, doing that remotely, you want to set yourself up for success so that you can have an open conversation versus guarded contentious.

A (26:04)

That's right. Now one of the other anti patterns I see, Leah, is people thinking collaboration means like consensus. We kind of call it, you know, these are design by committee or decision by consensus. Maybe kind of help distinguish in the world of building products like what is the role of consensus and how does that differ from collaborating with someone.

B (26:24)

Oh my gosh, the best collaborators I have ever worked with and I can call out two tech leads and when I say tech leads, you know, in various levels of the organization, we rarely saw eye to eye at the beginning and that's okay, right? In fact, in this particular organization it was actually a very much an engineering led organization. Engineers were seen as the innovators in the organization. Product was seen as their responsibility was taking requirements from the engineers or putting the messaging and positioning and packaging up the technology and finding a problem to solve. We switched all that. We transformed those teams. But throughout the course of making that transformation, there was a lot of contention between product management, design and engineering. However, it was incredibly beneficial because engineering would come to the table with their perspective and their point of view. Sometimes it was, we want to leverage the newest technology to make sure that we can innovate for the future and future proof what we're trying to do. From a platform perspective, design would be thinking about the best possible approach. From a design pattern perspective, product would be thinking about how can we solve this problem for the customer and do it so that we can make a lot of money off of this for the business, A lot of times those goals and objectives don't align. And so by nature of that collaboration, we're not always going to agree. However, from a cultural perspective, we had a culture of disagree but commit. So at some point we would make a decision. Not everyone would feel like, you know, it was their favorite pick, but that was okay. We would still disagree and commit to move forward because we had an action bias and we wanted to make sure that we didn't belabor our discovery, belabor our decisions, et cetera. But collaboration does not mean consensus. It does not mean the lowest common denominator. It means every function brings their expertise to the table to make the best possible decision on behalf of the customer and the business. Of course, with evidence. But at some point you're going to have to agree to move forward.

A (28:36)

Yeah, I know, I love, because, you know, you kind of talk evidence is going to beat an opinion. Everybody has a voice, but not to vote. You know, I think I hear the other end of that anti pattern being like for many people, role clarity or stay in your lane, you know, kind of thing like this, like this is an engineering decision or, you know, this is a design decision. I do get a lot of those. I am the business, you know, this has to do with finance. How dare you ask a question, engineer around a, you know, the business model question. I'll tell you how I build products, you know, because some people kind of ask me even about writing stories and I say, this is an indictment on collaboration for me. And I tell people there's nothing I should know that my designer, my engineer should not know. And let me be very clear, we all prototype. They're like, oh, I'm like, look, there's somebody on my team called a designer. They are experts at using figma. They know how to do things quickly. They are stuff. But when we are trying to solve a problem, I take a piece of paper and I draw what I'm thinking. The engineer takes a piece of paper, he draws what he's thinking. Of course the designer's sketch is probably gonna look better than us that suck in this aspect. But we're gonna all present to each other. Okay, here's what I'm thinking in my sketch. I think we should do this. And we all share our knowledge. The designer's job now is to take what they have learnt, put it in one of those tools like Figma, and present it back to us. When he does it, we're like, no, that was not what I really meant when I was drawing it this way. Or we now start to see. Okay, okay, that was not what it should be. It's not possible anymore. Oh, yeah, that's not gonna be compliant anymore. And I tell people, you know, that's what collaboration feels like. And the way I describe it to people, you know, I use a lot of sports analogy. I tell people my brain is shallow. I can. Life makes sense in sports. Everybody is in the huddle whether your play is called or not. If you think about any sports team, it's like, okay, everybody comes in the huddle, they get the same context, they break, they are aware, even if the ball is not being passed to them, they are aware of what the intent is and the players. And I say, that's kind of my first rule. Everybody should have shared context. Second, there's nothing in any sport that suggests like, oh, I am a goalkeeper, I am not allowed to score a goal, you know, or I am a striker, or I'm, you know, I'm playing offense, I can never play defense. You know, it's like that's become. The outcome is bigger than the individual skill set. I will defer to you because you're the best person with the best skill to do it. You know, it's like, who take a penalty kick? I hope the person that is very good and gets paid millions to take penalty kicks. But should my number be called? Should I be standing in front of an empty goalpost and I can kick the ball in. I'm not going to be like, nope, not my job.

B (31:18)

That's right.

A (31:19)

Which is such a cultural thing I see in so many companies. And I say, well, that's a very output project based behavior. It is a racy. There is some charts that indicates this is where my job starts and where it ends. So when I do my job, I hand it off to somebody else and I have to coach teams. That is the opposite of true collaboration, which is a big shift mentally for people. And I have to kind of coach, what does that look like? You're moving from sequential handoffs to doing it together. And you're like, every piece of it together. I'm like, yeah. He said, well, but do you Code together. I say, oh, yes, I suck at coding. That's why I have an engineer. But there's nothing that the engineer will need to know to code that I don't pass on. Yeah, it's kind of like you are the best skill at it. It doesn't mean that I do it, but I participate in you by removing any kind of clarity, by ensuring you have all the information that I do and context by coming in, by stepping in. That's how we collaborate in every aspect. You collaborate in problem identification or validation. We go talk to customers together. We go. These are all the things we do together. That's the key of true collaboration. Okay, this conversation is obviously a super fun one. I'm sure we can have it all day. I'm trying to make sure I'm capturing some of the traps that I see and some of the anti patterns. Many teams confuse the trap of coordinating work. And I think that that is collaboration and that may be some part of role clarity. Many people think every meeting is a collaboration. We talked about collaboration. People think it's like consensus in some ways. No, people are assuming that we can collaborate even if we have no trust or rapport, you know, and people are like, why are you. You're trying to be in my space. But one of the other pieces that I think people fail to ignore is the cultural environment.

B (33:05)

Yeah.

A (33:06)

You know, we talk about the culture of experimentation and learning and I think one of the things is the blame game. The lack of accountability or the failure, the fear of failure hurting collaboration. Like if something goes wrong, the reason I want it to be in your lane is so that I can blame you. Like design failed, engineering failed rather than we failed. Maybe talk about that. How do you coach that? My lane versus your lane, Our failure versus individual failure.

B (33:36)

Yeah, Well, I think that the organization has to be set up to incentivize everyone to collaborate, quite frankly. So having that shared definition of success is critically important. So that product doesn't have one definition of success. Engineering has a completely different definition of success. Design has a different definition of success. So having that shared, quantifiable definition of success is basically what aligns the team to solve the problem. Right. To solve the problem and achieve the results that we're trying to achieve. That is absolutely critical. Point number two is everyone has to have access to the right information and the right data. So access to customers, access to product data, telemetry, financial data, the evidence that's going to help us make the best possible decision to achieve that outcome. Without those things, it's difficult to collaborate because I agree there's finger pointing, there's the blame game. Worse anti pattern than I see is when engineering is measured on velocity, but product is measured on results. Even worse if design is like measured on their ability to implement a design system, no incentive to work together, no incentive to collaborate. So leadership, you need to make sure that you have functional alignment on that definition of success. And that definition of success is what you're holding the teams accountable for versus their functional roles. I think that mitigates a lot of the challenges around the finger pointing and the blame game, et cetera.

A (35:04)

We reinforce that by saying there's nothing like a functional objective, you know, like design objective or engineering objective or product management. Their only team objectives. You know, if a player can win without passing the ball, you know, they'll never pass the ball. It's like, I don't need you. You know, team means like I cannot accomplish things on my own. I want to end quickly on this point because many people see collaboration remotely or even in a traditional sense at this team level. I have seen many companies struggle with is leadership, collaboration, other leaders collaborating with other leaders. Like this is my silo. How do you coach that? And what are some of the things you use to help leaders collaborate with other leaders?

B (35:48)

Yeah, I mean, I think it goes all the way up to the overall business mission and objectives as well as the strategic context that we talk a lot about. And I actually was worked in an organization where every vice president basically had their own objectives and their organization laddered up to that vice president's objectives. And there was no incentive whatsoever for these vice presidents to work together. Because my success, my compensation, was based on my ability to achieve my objectives. And if Joe over here, the VP of a different area, needed to get something done and needed my help, I'd get no credit. It makes me sound like a horrible person, but I get no credit for helping Joe. And when the organization was going through a major transformation, one of the best things that actually our head of HR did was in order for us to transform, she made every vice president accountable for the success of that transformation by tying their objectives to that. That changed everything. Now all of a sudden, the organization, every vice president, was focused on the success. I believe that to get leaders collaborating with each other, they need to understand that why? Again, they need to understand the higher purpose. What is it that we're trying to accomplish? I also believe, Christian, that leaders have two roles. They have their own discrete role and then they have their role as a leader in the organization and the best performing organizations are the ones who take both of those things very seriously and they align the objectives behind that dual role.

A (37:25)

I often try to describe to people that the difference between a group of people and a team of people is a common goal.

B (37:32)

Yeah.

A (37:32)

And you know, many people often look for what divides them than what brings them together to play as a team. And I, you know, I was just coaching a leadership team at a very big company and I was trying to explain to them, you have a common goal of leadership of this organization.

B (37:49)

That's right.

A (37:49)

You have a common goal of coaching this. I say, you know, like I go back to my sports mindset again, there's a coaching team and I'm trying to help people think like your team doesn't have the same goal as you. You see, the people that share the same goal of leading the organization are the leaders. So it should not be lonely. You should lead together. You should leverage the strengths. And the same way you want to defer to a designer for experience or defer to an engineer for technical stuff, I can defer to Leah because she's fantastic at stakeholder management. I can defer to someone else because they are great at presentations. Like that's the idea of a leadership team or a coaching team. And it's one of the powers that unites people, ensures that we work together. This idea that we cannot accomplish something individually, we need different cross functional, complementary skills.

B (38:42)

That's right.

A (38:43)

Absolutely magical. Leah, this was fun. I mean, I'm sure we could collaborate on this all day long. And we're doing it remotely in some ways and we're talking, we're riffing about some of these things. I have absolutely enjoyed the conversation. Thank you again for spending the time and for being here on Product Therapy.

B (39:03)

Thank you, Christian. Fun as always.

A (39:05)

Want to learn more? Until next time, Please check out svpg.com, sign up for our newsletter that Mary Kagan puts out. Join us for one of our workshops near you and get access to all of the articles and content we put out. And thank you to everyone for joining us. Until next time, have a good day. A quick disclaimer. While this podcast is named Product Therapy, it is not hosted by licensed therapists or mental health professionals. And it is in no way a substitute for professional mental health services. We recognize the importance of mental well being and encourage anyone facing personal difficulties to seek support from qualified professionals. See www.findahelpline.com.