BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Generous, High Fidelity Communication Is the Key to a Safe, Effective Team

Generous, High Fidelity Communication Is the Key to a Safe, Effective Team

Bookmarks
48:47

Summary

Denise Yu discusses why one might be feeling unheard at the end of some conversations today, and presents some tools to engage with colleagues and facilitate better conversations.

Bio

Denise Yu is an engineering manager and Rubyist, most recently at GitHub, but currently on hiatus. She speaks and runs workshops frequently at conferences in North America and Europe on topics ranging from scaling organizational culture, to reliability engineering, to sketchnoting.

About the conference

QCon Plus is a virtual conference for senior software engineers and architects that covers the trends, best practices, and solutions leveraged by the world's most innovative software organizations.

Transcript

Yu: My name is Denise. This is generous, high-fidelity communication, and how that is the key to a safe and effective team. I'm actually on a career break right now, just taking a couple months off to unwind from a very long pandemic. Earlier this year, I was a senior engineering manager at GitHub, working in a department called Communities. We are the org that builds tools that power open source communities on GitHub. I worked specifically on GitHub Sponsors, which lets people give money directly to the maintainers of open source projects that they depend on.

Being an engineering manager has been by far my favorite job in my career so far. I loved being a senior engineer, but being a manager really stretched my abilities in ways that I could not anticipate. I went into the job with a lot of leadership experience, a lot of experience running projects and being in charge of things. Nothing truly prepared me for the process of building a great team. Because that process wasn't just about putting the right energy out into the world. It's not just about nailing your top-down communications. The process of building an amazing team is messy. It's incremental. It's humbling. It's every little decision you make. It's like every Slack DM you choose to send, every choice you make about when to give feedback, how to give it.

Just Culture

I want to explore how communication skills within a team can make or break that team, and why the team as a unit matters in terms of building a resilient and just culture. I want to start by contextualizing this talk against just culture, because this track is dedicated to a deeper examination of that concept. The idea of just culture comes from academic research in safety critical industries, such as medicine, aviation, manufacturing. We've adopted some of the ideas into software engineering in recent years. I think that just culture is a philosophical approach to improving an organization's ability to manage incidents through a balanced examination of both environmental/cultural/organizational factors, as well as individual accountability. In recent years, more tech organizations have been trying to apply the principles of just culture as we approach the limits of what traditional safety management practices can give us. Of course, not all of us work on safety critical systems where all of this research originated. We don't necessarily have the same constraints and requirements that medicine or aviation has, to be very worried about mistakes. Our organizations are still deeply invested in wanting things to go right and learning from when they don't. A lot of the practical applications of just culture have been described through Sidney Dekker's work. I'll be referencing his work a lot.

In order to improve and make our systems more resilient, just culture seeks a balanced examination of the environmental factors that contributed to a mistake, as well as individual accountability from the person who was directly involved in the incident. I want to pause here and just point out that just culture's definition of accountability is quite narrow. It might be a bit different from how we generally think of the term. In just culture, accountability doesn't mean blame. Rather, it means that we literally want the person who was involved in the incident to be able to talk to the rest of the org about it so that we can all learn from it to literally give an account of what happened. In just culture, it's really tricky to get this balance right when you look to both environmental, or cultural factors, and individual accountability, if our goal here is to improve the overall system. Because on the one hand, you don't want to place too much accountability on an individual, because if you push an individual to own up to too much, they'll feel penalized. The long-term effect is that fewer people are going to speak up when they see something going wrong. In other words, you just suppress reporting. Any information that potentially could have helped avoid or mitigate a problem just gets pushed underground. This does not make your system safer. On the other hand, if you place too little emphasis on individual accountability, you potentially create a culture of increased carelessness in the future, because the people perceive that their managers don't really care about things going wrong, then, why should they? In both of these situations, we lose out on opportunities to learn from the failure and improve the overall resilience of our systems.

Decision Making Frameworks

