 I'm currently the VP of Engineering at DevMind Software and I'm the founder of Writesbcode. And as Luke mentioned, I'm here to talk about trust in teams. So raise your hand. How many of you have ever said, I just don't trust that person? And if I asked you why, you probably had a good reason. There was an incident that happened. There was dishonesty. Or there were mean or gossiping out for themselves. But if I asked you what makes you trust someone, that feels like much harder to answer, right? But it's super important. It's kind of fundamental to who we are as humans. And it's really important to every relationship, including our working relationships and the teams that we work with. And there's also some research that it's collaborated with business profitability, so you don't tell your manager. But what is trust? It feels like a pretty vague thing. So there's a book called The Thin Book of Trust by Charles Feldman, and he has a definition that I really like. And so that is trust is choosing a risk making something you value vulnerable to another person's actions. And there's a couple pieces of this. The first one is choosing the risk. So in essence, trust is a risk assessment. We think about our past experience with this person and other people, and we decide if we're going to take this risk. It also involves something we value. So what are the things that we care about at work? Like, hopefully, we care about the quality of our work. We care about our team. We care about our own happiness. We care about not getting fired, all of those things. And then the last piece is making it vulnerable to someone else's actions. So normally, when we talk about vulnerability, we're talking about security issues. Like, there's vulnerability in this code, and we need to submit a security patch, right? But the good part about vulnerability is that it leads to innovation and growth and positive things. And where do we talk more about vulnerability and stuff than romantic relationships? And we can learn something from that. And remember that whether you like someone you work with or not, like you're in a relationship with them, you interact with them, you have to deal with them. So there is an institute in Seattle called the Gottman Institute. And they videotape couples interacting, and then they can apparently predict whether they stay together or not. But one of the things they found is that they could actually make these predictions pretty accurately within, like, 10 minutes. Because trust isn't about big things. It's actually about all of the small moments that we have interacting with people. And that makes it, in some ways, easy. Like, cool, I don't have to make a grand gesture. And in other ways, hard, because it's really about every single interaction that you have with a person. So how do you build or rebuild trust? The first thing that we need to do is really kind of debug it, identify the line that's broken, right? And Brene Brown, who's a shame and vulnerability researcher and Oprah's a big fan, has an acronym for the elements of trust called Braving. And I think this is, like, super useful. So the first one is boundaries. Do you respect my boundaries when you're not clear about what's OK and not OK you ask? And you're willing to say no. So I once was leading a team, and our CTO would, like, sometimes do drive-by-pull requests. As a manager now, I totally get it. You want to write code. But as a team lead, I mostly found it annoying. And then one day, he, like, pulled a story. And it was about naming. So the thing was, we had all agreed that this naming was bad. We needed to rename this class or whatever. But we could not actually agree on what to rename it. So here comes the CTO, like, submitting a pull request and making that decision. And so in a lot of ways, this was a violation of boundaries, which are kind of expectations. Like, we expected that the team could make the decision about what to name it. The team, like, was managing their backlog of work. And it wasn't that the CTO couldn't do it, but there was sort of a boundary that we expected them to ask or get context, right? And that's really important, because boundaries aren't about, like, hard and fast rules. They're more like fences with gates. And they can be moved. And we can cross them. But we need to be clear and explicit about where they are. And I think being really clear about expectations is an essential part of this. And that includes, like, success criteria. Like, how do I know that you met this expectation or I met it? And what's the time frame? So the second element of trust is reliability. You do what you say you'll do. That work, this means staying aware of your competencies and limitations so you don't overpromise and are able to deliver on commitments and balance commuting priorities. So in the book Understanding Computers and Cognition, Terry Winogar, grad, talks about the promise cycle. And that's something that we use a lot in, like, three-way handshakes and networking or thinking about promises and JavaScript, similar ideas. So that guide Charles Feltman extracted that into a larger cycle of commitment. And this seems really obvious, except we actually miss a lot of these pieces. Like, if I walk into the kitchen and I'm like, why can't people just wash their own dishes? I'm kind of making a request that people wash their own dishes, but I'm not really being clear about what the request is or who I'm talking to. The other place is, like, waiting for someone to actually say yes or no. And then once they do, being clear about what they're saying yes or no to. Like, are they going straight with my request or, like, are we negotiating some aspect of that? And the last piece I think we forget is reporting back. And that is part of staying aware of our limitations, too. Like, if you can't do something, report back. I think a lot of agile processes actually, like, handle this in a lot of ways, stand-ups, planning poker. And so the main thing is just, like, clarifying your requests and your commitments. So the third element of trust is accountability. You own your mistakes, apologize, and make amends. So my first job as a developer was to do our deployment, basically, involved FTPing files to the production server. And we were using an access database also, which is just a file. So of course, at some point, I went to deploy and overwrote the entire database and all of the data and had no backup. So I had to call my boss and be like, I totally fucked up. And it ended up being OK. There were some server backups, whatever. I could have said, I totally fucked up, but our deploy process is stupid. And we should have a better system, right? Which would be true. But in order to take accountability, I needed to take responsibility for my actions and the impact they had on that. So the fourth thing is vault. You don't share information or experiences that aren't yours to share. I need to know my confidences are kept, and you are not sharing with me information about other people that should be kept confidential. So I actually think, like, Slack and chat apps often lead to a lot of back channel communication, which is effectively gossip even though we don't think of it that way. I once worked with a guy who literally live chatted me a rant that someone else was having. And at some point, I was like, I mean, it's great to know this, but does he know that you're telling me this? Because confidentiality isn't really like, you haven't broken my confidentiality. If I see you telling me something that I think that other person wouldn't want me to know or would want you to keep confidential, I'm going to trust you less. So there is a cycle where we observe behavior and then assume someone's going to act similarly. And so asking, like, does someone know you're telling me this is actually a really useful way. There's also sort of difficult circumstances where saying nothing creates gossip, and so you want to kind of be vague. This is like, they're having personal issues, right? And also ask a person what you can share. All right, so the next element of trust is integrity. You choose courage over comfort. You choose what is right over what is fun, fast or easy. You choose to practice your values rather than just professing them. So I think when we talk about code, we talk about this a lot, and we do a pretty good job. We do less of a good job when it comes to teams and culture. So how many of us have heard someone say, like, oh, we let our developers choose the best tool for the job? Which is great. But if your entire organization uses Ruby and Rails and then someone comes in and is like, I think C-Sharp is the best thing to fix it, they may be right in some ways in terms of the technical problem, but that's not probably going to go over well. So that statement that we let our developers choose the best tool for the job isn't entirely true. And I think that part of this is we need to be explicit about what matters. I have really strong feelings about how CSS should be named, but I value consistency and team buy-in more than my stupid opinions about CSS. And so sometimes we just have to check ourselves that, like, is this about something that matters? If so, let's talk about it, and if not, maybe you should let it go. Element of trust, non-judgment. And I think these really build on each other. I can ask you for what I need and you can ask for what you need. We can talk about how we feel without judgment. So in 2013 was my first time organizing Go Ruko. I also was the first Rights v Code conference. I also fostered and then adopted a dog who turned out to be a puppy mill breeder, which basically meant she was an adorable, lovely pain in my ass. And so at some point I had to go to my boss and I was like, dude, I'm in over my head. Like, I bit off more than I can chew. Like, I need help. Fortunately, conferences have end dates. And I probably should have done that earlier and I didn't because I was judging myself for asking for help and needing help, right? And I think that, like, this one, one of the things we can do is, like, deal with our own shit. Like, deal with our own sense of judgment and shame around, like, I can't get this done, I can't do this, I don't know how to do it. The last aspect of trust is generosity. You extend the most generous interpretation possible to intentions, words, and actions of others. I think this is hard to do without any of the other aspects. So this is a picture from Go Rugo 2012 and in that corner is Abel who's sitting over there and I've worked with a bunch of times and I'm kind of an intense, direct person. And we were having a team discussion. I was kind of frustrated, we came out of it and Abel chatted me and he was like, hey, Rebecca, that was really harsh, what you said. I don't remember the exact details. But this was an instance, like, he could have been like, hey, you're being an asshole, right, but he didn't. He was like, hey, you were really harsh and I don't think you meant it that way, right. So he was sort of telling me like, I assume that your intentions are good but this was the impact and I want you to know. And so that sort of builds trust. So how do we think about rebuilding trust on a team? I actually think monitoring is like a great way to do it. I had a team where they had some trust issues and I started making them like, basically break each other on this, braving. And it was really interesting to see that kind of change and also gives people a shared language for how to talk about issues that they're having. But in general, having some sort of checkpoint that says like, are these things happening? Identify the breach, like having the elements of trust allows us to say, okay, where are things broken and be specific and give specific constructive actionable feedback to someone as opposed to just being like, people don't trust you. And the last thing is I think that modeling good behavior is really important. I'm a big believer in like subversive ground up change in organizations and one of the ways to do that is to say, like respond positively when someone asks for help to, you know, ask for help yourself to make amends to apologize, take responsibility for your actions. People will start to see that and that starts to have a cascading effect. So trust in teams, thank you. All right, good.