Join Jesse and Amy as they talk about the importance of measuring personalities during AWS projects; how remote work makes effective collaboration difficult, particularly for folks who’ve never met their team members in real life; the importance of embracing a growth mindset; how if something is everyone’s responsibility, it’s no one’s responsibility; the three different types of conflicts; what you can do to compromise and find common ground; how it’s a struggle to find the perfect balance between prioritizing new feature developments and cost optimization work for many organizations; and more.
Corey: This episode is sponsored in part by LaunchDarkly
. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com
and tell them Corey sent you, and watch for the wince.
Jesse: Hello, and welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.
Amy: I’m Amy Negrette.
Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure. Today, we’re going to talk about the people side of technical projects, especially people who might introduce roadblocks for completing technical projects. Now, you might be thinking to yourself, “Jesse, Amy, that sounds like it is not about AWS.” But let me assure you that any project involving AWS is going to involve multiple different personalities approaching the project from different angles, who ultimately all have the same solution in mind, but have different ideas about how to get that problem done, or different ideas about what’s the right thing that ultimately get done to begin with. So today, we want to talk about that: we want to dive into how can you have really rewarding conversations with those folks? How can you better engage people who are intentionally or unintentionally difficult?
Amy: We want to be very clear that we are not trying to come after anyone. Every time that I’ve gotten an engagement, it isn’t because someone means to be difficult, but maybe there’s a project timeline, maybe there’s something else getting in the way of them being able to fully be present for that specific part of the engagement, and maybe that’s just what’s causing friction, causing speed bumps. And we’re all well aware of this. Jobs are hard, and especially this sort of work can be difficult. So, first of all, we totally understand, and this is just more about how to get everyone moving in the same direction at the same pace.
Jesse: Yeah, absolutely. I mean, especially with the pandemic going on right now, everybody’s doing remote work, some people have never actually met their teammates in person and they’re expected to work together efficiently, and quickly, and easily. It’s hard.
Amy: It also doesn’t help that when we do come in, we come in under the context of a cost optimization project, or some other efficiency-type title. And that sounds a little like the Bobs from Office Space, which I bring up a lot, especially during internal meetings. And it makes it sound like we’re going to come in to shake a bunch of things up and look for inefficiencies where there aren’t any, which is truly not the case. And it can cause a lot of insecurity, especially about how someone thinks that they’re doing their job, or that their job is somehow going to be impacted by what our suggestions are. It may not just be us, but it may be another migration consultation suite, where someone’s coming in to change the architecture that they’ve worked on for a long time, and that can put a lot of people in a state of
Jesse: And I think it’s also important to note that it’s not just about an external party coming in like Duckbill Group or another external, third-party consulting service, or technical group. It could be an internal separate team. It could be your internal cloud cost management team that is starting conversations with development teams saying, “Hey, I want to better understand how you’re using AWS. I want to understand some of these cost optimization opportunities.” Even in situations like that where all of these conversations are internal within the company, even within teams, there are still multiple different personalities, multiple different people approaching the problem from different angles, and it’s still really, really important to make sure that you approach them collaboratively.
Amy: And ultimately, we wanted to be clear that what we’re going to be talking about is helping people think differently into a growth mindset, and being able to do this work without anyone feeling shame or embarrassment.
Jesse: Yeah. Growth mindset is so critical. It’s something that I love to talk about ad nauseum, and so I won’t dive into it too deeply here, but—
Amy: That’s another episode.
Jesse: [Laugh]. Exactly. Growth mindset is so important for folks in technology teams, especially in today’s technology era where there’s just so much constantly innovating. There’s so much new constantly going on around you, to new technologies, new teams, new ideas, new ways of doing things, new processes, new tools; it’s really important to be open-minded to learning those different things. You don’t have to use every single one of them, but be open-minded to different people approaching problems from different perspectives and different angles.
Amy: Having to face all of this uncertainty will cause some to not be the most cooperative when they have to start reacting into these situations, whether it is an internal change that’s happening, or if it’s an external consulting group; they can start coming back and taking a various sort of stance, and just like being back in middle school, sometimes standing up to a bully is simply how you have to succeed because it’s not about dominating, it’s about compromise and trying to find out what you’re trying to do and find that common ground.
Jesse: Yeah, absolutely. I think that’s the most important part here because when we talk about working with other personalities that are different than yours and having conflict, it’s not about dealing with them; it’s not about overcoming them from the perspective of winning the argument, so to speak. It’s about how do you compromise? How do you effectively find that common ground and move forward together? And sometimes it’s just about sharing context, it’s just about sharing that mental model that you have that might be different than the mental model that this other person has, or maybe the other team has.
Like for example, some teams that we’ve talked to can’t make a cost optimization change due to security, or legal, or product SLA restrictions, but maybe the person who’s coming in from the cloud cost management team or cloud cost management side doesn’t know that because they aren’t as familiar with the product.
Amy: But it can also just be a staffing issue. These projects take work, and if an engineering team is already stressed and stretched to the edge, they’re not going to have the resources, and they don’t want to be the ones to say we simply don’t have the manpower to do this.
Jesse: Yeah, absolutely. And it’s so, so important to be able to identify those bottlenecks or identify those constraints. Because ultimately, if you give a team that already has a ton of things on their roadmap new work and say, “Hey, cost optimization is important.” They’re most likely going to ask you, “Okay, where does this fit into all the other things that are already on our roadmap?” We’ve talked to a lot of companies who struggle with that balance of prioritizing new feature developments with cost optimization work.
And there definitely needs to be that healthy balance between the two because new feature work is obviously important for the business to grow, but cost optimization work is also important within these processes as they go through more and more agile sprints, build more and more things to make sure that each team understands what are their opportunities to really optimize their spend as they’re building new architecture.
Amy: We’ve all seen that bug board where everything is a P1 bug.
Jesse: Yes. The thing that’s coming to mind for me is if it’s everyone’s responsibility it’s nobody’s responsibility. And in the same way, if everything is a priority one problem that needs to be fixed, then essentially nothing as a priority one problem that needs to be fixed, nothing is going to get done because the teams are going to get completely burned out with context-switching constantly between one priority and the next, rather than being able to actually focus on each piece of work as it comes up.
Corey: This episode is sponsored in part by our friends at Lumigo
. If you’ve built anything from serverless, you know that if there’s one thing that can be said universally about these applications, it’s that it turns every outage into a murder mystery. Lumigo helps make sense of all of the various functions that wind up tying together to build applications.
It offers one-click distributed tracing so you can effortlessly find and fix issues in your serverless and microservices environment. You’ve created more problems for yourself; make one of them go away. To learn more visit lumigo.io
Jesse: So, I was thinking about some of the best ways that we’ve seen this kind of work handled within organizations, some of the best ways I’ve seen this handled at previous companies that I’ve worked at, some of the best ways that we’ve handled this with some of the clients we’ve worked with. I actually ended up listening to a really great podcast episode about the science of productive conflict, and I’ll link that in the [show notes 00:10:18]. It basically broke down three types of conflicts; you have task conflicts, relationship conflicts, and status conflicts.
Task conflicts are your disagreements about a problem, a solution, or decision. Maybe I think that the best way to implement this new feature is in Python. You may think the best way to implement this new feature is in Golang, or Ruby, or something else. That kind of disagreement is a task conflict.
The next one is relationship conflicts where you’ve talked about differences in personalities or values. So, maybe I come from a world where product is the most important thing in everything that I do, so I always want to make sure that we focus on feature things first; I always want to make sure that I am doing what is asked of me. I always want to make sure that I am a yes man, so to speak. Whereas maybe you come from an environment or a space where you are more open to pushing back, having collaborative conversations. And it’s just different mental models of how we have been raised in the world, how we view the world, and it’s really, really difficult for us to get out of those different models, so it’s a harder type of conflict to have, relationship conflicts.
And then the third one is status conflicts where we disagree about where we fit into this hierarchy that we’re in together. Basically, who’s in charge? Who gets to decide what gets done?
Task conflicts and status conflicts can be productive; relationship conflicts are generally not productive because like I mentioned, relationship conflicts really come from people with different mental models, different views of the world and it’s unlikely that you’re going to change someone’s fundamental values. But with that said, having a conversation with the other person, establishing psychological safety, giving them that space to say, “Hey, I want to know more about how you view this problem, so that I can also share how I view this problem, and we can better understand each other,” that’s going to make a world of difference in helping both sides better understand each other, and then also find the right solution, better opportunities for maybe a cost optimization team to learn that, maybe, there are these restrictions that mean that they can’t apply all the savings opportunities that they want to, and that’s fine; that’s a business decision that the business and the organization needs to make. But it helps both teams understand that so that they can have more constructive conversations about where, where are the opportunities in areas that we can make cost optimization improvements? We can have good technical conversations together?
Well, if you’ve got questions you’d like us to answer go to lastweekinaws.com/QA
. If you’ve enjoyed this podcast, please go to lastweekinaws.com/review
and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review
, give it a five-star rating on your podcast platform of choice and tell us how you try to form those more collaborative, psychologically safe conversations when you run into conflicts in your organization. Thanks again.
Announcer: This has been a HumblePod production. Stay humble.