Dekker's research showed that when we're trying to get this balance right, leaders in our org are generally looking at human choices that led up to a mistake. They're making a judgment call. Was this action an honest mistake, or was it at risk behavior, somewhere in the middle, or was it straight up negligence? What kinds of actions fall into each of these boxes? That depends entirely on your organization. Figuring out where these boundaries should be requires really specialized knowledge about the work that you're doing. It's a difficult task, even when you do have all the information. Sometimes organizations use devices like decision trees to add some structure and transparency to this judgment making process. Here's an example from the aviation industry. This is a series of bubbles that you traverse by answering yes or no at each juncture. The further you make it to the right, it means that you took more precautions along the way, and therefore, the person involved in the incident is less likely to be held to account. I think it can be sometimes useful to formalize decision making like this, but at the same time, creating a diagram that's useful and generalizable, necessarily requires us to buff away a lot of the finer details and edge cases. The problem with that is that, of course, life happens in these edge cases in finer details and reality is messy and is full of surprises.

As I learn more about decision making frameworks, another example that popped into my head was engineering career progression frameworks, or career ladders, which attempt to systematize the growth of engineering ICs. If you make your career matrix really detailed and concrete, what can sometimes happen is that very ambitious ICs can turn them into a box ticking exercise. It stops being a meaningful framework for both engineers and their managers to help them grow their skills and impact. Another thing that both decision trees and career ladders have in common is that they were both written by a group of people who had a certain set of opinions at a certain point in time about what exactly is an honest mistake, or a senior engineer. People are going to bake in their own biases, experiences, and outlook at a particular snapshot in time. I think that while these tools can be helpful, if we truly want to create organizations that can learn and adapt quickly, we should not place too much emphasis or too much confidence in what's already been written, and instead, continually reassess whether these tools are still serving their intended purpose. When they stop doing so, we can change them, we can iterate them, or we can thank them for their service and let them go.

Every time we try to formalize an inherently subjective idea, like an honest mistake, or a senior engineer, we have to expect that we're just going to get it wrong sometimes. I used to give a talk about why distributed computing is so difficult, both in theory and in practice. One of the core messages was that with large scale distributed computer systems, we honestly should just expect things to go wrong at some point because our systems will be designed more robustly if we build in the possibility that they could fail. It turns out that big socio-technical systems are no different. Humans working together towards a complex goal, like building an organization that can learn from mistakes well, is not all that different from a large system of computers executing instructions to stay online as much as possible. If we assume that we're going to get things wrong sometimes and we design for failure, this is how we build resilience into big and unpredictable systems. Dekker's work over the years has found that when an organization tries to decide what types of actions require accountability and oversight, who should be held to account, when, to what degree? We're just going to get it wrong sometimes. It might be a more interesting question to examine who is making these judgments rather than the specifics of like, what actions go in which box. It also turns out that we humans really like defaulting to negligence. We really like boiling down complex problems to statements like, this person did something wrong, which sometimes creates organizational impacts that don't actually benefit us in the long run. Because even the best managers and leaders among us are only human. That's ok, because, like we can design against network partitions in distributed systems, we can design for this mistake in judgment making. We can tolerate mistakes in judgment calls, as long as we have a mechanism for making things right. That's where teams come in.

Table Stakes When Implementing a Just Culture

