Check out a free preview of the full Enterprise Engineering Management 102 course

The "Building Strong Partnerships" Lesson is part of the full, Enterprise Engineering Management 102 course featured in this preview video. Here's what you'd learn in this lesson:

Ryan discusses the importance of strong partnerships and collaboration in achieving success, emphasizing the need for input, feedback, and diverse perspectives from partners to drive innovation. The lesson also covers building trust, effective communication, aligning expectations, being adaptable, and understanding shared goals. Ryan also addresses a question about teams that have different approaches to problem-solving and provides suggestions for finding a middle ground and fostering collaboration. The lesson concludes with additional tips on communication and the impact of team communication patterns on software systems design.

Preview
Close

Transcript from the "Building Strong Partnerships" Lesson

[00:00:00]
>> So we have definitely covered a lot of this, of what makes strong partnerships. But I'll make sure to kind of touch on a couple other things, making sure I mentioned there's dependencies on other teams. In order for your team to be successful, you're not just doing all the work by yourself, there's no way, there's definitely collaborations.

[00:00:20]
You have also opportunities to get input and feedback from partners, right? They see different things that you may not, and so I think this brings to the fact that you can get new ideas, diverse perspectives, and ultimately you'll innovate more. So even in that thing that bothers me of when people created the same tool or something like that.

[00:00:43]
It's if you bring the groups together to think about meeting both needs, the tool or product or whatever you're creating ends up being probably that much more stronger. There's also a wider range of resources, expertise, capabilities, and this can show up in many ways, where it's hiring. We've talked about that, is like, hey, you'd be perfect for this team.

[00:01:09]
Maybe it's leaning on that team, is like, hey, Jim, you have a lot of engineers that are really great at GraphQL. I'm just struggling, I don't have that on my team right now. I really, really need someone with a lot of those expertise. Do you have someone who has bandwidth to help my team?

[00:01:25]
Maybe they can help pair or get input or feedback on that, maybe I need your team to help interview. And so these are things where you wanna be able to help and share those expertise. Partners can also help, add assistance, give advice, guidance, I've said that many times and it's true.

[00:01:45]
So, how do we build strong partnerships? It's an important aspect. Trust, let's get back to that, you want to build trust and this can come in many ways. It could even just be spending some social time together, getting to know each other, how do you operate, maybe it's reading their team charter, having them read your team charter.

[00:02:04]
Getting to really understand each other from that perspective and what are the goals that you're often trying to achieve. When I'm working with newer teams that has been times where we've actually gone and done something like played bocce ball together or gone out for dinner. Sometimes those things you don't know if it's gonna pay off or not, but it does, it's just hard to know the connections that are made.

[00:02:30]
You wanna have effective communication, you wanna have check-ins with your partners, you wanna know how are things going, is my team doing well for you all? We're working on this, what could be better? When things aren't going well, it's better to communicate it, let's talk about that upfront.

[00:02:48]
If I'm gonna miss a timeline, or my team is, I wanna communicate that, I wanna go get ahead of that. It's fine to miss timelines or make mistakes, but leaving it to the last minute to not communicate that, that's gonna erode trust, it's not gonna be look good for you and your team.

[00:03:07]
Align unclear expectations, if you're working on projects where's the divide, who's owning what, where's the handoff happen. Just trying to get that clarity for one another when you're working together is huge. Be adaptable, be flexible. Things will change, you're also partnering with a new set of people that they might have different ideas or different ways of doing things.

[00:03:35]
It might actually help you, you might embrace some of those changes and learn from them. But it also helps you both kind of become together and be flexible in that manner and ultimately collaborate better. I think I'd mentioned this one earlier, but yeah, understand you ultimately have similar goals as a company, you're probably still striving for things.

[00:03:59]
But there are gonna be individual goals for a team, and understanding what a team's motivation and goal is can help you really understand that. And then, yeah, make sure the partner understands your goals and ask them that, do you understand? You could explain it, but even just making sure they fully understand what you're trying to achieve can go a long way.

[00:04:22]
And be open to help your partner, but also be open to help or ask for help where you need it. Any other, yeah.
>> Yeah, I guess I was kind of curious if you have some perspective on when teams and partner teams seem to align in goal, but disagree on approach to solving problems.

[00:04:53]
So in our company, we have a lot of teams that want to actively collaborate. We've got a lot of sister teams to those teams that want to operate autonomously. So it can create this kind of push and pull where one team wants to operate autonomously and drive in their own lane.

[00:05:16]
And dependent teams want to pull them out of that lane and get them collaborating more actively and sharing more information. It can result in a lot of confusion and friction, so, curious your perspective on like how to untangle some of that.
>> Yeah, that can be a difficult one too, and I'm sure there's not management, not a right answer, right?

[00:05:41]
There's definitely different ways to approach it, but I think-
>> It's a themed perfect science.
>> Yeah, but I think there's definitely things that I would try too. Is trying to understand if that one team wants to be very independent and is it looking to collaborate. And that's what it kind of sounds like, it's like there's others wanting to collaborate.

[00:05:59]
It's trying to say, okay, that's fine, let's meet in the middle, you still need to communicate, right? You still need to talk through what's going on. So should we have weekly meetings to sync up to check in on where things are at? Should we do joint stand-ups? It's trying to understand and maybe even giving suggestions or ask them, how do we collaborate?

[00:06:22]
How can we still collaborate? There's gonna be some form of it, right? You may not be meeting as much, maybe even understanding if there's a meet-in-the-middle moment, but also why don't they want to? Ask that, right? What's preventing you from collaborating? Maybe they don't trust your team, that could be it, right?

[00:06:42]
And if that's the case, better to know that than to not, and then you can try and figure out, do I need to start to build up better trust there? Is that something that's been broken? So I think a lot of it is approaching it with curiosity. And possibly another thing is like we often forget, maybe you're frustrated.

[00:07:02]
This team won't listen to me, they're not collaborating, they're siloed. And it's good to try and take a step back and go, all right, let's approach this with curiosity and approach it with best intent. And so to me, it's not probably answering you, giving you a perfect solution, but its ways in which I'm trying to think about how I would approach the situation.

[00:07:23]
But you obviously need at some point some communication or collaboration that's happening.
>> Meghan at chat had mentioned that another tip learn for communication is just acknowledgment and being responsive. Even if it's just saying, I'll get back to you, and then of course following up with what you said you're gonna do.

[00:07:43]
And as you follow it up with, Conway's Law usually happens here. Your software systems design ends up following the communication patterns of your team.
>> Yes, great point for Meg, I like that a lot. Yeah, definitely, that's a good point.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now