A team's ability to communicate effectively and disagree productively is directly related to its resilience towards incidents and interruptions. By taking the audience through a few common scenarios of communication breakdown on teams, we'll provide a framework to help teams talk to each other more effectively, with insights from human factors research, management literature, and the speaker's own background in competitive debating. At the end of this talk, you'll understand why you might be feeling unheard at the end of some conversations today, and you'll have some tools to better engage with your colleagues and facilitate better conversations among your team, along with some tips for asynchronous/remote environments.
What is the focus of your work these days?
I'm right at this moment on a career break. I decided to take some time off to unwind after two and a bit years of basically nonstop working from home and working through the pandemic. Until recently, for the last about two and a half years, I was working at GitHub as eventually a senior engineering manager. The focus of my work was around open source communities, which is super, super fun. This actually is probably my favorite job that I've had so far, just because the stuff that we got to build has such a big impact on people. That part was really awesome. I was the engineering manager of the GitHub Sponsors team. For those of you who are unfamiliar with Sponsors, it's basically GitHub homegrown, like Patreon for open source offering. We let people give money directly to the open source projects that they depend on. Either people or companies can fund those projects, which is pretty cool to work on. Right now I'm taking a bit of a break from that and just doing a lot of reading and writing and thinking about what I want to do next.
What's the motivation behind your talk?
It's a pretty long winded answer for this because I arrived at this topic through a not straightforward path. I'm going to be talking about communication on software engineering teams, which is an enormously broad topic, and even phrasing it that way feels like too concise of an explanation. But basically I'm going to be speaking in the Just Culture track and I'll talk a little bit about how it ties into Just Culture in a second. Basically the reason why I'm interested in making teams communicate better and more resilient overall is, number one, I was a competitive debater in college. I obviously don't do it anymore as a working professional. But having spent years in this world of being very analytical about what you're saying, being very structured about responding to everything that your opponent says, I think I have a pretty well-trained ear for listening to when people are not communicating well. Like I understand the mechanics of what a good disagreement looks like and what a bad disagreement looks like. In bad disagreements, people tend to talk past each other. People tend to try to use power plays, appealing to the relative power imbalance in the conversation rather than the actual content of what people are saying. And there's all kinds of other communication antipatterns, I would say. I think the first aspect of why I'm interested in talking about this is my background in competitive debate has actually to do with the thought that if people in tech knew a little bit more about debating, not necessarily everyone should debate because there are aspects of competitive debate that I don't think we should be doing in the workplace. It's not about overwhelming someone you disagree with by putting 30 different arguments on them. That's not how things should work. But there are pieces of competitive debating that I think we should learn from if we want to be more effective communicators. That's number one. And number two is a couple of years into my tech career, I learned about psychological safety from Amy Edmondson’s work, and I sort of heard the phrase bounced around before but didn't really understand it deeply until I got involved with diversity inclusion initiatives in the tech industry. And the thing that's really stuck with me about psychological safety is that, of course, the core idea is that you need to be able to speak your mind without fear of consequences, which is a lot harder than it sounds on paper, because it's not, consequences is not literally your boss punishes you or demote or something like that. Punishment is a lot more subtle. It's social consequences, long term career prospects being shut out, opportunities and that sort of thing. So it can be really subtle and hard to see, especially if you are someone who is in a position of power, such as a manager, and you're looking at the different changes in dynamics that are causing people to speak their mind or disagree with each other. Thinking about psychological safety on and off for a bunch of years and I became a manager last year and I got a front seat. You get to see everything when you're a manager, you spend all your time on 1 to 1. You learn a lot about what people are thinking about the team, what people think about each other. And it was really eye opening for me to take all the theoretical background and start applying it. So that's the second thread. Third thread, third entry point for me is of course learning about just culture. A couple of years ago I learned more about what it means to build a resilient team, resilience engineering from the SRE. I started speaking at SRE conferences a couple of years ago and got exposed to a lot of different people who are working in taking a holistic approach to systems safety. At the time, people were looking at, how do I keep my web service online through spiky traffic, through this and that? And I think over the years, the conversation has evolved more around resilience in terms of like the entire system, not just the technical system. Humans are part of the system. When a human makes a mistake, there's an interesting conversation that we have to negotiate around with this person ever set up for success, did they make the right decision, given all the information that was available to them, which is a reasonable decision for this person to make? I'm taking a step back and trying to understand how a decision was made in the grand scheme of things. So I've been really thinking about this idea for the last couple of years as well. And I latched on putting aside root cause analysis, which is, classically like when something goes wrong as an engineer, your manager tells you, okay, go find the root cause, go find out why we went down. We're taking a step back from that and looking at things like what are all the different contributing factors? How could anybody in the situation have made exactly the same mistake, which I think is a more interesting conversation and more fruitful, and you're more likely to take that approach. Putting all of that together, I've been very interested in figuring out how to make teams more resilient. That's the shortest version of it. And I think that's when you put together psychological safety and Just Culture and what I know from competitive debating, the common thread for all of those three things is how much do you trust your team? How can you be safe? Can you be vulnerable in a safe way in front of your team? Because if the answer to that is no, then a lot of things stop working. a lot of things get jammed up down the line. People make less than optimal decisions. People don't speak their minds. People don't report when they think that something might go wrong. a couple of days down the line, a couple weeks down the line. And that's how we've ended up with a bunch of the classic case studies around big, big disasters that have gone wrong, like the Challenger disaster, if you want to get into all of that. But what I'm interested in is like the team is a unit, right? Most people care a lot about what team they're on. And I certainly interview for a specific team and not like an organization as an abstract entity. The majority of your day to day experience or happiness at work is dictated by the people in your teams, how you interact with people on your team? So I think as managers, that's the thing that's most within our control. That's the thing that I'm most interested in, giving managers a set of tools to make sure that your team is communicating with each other well. Make sure that they know how to disagree in a healthy manner. Make sure they know how to do the repair work when an incident happens, either someone makes a mistake or someone disagrees in a really spicy way, whatever that is. Harm will come at some point. It's like if you're working out in order to get stronger, you have to tear your muscle fiber and it repairs itself. So what is a manager's role in creating the type of environment of stability.
What would you describe the persona and the level of the target audience for your session?
I'm definitely talking to other managers in the situation just because the engineering manager is traditionally the person that has the most direct influence on a team, on a team's happiness. But I think that people who are at one separate booth, like engineering directors also may be interested or maybe senior IT staff that have a lot of soft influence to sort of recognize that they are the person who sets the tone on their team. I think they could also take some things away from my talk.
Is there anything in particular that you would allow these personas to walk away with after seeing your talk?
I basically want this talk to be a talk that I had seen maybe two or three years ago when I was thinking about going into management, when I didn't really understand the role very well. I hope that the key takeaways are, what does a healthy team look like? What are the concrete behaviors? This is beyond literature. I think the literature is fantastic. I highly recommend, go read Five Dysfunctions of a Team. Go read the psychological safety books, all of that good stuff. But when you actually put those ideas into practice, what is it going to look like on the ground? So I want to give managers some tools for identifying what healthy communication patterns look like. Also tools for when you see the bad communication patterns, how to gently nip that in a bud, and also maybe longer term, how to be a role model, what good disagreement looks like and why that matters.
Engineering Manager and Rubyist, Previously Engineering Manager @GitHub
Denise is an engineering manager and Rubyist, most recently at GitHub, but currently on hiatus. At GitHub, she worked on the GitHub Sponsors program and other products within the Communities department, the mission of which is to make GitHub the best place for open source communities to thrive. 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. She is currently based in Toronto, Canada.