Table stakes for implementing a just culture is that psychological safety has to be present. Psychological safety was first coined by Dr. Amy Edmondson. The classic definition is that it is a shared belief held by members of a team that the team is safe for interpersonal risk taking. Today, we commonly think of risk taking as speaking up, bringing up difficult issues, and being vulnerable. Vulnerable enough to say, for example, I made a mistake and here's how I'm going to fix it. When you ask for individual accountability, the only way you're going to get an honest and insightful account is if the person telling the story feels like their job, or their reputation won't be in jeopardy afterwards. In my experience, and I think in a lot of people's experiences, your team is your primary social environment at work. Most engineers learn about cultural norms at the team. Most engineers pick up on cues about how to be successful at this organization from their teammates. For most of us, our happiness and our safety at work is directly influenced by how safe and supported we feel around our teammates. If you're on a team where you feel like you can speak freely and disagree without fear of consequences, then I believe that you have the idea of social support that Dekker talks extensively about. This kind of social support is vital to, number one, psychologically recovering from mistakes we make. Even if you know you're not going to get in trouble, it still sucks to be the person who was at the wheel when prod went down, or whatever it was. Also, secondly, social support is really important for being able to effectively take accountability for those mistakes, and to help the wider org actually learn from them.

As an engineering manager, if your org is pursuing a just culture model, or even if they're just trying to learn more from incidents, I think that the best investment you can make is in your team. Even if none of the just culture stuff earlier resonated with you, I think that investing in your team is still worth your while because it's realistically probably the only thing within your direct control. I believe that there's one behavior in particular that teams with high psychological safety do really well, which is that they disagree productively. In terms of building a just culture, having teams that can navigate conflict effectively will form your strong foundation for a resilient organization.

Disagreements in Communication

I'm going to shift gears a bit into the second half of this talk, which is more focused on communication. We're going to dive a lot deeper into what a good disagreement looks like. A good disagreement, in my opinion, boils down to three characteristics. A good disagreement is engaging, fair, and generous. A long time ago, I was a competitive debater in university, so I understand the mechanics of a good debate pretty well. I noticed over the past couple of years that I started leaving conversations with coworkers and friends, sometimes with a nagging sense of incompleteness, a feeling like I hadn't really been hurt at all. I realized that this was the same feeling I got when I finished a really bad round of competitive debating. A lot of disagreements at work are missed opportunities to find a better solution. Instead, they can hurt relationships, and perhaps create a chilling effect in the future, if, for example, one person feels like they really were not listened to, that they're never listened to. I spent a lot of time reflecting over the years about what great disagreements look like. It turns out, they look pretty similar to great debates. Good disagreements are engaging, first of all. By engaging, I mean that everyone is actually taking time to respond to the arguments being presented by their peers, instead of just waiting to say their own piece.

Let me give you an example of a conversation where engagement is not happening. Meet our two engineers, Katherine on the left and Jimmy on the right. Jimmy and Katherine are going to disagree about something. Katherine says, "I think we should transition away from our hosted app analytics solution called Datacat and look into building our own in-house monitoring solution, because we're hitting the limits of what we can learn from Datacat's current analytics tools." Jimmy responds, "That makes no sense. We're struggling to staff up our core product teams. I don't think there's any way we can get headcount or budget to maintain a whole in-house monitoring solution when Datacat gets us 95% of the way there." Katherine replies to that, "If the gap is 5% today, it's only going to get bigger in the next year, because our sales teams have already told us what our projected growth is going to be, just over the next 12 months." At this point, Jimmy is getting frustrated. Jimmy says, "I think we should look into other alternatives. I think we should explore other off-the-shelf solutions." It concludes with Katherine saying, "You're not really listening to me. I have looked at other vendored solutions, and no one is selling a tool that can keep up with our scale."

I'm going to explain what happened. First, I want all of us to take a beat and reflect. Does this disagreement sound familiar? When is the last time that you saw or took part in a disagreement like this? How did it make you feel? How would you imagine the other participants felt? In debate parlance, we refer to this type of conversation as two ships passing in the night. Katherine's argument is that Datacat is becoming a poor solution to her team's specific problems. Jimmy is making an argument about resource allocation. Both of these people are experts. They're equally familiar with the problem, but they have different ideas about what's the most important aspect of the problem. Jimmy didn't disagree with Katherine's premise that this company is going to outgrow a vendored monitoring solution. Katherine also didn't engage with Jimmy's concerns about staffing and budget being a finite resource. The outcome here is that both Jimmy and Katherine will walk away from this interaction, feeling pretty frustrated. There's also no sense of resolution if you're a listener. For example, if I was a judge, and this is a real debate round, this would be a pretty terrible round, both of them would get really poor scores. This conversation might have gone differently if Jimmy had first paused to consider Katherine's concerns, before offering up his own arguments, and likewise for Katherine in her later response.

I see this dynamic happening in async settings, especially, because it's so easy. The barrier is so low to go into someone's Google Doc or someone's written document, whatever it is, and drop in 30 different comments each along the lines of, but what about this other alternative? What about this? What about that? Without ever having engaged with what the author did right. In doing so, you're not engaging with their ideas. Secondly, you're also not giving them any credit for having done some critical thinking, because maybe they did consider some alternatives but this is the best version that made it onto the paper. Engage with what's there. Give people credit for having done critical thinking. Listen as much as you speak, and I think you'll find that the quality of your disagreements will really improve. Second, a good disagreement is a fair disagreement. By that I mean that team members can equitably participate in the discussion. Sometimes a bad disagreement happens because one person never actually had as loud of a voice as the others in the conversation. This can result in one person's ideas being shut out, and they eventually lose trust in the rest of their team to fairly engage with their ideas. Maybe they'll eventually withdraw from trying to participate all together. This is a big loss. I think this is something that we as managers and leaders should be very worried about. In the long term, this will have a negative impact on the morale of the team.

Some debates are inherently unfair. This one is really tricky for a lot of managers and leaders, because it requires knowledge of power dynamics. There are certain aspects of structural power that we can see, things like job titles, things like years of experience, seniority on the team or at the company, and so on. There are also social and interpersonal dynamics that are less obvious, and as managers sometimes we are especially poorly positioned to see those dynamics. Because sometimes when people are creating a negative impact on the team, they shield us from that. Sarah Milstein did an excellent talk at the LeadDev New York this past year, called, "Harassers are nice to me." I highly recommend you go watch this talk and check out this blog post in its entirety. The thrust of this is, as you gain more formal power in your organization, people who are really sneaky are increasingly likely to be perfectly sweet and civil to our faces, because they know that they have to be in order to get what they want. As much as we try to pay attention in our one-to-one conversations, it can be really hard for managers to know who has soft influence over whom. Sometimes you don't necessarily need malice or sneakiness involved, things can still be unfair without anyone deliberately trying to be harmful.

Let me tell you a little story. This is a true story. I told you already that I was a competitive debater in university. There are a lot of different debate formats that use different styles for winning. There's a format of debate called policy debate, which rewards teams that can overwhelm their opponents by speaking really fast, and bringing a ton of evidence to back up their arguments. By evidence, I literally need paper printouts of news articles, that sort of thing. They seem to bring boxes of paper to every single debate tournament, like you would expect from a lawyer arguing a real-life court case. It takes a lot of effort to compile all this evidence. It literally takes hundreds or thousands of hours of work. Many of the more privileged teams on these debate circuits will hire full time debate coaches to help them compile all of this evidence. For several years, the top ranks of policy debate were completely dominated by the wealthiest schools who could afford to pay for the best debate coaches.

Unsurprisingly, a group of black debaters from schools who cannot afford to pay for coaches found that they were consistently not performing well at tournaments, no matter how much they practiced. Instead of competing by the rules of the game, they decided to confront the rules. Instead of coming with boxes of evidence, they started making a new argument in debate rounds that the long-standing expectations of policy debate were inherently unfair to less privileged teams. Policy debate as a whole should reject these old rules and instead evolve towards something more creative and engaging. They argue that being a great debater shouldn't be about being able to hire the most expensive coach. It should be about developing your critical thinking skills, winning people over to your cause, and eventually using that power to do some good in the world. What message are we sending then, when only the most privileged teams receive all the opportunities? Today, this type of argument about the rules or the procedures themselves, is called meta-debate. It's super common across all formats. If you want to learn more about the story, RadioLab did a great episode called "Debatable" about it.

I told you the story, first of all, because I think it's an interesting story. Second, to illustrate that sometimes the rules of engagement are unfair, and they're worthy of reexamination. This is a simplified model that I came up with to encourage managers to be inwardly critical of what we're asking from our teams when we ask them to communicate or to disagree with each other. On the x-axis, we can ask for communication in a slow or fast style. On the vertical, we can ask them to do it together or alone. To add a bit more color to this, I want you to think about what your rules of engagement are. Are you having a lot of team meetings where folks are asked to spontaneously respond to new information and come up with an opinion on the spot? That's a fast and together style. Or, do you give your team written materials to review ahead of time and explicitly block out time for everyone to do it, which is more of a slow and alone, or maybe eventually a slow and together style. Some other examples of communication-oriented tasks include asking your team to develop opinions on something really high context, brainstorming ideas together, giving their opinions, and responding to each other's ideas. If you're finding that your facilitation style falls heavily in one quadrant of this model, consider mixing it up once in a while. Consider sending out reading material ahead of time if that's not something you normally do, or give people explicit time at the start of the meeting to review the material. Or maybe let people brainstorm independently before sharing out their ideas.

If you sense that some people are being unfairly shut out from a conversation, it's our responsibility as managers and leaders to stop the conversation all together. Then do some critical thinking and examination about what made it unfair. For me, personally, I call it a day. I give people time to cool off. Then I go and check in with the people who I think were being shut out. This is one of those opportunities where your actions as a leader establish your culture. This is one of those brick-by-brick things. You can either choose to plow forward and to continue to shut out your most marginalized voices, or you can use your structural power to try to make things right. You can explicitly tell those folks that their ideas matter, and that you will back them up, and, of course, actually do that the next time you get the team together to continue the conversation. I'm going to repeat this part because I think it's really important. As a manager or a leader, you have structural power and privilege here. It is a fantastic use of that power to use it to equalize the playing field for your team. Let's pause and reflect again. Now that you know a little bit more about the different ways that disagreements can be fair or unfair, when's the last time you noticed someone getting shut out? How might they have felt? What is something that you could have done from your position of power to include them more effectively?

Third and final characteristic of good disagreements. Good disagreements are generous. In philosophy and in debating, actually, there is something called the principle of charity, which is that when you are debating an opponent, you should always try to understand their statements in the most rational way possible, as if they made the strongest possible version of their argument. Here's an example of ungenerous and then generous interpretation. Say you have a staff engineer on your team, and you're presenting the architecture for a new project. She points out something that looks like a load balancer in the diagram, and she says, why do we need a load balancer? There's actually a lot of different ways to interpret this question. An ungenerous interpretation would be to assume that she has zero knowledge of load balancers generally, and then launch into a 101 level explanation of how load balancers work. I've actually seen this happen before, and it was as awkward as it sounds. A far more generous interpretation is to assume that she's deployed a load balancer before, she understands her general purpose. Instead, she's asking a very high context question about why this particular system might need load balancing around a particular set of services. Maybe she knows something about typical traffic patterns in this scenario that you might not have thought of yet. Even better than trying to guess how generous or how ungenerous, even better is when teams actually check for understanding. It gave me a lot of energy to see teams doing this.

In that example, the person presenting the architecture might ask a clarifying question before trying to answer. That clarifying question might be something like, just so I understand your question, are you looking for more clarity around the assumptions we made about traffic to these services or are you asking a different question? Getting everyone on the same page when you work in a really high context environment is really difficult. Disagreements tend to be a lot more productive, though, if you can take a couple of extra beats, and just make sure you're always treating each other with dignity and generosity. One more quick round of reflection. When's the last time you noticed someone interpreting the words of a teammate in a really ungenerous way? How do you think they felt? Has this happened to you? What impact did that ungenerous interpretation have on the overall tone of the conversation? A good disagreement is engaging, fair, and generous.

Takeaways

Now that you've seen a couple of examples of bad disagreements, we'll wrap up with a couple of actionable things for you to take back with you. Of course, it's one thing to observe and to recognize, but that's not enough. Our job as managers is to play an active role in shaping the culture we want for our teams. That involves rolling up our sleeves and doing. First, I think we have to model graciousness and humility when people disagree with us, because we have the most formal power on the team. It's important to show that you as a manager can deal with being told that you're wrong. As managers, we get it wrong all the time. If someone disagrees with me in private, and it results in a conversation where we get to a better solution, I get their consent to share what their objection was at the next team sync or just in the team channel. I make it super clear that their feedback was welcome, relevant, and impactful. In fact, I am changing my plan because they made a compelling and productive argument, and I'm going to be partnering with that person on the follow through. I might write a message like this, "Hey Team. I know I said this morning that we will be doing X next, but Amanda made a really great point to me earlier that we're spreading ourselves too thin. She also shared with me some new context that I didn't have that one of our tracks is delayed because of the deployment problems last week. I'll be working with her over the next few hours to figure out a new game plan for our coming weeks, let me know if you have input that we should know about." My goal here is to give credit to good disagreements and to engage the team in crafting the solution together. If you're having interactions like this with your team regularly, it means that you've likely done a decent job at creating some psychological safety. I think that's something you should be proud of. Because when your team feels comfortable bringing up problems to you, you can get in front of potential issues before they happen. That's exactly how just culture seeks to make things better. Summarizing and naming things, also a very useful tactic. Try this out.

To go back to the two ships passing in the night example, if you see that people are talking past each other, you can try to intervene with something like, "Katherine, it sounds like you're really worried about the problem solution fit of our monitoring solutions in the coming years. It sounds like Jimmy is really worried about resourcing. I think these are both really valid concerns and I love that we're getting as deep as we are into this. I'd love to hear a little more from Jimmy on Katherine's core idea. I want to make sure that everyone's ideas are properly engaged with before we move on." Nothing too fancy. When you see these bad disagreements happen, you have structural power to bring things back on track. You can use that power to level the playing field to amplify voices who you suspect are being shut out. As a leader, it's far more important for us to create space than to take up space. Anyone can take up space, actually. As leaders, we are way better positioned to be the ones creating space. As I learned more about team dynamics, I learned that everything I say inherently has more weight when we're trying to find a solution because I'm the manager. At first, that was really scary to me because I was like, I don't know what I'm doing. I'm just making things up. I'm just guessing. Here's the thing, when you're just making things up, or you're just speculating as a manager, at best, it can be distracting. At worst, it can actually be harmful because people sometimes think that you're privy to a lot more information than you actually are. When in reality, the engineers directly working on the problem are the experts. Recall earlier that in order for just culture to be effectively implemented, we need to make space for the people who have the most direct knowledge so that they can creatively and effectively solve problems.

To mitigate this phenomenon, where I noticed that every time I spoke, I took up all the oxygen in the room, I started doing two things. First, I worked on developing my facilitation skills. Secondly, when it comes to substantial contributions, like actually coming up with solutions, talking about the problem, I started speaking last. It's important to note that this isn't about trying to get the last word in. Speaking order is just one tool. The most effective thing you can do as a leader is learn to facilitate conversations in an inclusive and productive way. Finally, a great thing you can always do if you sense that your team is in disagreement territory, you can always reaffirm shared common ground and remind everyone that we are on the same side. It's the whole team versus the problem.

Conclusion

Building a healthy and safe team is a really hard thing to do. Hopefully, by the end, you'll have a clear idea of some of the concrete behaviors on a psychologically safe team, how these teams communicate, and some ideas of what you can do to help your team get there. If an organization has a lot of independently strong teams, my bet is that the org will be so much better equipped to pursue a just culture, because the cost of getting it wrong is so much lower. When we design for failure, when we think about building resilience into our organizational systems, I think that we end up with building stronger systems overall. Ultimately, that comes down to having really strong teams that can support each other, provide social support, and know how to navigate conflict.

Questions and Answers

Brush: You mentioned psychological safety and what it means. Sometimes folks confuse psychological safety for the ability to not hear critical feedback, to not have to get that direct feedback. In your experience, how do you handle that situation?

Yu: I think one misnomer that a lot of folks have about psychological safety is that if you're happy and healthy and safe on a team, you never push back on anything, the team never disagrees and nothing spicy ever happens. I actually don't think that that is really how healthy teams operate. Because as long as you have a group of people with different experiences and different ideas in a room, which is always the case when you have a group of software engineers where the group is larger than one, I've never seen two people agree perfectly on everything. Some level of natural disagreement is always going to happen. The question is, how is the team responding to those disagreements and recovering from that? Just culture's whole idea here is that social support, like when these disagreements happen, you have enough of a social foundation so that you can recover from that disagreement. So that me disagreeing with your idea doesn't come across as Denise hates Michelle, or something like that. Because we're on the same page there. We're just here to figure out what the best solution is to this problem that we both have to solve together. The key really is to build a lot of trust within the team, which is, of course, way easier said than done in all circumstances, especially if you're beginning from a low-trust environment. It's like, how do you know if you're even moving the needle when no one is saying anything to you in team meetings, or one to ones, or anything like that? I think it's really tough.

Brush: I think the key thing was focus on, how do people respond to the feedback? How do they feel supported during receiving the feedback and not about trying to avoid it?

The most ungenerous thing happening to me is when an opponent starts doing something else when you try to make your point. This is about not having respect. Then sometimes this is the manager themselves. How would you respond in that situation?

Yu: That's really rough if that's your manager, because that's supposed to be the person that's looking out for you. That's the person with formal power, who should be establishing that the norms of communication are based in respect, and being on the same page about what we're here to do. It sounds like this is an experience that might have happened to you. That really sucks. I just want to validate that that is a terrible thing to have to experience. In the case where it's a teammate, I do expect that team leads and managers, the people who have the formal authority, take some feedback on board about how they're running meetings, about how they're facilitating meetings. If this is a regular recurring thing, that's some feedback that needs to flow from the managerial level down to those ICs who are consistently displaying that lack of respect. Other things I would consider doing if I was someone in charge of that situation is changing of the meeting structure, just as an experiment. There's no one-size-fits-all thing here. If you're constantly in a situation where it's like one person lecturing, try to change up the meeting format to be more dynamic and more interactive. Try to create situations where people have to be engaged, people have to sit with their ideas, and they have to collaborate with others to mesh their ideas together before just saying their piece.

There's different facilitation tactics, if you're really interested in this. I learned a lot of this when I was at Pivotal from the designers. They all were very immersed in the world of design thinking, which I don't know super a lot about, but I know that's where a lot of those facilitation tips and tricks came from. I think if it's your manager straight up being on their phone all the time while you're talking. That really sucks. At that point, I think upward management techniques are things that you would have to look into, if it's not an option to switch managers or switch teams. I know that that's rarely a feasible option. If I suspect that someone's not paying attention with me, I do the thing where I say something, and I check in with them. I'm like, just so we're on the same page, you agree to do this and that. Just get verbal assent from them that they heard you, that they understood your point, and then just operate as if you have their consent for as much as possible. It's difficult to collaborate with people who are fundamentally not interested in collaborating with you, but I would try really hard to. I heard the phrase a long time ago, like very early in my career, if you're in a situation where you don't have a lot of control over things, you can do two things. You can either change your environment, or you can change your environment, which is like, depending on where the emphasis is on those words, it's two different things. That's a tough situation, for sure.

Brush: How would you handle the situation when there's a request coming from upper management that the team doesn't agree on?

Yu: I think this happens to everyone. At some point, sooner or later in your career, you're going to be asked to build something that you don't just agree with. In my experience, there are times when it's productive to push back on this and bring data upwards and try to appeal to upper management, speaking their language. Figure out what is the thing that they're most concerned about, and try to appeal to them on those grounds. There are other times in my career that I've just had to suck it up and just deliver the thing, because that builds enough trust for me to fight the next battle more effectively. Picking and choosing your battles, incredibly difficult, especially if you're someone who's very strong willed and opinionated, like I am. I've had to learn. When you want to stay at a company for a couple of years, for whatever reason, you're there to grow, you're golden handcuffed, whatever it is: it's a marathon, it's not a sprint. If you go out swinging in every single fight you're in, you're going to run out of energy, probably before the end of the first year. Pick your battles and find out how wrong can upper management afford to be? Is this a company tanking mistake? Is this a mistake that will cost a couple of customers? Will it erode all of your customer trust? Figure out what's the worth of pushing back before you decide to push back or not.

Brush: The thing I always add to that is like, how hard is it to change the decision later? If it's easy, then maybe that's the one you let them learn the hard way.

Yu: There's a really good blog post by Camille Fournier. The name of the blog post is called, Other People's Problems. Essentially, it's like, you only have so much energy when you're at any size organization, you need to be deliberate about where you direct that energy. If you keep throwing your energy at things that are outside of your control, you're just going to set yourself up for failure. Also, one of the other outcomes of that blog post is one of the things that is usually within your control is focusing on your team, because often you're not part of the decision-making structure for things that are two or three titles above you.

Brush: When the team is speaking their mind, how can we make sure they are not judged or held accountable for what they said. I'm assuming accountable in a bad way in this sense.

Yu: I think a lot of the negative accountability happens when a person's comments are taken out of context. That usually is like, someone maybe said something in a channel that was meant to be for the team, but it's actually public, and now it's been shared. We're all on social media. I think we've all seen the scenario where a set of comments gets taken out of context. You can't control how other people interpret your comments, but you actually can control the flow of information. You can set up norms and structures so that someone's feedback or someone's comments don't spiral out of control, and they don't get continually taken out of context. One of the best ways to do that is have conversations as a team first. Make your team the safe space for people to communicate. Do it ideally, on Zoom, ideally, in real time, like on video, or at least over audio. Because when things get written down, that increases the risk of people misinterpreting or start taking out of context. Just make sure that disagreements firstly happen within the team, they happen among the people who are closest to the problem, and most in charge of delivering the solution. Beyond that, things don't have to ever get shared outside. What you could do as a team leader, as a manager, if you have a culture where teams share what they're doing to the broader company, which I think is actually a really good culture that I've seen at a lot of different places, make sure that whatever you're posting outward, gets run by the people who originally made those comments. If someone made a really great idea, and that makes it into like a new iteration of this feature, make sure that person is appropriately credited, but understand that you as the leader, you're going to be the person that goes to bat for defending that idea.

Sometimes the people are like staff level or super senior level, they're comfortable with being the person to also defend their ideas, or there's career reasons to also want to do that. I think a good default, as the manager, as the leader, you're accountable for your team's decisions, and you're first-line support, you're first-line of defense for any possible repercussions from the outer org. I know that's only one variety of the negative accountability, things being taken out of context. I think that theme can extend outward. Protect your team, as someone with formal power, protect your people. That's how you build trust within the team. That's how you create an environment where people actually come to you and say things like, "We're heading towards a really bad incident, I need to talk to you." That's exactly what just culture wants to happen. Show with both your words and your actions that you have your team's back. You will protect them. You will make sure that their ideas and their feedback and anything that they raise will be interpreted and recorded in the most generous interpretation possible.

 

See more presentations with transcripts

 

Recorded at:

Aug 01, 2023

BT