Lead Without Blame with Tricia Broderick

Transcript

Shane Hastie: Hey, folks, it's Shane Hastie here. Before we start today's podcast, I wanted to tell you about QCon London 2024, our flagship international software development conference that takes place in the heart of London next April 8 to 10. Learn about senior practitioners' experiences and explore their points of view on emerging trends and best practices across topics like software architecture, generative AI, platform engineering, observability, and secure software supply chains. Discover what your peers have learned, explore the techniques they are using, and learn about the pitfalls to avoid. Learn more at qconlondon.com. We hope to see you there.

Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Tricia Broderick. Tricia, along with Diana Larsen, is the author of a recent released book, Lead Without Blame, but she's a lot more than that as well. Tricia, thanks for taking the time to talk to us today.

Introductions [01:09]

Tricia Broderick: I'm so excited to be here. I wish we were in person. I do really want to just give you a big old hug, but at least I can virtually see you on Zoom here.

Shane Hastie: Absolutely. And hopefully we'll get a chance to be in person again sometime soon.

Tricia Broderick: Oh, I hope so. fingers crossed. Knock on wood here.

Shane Hastie: You and I know each other well, but I suspect the audience might not have come across you before, so who's Tricia?

Tricia Broderick: Oh, I actually appreciate even that question more than, "Tricia read your bio off." Because the bio's never any fun. I heard this term from somebody once, and I really liked it. I'm a recovering developer, meaning I still get excited when I see code, and I'm not even going to front. My son just started college and he decided he's going into computer science, and I will tell you, I was very happy. I didn't show him the happiness that I had, but I am. So I'm a Michigan State University grad in computer science, and I did a lot of mainframe programming, Cobol, DYL280, PL/1, but I did a lot of J2EE stuff as well, and I got pulled into project management and then further executive type leadership roles from director of development to director of project management at a variety of companies over the years.

And I got really lucky and got involved in the Agile space. I got exposed to extreme programming in 1999 and started using Scrum in 2005. And when I say used Scrum in 2005, I was the queen of faking Scrum in 2005. I had perfect burn downs, the whole nine. But I started really getting involved in the Agile community, which is how we got to meet, officially in 2007, including running the conference in '17 and being on the Agile board of directors. So a lot of times, I try and share this information or I try and pay forward what I feel so lucky to have gotten so much from other people in the community and learning how to be a leader, especially a leader in technical spaces.

Shane Hastie: Which leads us beautifully into your new book, Lead Without Blame. I believe it is your first book, it's certainly not Diana's first.

Background to the book [03:07]

Tricia Broderick: It is not. And when you get an opportunity to write with Diana, you say yes. Yes, yes. So it is my first book and I had an incredible partner to have so much wealth of knowledge and experience in writing this, so it was an incredible experience.

Shane Hastie: Maybe a starting point is, why the book? What was the problem that you're trying to fix in the world or the opportunity?

Tricia Broderick: We could kind sum it up a little bit to... I personally wanted to, and this has been kind of driving me for what I do in owning Ignite now, is, I want to help people, especially lead developers and technical people that get promoted into leadership roles and they're never given the skills and training that they need for those roles. I remember my first promotion into a lead developer role, and I'm like, oh, that just means I write the most code, right? I had no idea what it meant to lead and what my skills were as an IC, as an individual contributor, needed to change to actually be an effective leader. And I really had to learn the hard way in a lot of cases. And so for me, this book and a lot of what I do is trying to help other people not have such a crash course and struggles along the way and trying to learn how to be a technical leader.

Shane Hastie: And Lead Without Blame.

Tricia Broderick: Yeah.

Shane Hastie: Tell us about that.

What it means to lead without blame [04:25]

Tricia Broderick: We went back and forth over this because I genuinely don't think anybody walks around going, "Hmm, Shane, who can we blame today?" Nobody's doing that, right? Nobody's intentionally walking around. And I know you're all thinking of somebody, but I swear, they're not doing it. It's not happening. But that doesn't mean that's not the impact that's felt. That doesn't mean that we don't tell ourselves narratives as leaders sometimes that we're like, "Well, if we find out what happened, then we can prevent it." And that's a good narrative in a complicated world. It doesn't really necessarily fit in a complex world, and we find so much time of trying to find the fault with this hope and belief that we cannot reproduce it like it will avoid it in the future, that a lot of times, it ends up just feeling like blame and it feels like we're just looking for the person to judge, to point to, and we're not really focused on what we need to do.

And at the end of the day, whether you're intentional about it or you're not, blame can just completely cripple innovation and quality and teamwork, and it was just something that we really wanted to not walk around, but to say, we need to create environments where blame isn't center when we're leading,

Shane Hastie: You mentioned the we try and we want to solve the problems, and that becomes blame, effectively.

Tricia Broderick: It can.

Shane Hastie: So how do we avoid that?

Tricia Broderick: Some people will look at my statement of that and it's like, "Oh, so we just shouldn't care at all and not have any lessons learned?" I'm like, no, no, let's not go to the extent of not ever reflecting and learning. I hear this term occasionally in workplaces, the single throat to choke. When we're trying to find things to where we're going to hold them accountable, well, what does that really mean? Because every time I've ever heard that sentiment in the workplace, I don't see really what does that mean? Truly, accountability just means to account for, it doesn't actually mean that you're responsible for it. And so for me, to lead without blame is not creating an environment where people are worried about who did what right or wrong, but looking at it at a system lens, at a bigger picture lens and kind of going, "Okay, what happened?" Being a little bit more objective about it and still learning from it, but not taking it in a way that someone did right or wrong.

Maybe that was as kind of the prime directive by Norm Kirth, right? It was the best that people had in the moment that could be made in that decision, and getting away from the label perspective versus what do we want to do going forward? And sometimes we overanalyze something for a false sense of security. And so for me it's kind of like, how do we keep moving forward and what reflection do we need in order to do that? Versus having the big post-mortem meetings, the after death meetings where you pick apart everything and then you're not even using it going forward. So it's really kind of that next step forward, like, what helps us move forward and focused on that? And you need data, you need reflection, you need learning with that, but that's not the goal in itself. The goal is the next step, not the blame.

Shane Hastie: So that's a significant shift, and these are going to be very ingrained habits. How do we break those habits?

Tricia Broderick: If there was one answer, I would have... If we just had a checklist, we wouldn't have needed to write a book, right? What we came at it from in the book was really to go, what are the conditions that need to be true to help make it just not necessary to blame? Like it just doesn't even. So moving away from cooperation to collaboration. If we're building something together, I have a lot less tendency to go, "Well, that was their fault." So the more that you're cooperating or handing things off, the more chances that the finger pointing can happen or the opportunities for that finger pointing. So really creating an environment where people have a shared purpose. We call them essential motivators. A shared purpose, autonomy, but where we switched it up a little bit and added to it, like Daniel Pink calls out, drive is purpose, mastery and autonomy. We upped it from mastery to co intelligence, and that's why I'm really talking about that collaboration.

So cooperation is, "Let's hand off." My part, your part. I can have great mastery in my part, but if I truly want collaboration, I don't want just my mastery, I want our co intelligence because what you are bringing to the table and what I'm bringing to the table, it's not just us, some of those, we actually unlock a new area by just our skills and we unlock new wisdom. And so it's something that's really powerful is by moving people from cooperation to collaboration, you start really focusing on building co intelligence, which then the blame becomes less of a need. There's no handoffs, there's no parts. So we call those the essential motivators to kind of getting rid of even the conditions that prompt blame or shame for a lot of people. And then we take it a step further with resilience factors, with power dynamics, conflicts, things along those lines that you have to keep addressing so that blame doesn't creep back in.

Shane Hastie: Let's dig deeper into collaboration. The mantra of high performing teams has been cooperative, cross-functional teams. How do we get to this level of deeper collaboration, that co intelligence? I love that term.

Going from cooperation to collaboration [09:38]

Tricia Broderick: And I think that's part of what I had to learn as a tech person or when I was... I remember a moment... Actually, it just popped in my head. I remember a moment when I was a director of development and someone was coming to me and they're like, "But I only do objective C." And I'm like, "Show me your computer science degree that says objective C." It doesn't. It says engineering of computer science, right? You've chosen to specialize in objective C. It is not your actual degree. And what I hired wasn't an objective C, I hired a developer who is currently working in this team, on this platform, right? Now, I don't say that with the intention that every tech person should know every single language and all of those things, but I think there are times that we specialize in a way that we actually limit our ability to collaborate.

We limit our ability, and we start to tell ourselves this narrative that to be the most efficient, I must only do front end or I must only do backend, or I must only do objective C, and all of that results in handoffs. And every handoff is a risk, a dependency, a lack of innovation and quality and things along those lines. And so, when I'm trying to move to things, I really kind of... One, I'll use myself as an example. I was a mainframe developer. Now, in some cases, they're highly recruited right now, in some cases, they're highly judged right now, right? But to hold onto your chosen specialization as if that's the thing you're going to do for your entire career, there isn't a developer that's in the same language for their entire career. We know that story's not true, and yet we've got to break those moments where we tell ourselves it's more efficient to do these parts, to cooperate. "I'll do this part because I know the best at this and you do this part."

But the problem is most of the challenges we have, especially in software when we're delivering for customers and for value, it's not the parts, it's the connections. It's the how they work together, it's the flow and the overall experience that that customer is having. And you don't succeed at that with parts, you succeed at it with working together. How that looks for different teams, that's going to vary across the board, but it is breaking that narrative that says efficiency is by parts when efficiency before effectiveness doesn't do anything. I don't care how beautiful your front end if it doesn't actually connect to the backend. It doesn't matter. It doesn't add value. And so I like to highlight to people that we can't worry about efficiency before we've delivered effectiveness. And is it really efficient if it's not effective? So I really try and start breaking down the narratives that we convince ourselves that cooperation's faster and better when it's just not.

Shane Hastie: As a technical leader, as somebody in that position of the possibly newly appointed, how do I create the space for this to happen? How do I enable that in my teams?

Enabling effective teams [12:36]

Tricia Broderick: Again, there's no one checklist. So nobody write down what I'm saying, create a checklist and then pretend that's the checklist. But some of the things that I've done is, I don't try and do it with everybody right out the gate. Some people have different psychological safeties and comfort levels. And so when we were first doing... I remember this a long time ago, but when I was first trying to get the team to start doing some pairing, start doing some basic things, I didn't go, "Okay, everybody, we're going to do pairing tomorrow," Because I would've had a mutiny. It would've been terrifying. And so as a leader, I went, "Okay, do I have somebody that's willing to experiment? Do I have one front end developer, one backend developer that is willing to pair and work on one item for this thing and report out? And here's the extent of the experiment. The experiment is, if I can get two volunteers for three months and then report out what you found at the end of those three months." I didn't need to try and get everybody.

I needed to get two people that were interested, motivated, engaged, willing, who didn't identify with their specialization, but wanting to experiment. And by the end of those three months, they were like, "We want to continue this." But I had other people now interested in what they were doing, and then more people started the experiment. I think, so often, that as leaders, we try to do a flip a switch kind of delivery instead of an experimentation delivery. Even though I was a former developer, I wasn't still coding. Nobody wanted to hear my thoughts about pairing in that moment because I wasn't still coding. They wanted to hear from somebody else. Did I get everybody on that team still interested in pairing by the end of that cycle? No, I still had one that was like, "Absolutely would not," But everybody else was. And that individual had other dynamics that was going on and what they needed in that moment.

But when you try to do everybody at once, you're going to be more focused on the people who don't want to do it than the people who are, and you want to build on the momentum of the people that are, so that's an example of something.

Shane Hastie: You mentioned resilience.

Tricia Broderick: Yes.

Shane Hastie: What do we mean by resilience and why does it matter?

Building resilience [14:35]

Tricia Broderick: Resilience is one of those words. I kind of feel like it's similar to the word courage. When people look at people and just go, "Be courageous." All of a sudden, "Oh, okay, I didn't know. Now I'll be courageous." Resilience has a little bit of that same feel. Like, "Well, just be resilient." It's like, "Oh." And a formal definition is the capacity to withstand or recover quickly from difficulties based on Oxford definition, right? But just looking at somebody and going, "Be resilient," Well, that doesn't mean they actually have built that capacity yet. And so when I look at resiliency, especially in the workplace, especially in a technical workplace, what I'm focused on in building resiliency is building and building off of that experimentation that I don't need my teams to act like they know everything, I don't want my teams to act like they know everything, I want my teams to own that they don't, that it's okay to have unknowns, but that they are confident in their ability to work together to figure out how to move forward, whether that's through experimentation, whether that's inspecting and adapting.

By building that confidence, that's how you're building, then, the capabilities and the resiliency in the teams. But I think so often when we think of resiliency, when people say it, they almost think of grit a little bit in different ways, but for me, it's very specific. It's like, no, you're building the confidence as a leader in them, but of them in themselves to be okay with not knowing everything, but be confident in figuring out how to move forward. And for me, that's resiliency. Because we're in a complex, chaotic world. We don't know what's happening tomorrow. It's not even unknown unknowns, it's like straight up craziness at times. And what resilience is is, I can be in that uncomfortable space of unknowns and know that I can figure out a next step forward. That's really powerful as an individual, as a team, as an organization.

Shane Hastie: In the resilience factors that you talk about, we've spoken about the collaboration. There's two that intrigue me, the conflict resilience and the inclusive collaborations. What's the difference between collaborative connection and inclusive collaboration?

The difference between collaborative connection and inclusive collaboration [16:45]

Tricia Broderick: We very intentionally decided to split these into two. And it could have been really easy to just make them one about collaborating and moving to that and building safety and trust in an environment, but we really wanted to call out inclusivity very specifically. I'll give the story that I gave in the book, or a version of it. I'm an Agilist. I've been in the Agile community for a long time, and in my mind, if you had a seat at the table, you were going to collaborate as an Agilist. And so I spent a lot of time, I never highlighted things, but I would open doors for people and do things and try and make sure people got opportunities. And I do different things because in my mind, just need to get you a seat at the table. That was what it was for me.

And I had a moment where I was at a conference and I was walking around the corner and I heard my name. Now, a mature, healthy adult would've continued walking in and then engaged in the conversation. This unhealthy adult child stopped and listened to what the conversation was because my name is not super common, right? Tricia. Across the board. And basically the question was asked to a colleague of mine, "Is Tricia the token female?" And the response that my colleague gave was amazing, super complimentary. In fact, there were things he said that I was like, "Oh, I don't even agree with that. That's very nice, but no, that's not true." But in that moment, I actually found myself getting mad at my colleague. And I had to stop because I was like, what is going on? Because he's responding in the same ways I've responded anytime someone said, "Oh, why did you put X person on the keynote stage?" Or, "Why is this person a track chair?" Or any other questions I've ever gotten when I've opened doors and things.

And I realized when I sat with it, what I was mad about was because he never said that was an inappropriate question. The reality is, to be inclusive isn't just a seat at the table, it's about creating a space of true belonging, where that weight of always being accused of the token female isn't just on my shoulders, isn't just something that I'm the one that has to deal with that or deal with that weight, but that you are as offended by that question as I am. And I started to realize that to truly be that ally, to truly create inclusive workplaces, there were things that I was taught that were taboo in the workplace that I was wrong about, and that we needed to start being better about being able to have these conversations because without them, these little microaggressions, no matter how nice my colleague was, it's always still back here. Am I the token female because of it, right? And that accumulates and that builds.

That's why they call microaggressions the death by a thousand paper cuts because it's exhausting. And I have such a small experience of it versus so many other people. But when Diane and I were writing this book, we really wanted to take ownership of what we've experienced as women in the tech space, but also that there's so much more than just that. Whatever intersectionality comes into play, that we can't just assume because you're at the table, it's an easy, inclusive collaboration. When I sit down as the only female in a room full of men developers, I have thoughts going through my head. It doesn't matter. It doesn't matter if I'm extroverted, it doesn't matter if I'm confident, I still have thoughts, and to act like those aren't there, it's really difficult for me to perform at my best. And if we want everybody to perform at their best, there was an element of, let's just put it on the table and start talking about what people need so that they can deliver their best, so that they do feel a sense of, I'm not just at this table, but truly being heard and engaged.

And let me be clear, my colleague and everybody, he did care, but it was me, and at the same time Diana, realizing we have to do more and be more resilient about these challenges that we have faced, but so many more people have faced. And it's not enough to just say, "Well, we're working as a team, so it's fine." No. And so we really wanted to call out what kinds of things can happen that make it difficult for inclusivity to truly occur?

Shane Hastie: What about power dynamics?

Dealing with power dynamics [20:44]

Tricia Broderick: This was another. I feel like every part of the book, I'm like, "Oh my gosh, this is another part." I'm going to say something that will not shock Shane in the least bit. I'm an extreme extrovert and when I make connections with people, I'm like, "You can't get rid of me." Shane's laughing right now. I am that person. As I got promoted, as I got in bigger and bigger positions of "power", or what was perceived power, there was formal power that was starting to come into play and there was influential power, the more I became recognized, the more I was accomplishing things. I didn't understand how my power, perceived or real, was impacting the team. I would be like, "I'm just one of the team. Don't worry about... I don't need... You don't have to... This is just my opinion." It's like, no, you're the director of development, it is not just an opinion.

And I really struggled to accept my influential power. And when I say that, let me give an example of, I co-wrote this book with Diana Larsen. It could have been very easy for me to just defer to Diana for the whole book. Like, "Okay. Whatever, Diana." Because Diana could probably look at me and say, "The sky is purple," And I'd just believe her because she has taught me so much. She has influential power. But what Diana refused to do was let me succumb to that influential power. So she had to take actual steps to create a power with so that I wouldn't just defer to her, where she would very intentionally ask my opinion, very intentionally lean into one of my ideas and things like that until we built that momentum, that co intelligence, that me deferring just wasn't an issue anymore. But she very intentionally used what we call power width versus power over to really make sure that her influential power, which wasn't a negative, it was a respect thing, it can be a positive, wasn't impacting our outcome. And I didn't get that as a leader for a really long time.

I didn't understand that people might think I could do more for them or that people thought when I show up and I have what's known as unhappy resting face, that my face was saying something way worse than it really was. I was like, "No, it's just my face." I didn't understand the power that just my role in an organization formally, my influential power or any other of the other types of power could be impacting, and I kept just dismissing it. Like, "No, no, just, we're one of the team." No. Once I'm in a leadership role, I'm not one of the team. And if I don't honor that, that power dynamic can get way out of whack very, very quickly. I'll give a story that happened that helped me realize this a little bit. We were doing this huge government project and if we had too many errors in the document, we would get a financial penalty.

So I would take this document home and I would take a red pen to it and I'd write it all up and I'd bring it back to my team and I'd be like, "Okay, correct all these mistakes." And then the next one I got was even worse than the first one, and I was peeved. I was very, very mad. I was very, very, very mad. And I'd go back and I'd dramatically throw the book down and I was like, "What is this?" And their response was, "We thought you liked doing this." What? I never said that. I didn't have to. I was in a formal position of power. By taking it home the first time, I declared ownership, I declared, this is what I do, and they're not going to question that unless I'm explicit about it, unless I'm clear. And these were the kinds of things that made me go, oh, power does matter. And I can't pretend it doesn't exist. It does. How do I help diminish the negative impacts of it?

Shane Hastie Cycling around to a topic in the book that is close to my heart, the strategy of continuous learning.

A strategy of continuous learning [24:41]

Tricia Broderick: Yeah. We didn't actually put this in the book, but Diana recently said this. She wants to start changing from task work, to knowledge work, to task work, to learning work. And this goes back to what we were talking about before with, you can't know everything, right? Be comfortable in the unknowing and really embrace learning. But we created this section really to call out that everybody says they're a good learner. This is like, "Oh, I'm a good learner." It's like saying, "I'm a good listener." Most of us are not. We're just not. I ended up really realizing a lot of the inhibitors that can happen while you're trying to learn, that will tell yourself a different story that lands you back in that fixed mindset, that lands you back in that, "Just stick with your current specialization. Just don't try new things. Don't experiment."

And so we really wanted, in this section, to highlight not just that you should learn. Because that's the thing, is like, everybody's like, "Yes, be a learner. Have a growth mindset." And then reality can set in and we're like, "But I don't want to fail," And, "It takes a long time." And we have all these inhibitors that will actually make learning and sticking to learning, really, really challenging, where you can get into the shame or feel blame coming into different dynamics. And so when we were highlighting this, we were really highlighting the section to call attention to those inhibitors, but to also say, as a leader, what are you doing to create the right learning environment? Are you creating energy in the environment? Are you making it obvious what people need to do? Are you getting the right setting for learning for the different people? And so we wanted to give tangible techniques and tools to people, not just say, "Be good learners."

Shane Hastie: Some really interesting pointers, some great advice in there, Tricia. If people want to continue the conversation, where do they find you? Where do they find the book?

Tricia Broderick: They can find the book on Amazon, which by the way, that is the way to make a 16-year-old daughter think you're finally cool, is to be on Amazon. Just FYI. That was the I'm a Cool mom moment was that I could be found on Amazon. But you can get to that Barrett Kohler as well, our publisher. I'm best reached on LinkedIn these days, Tricia Broderick on LinkedIn or my website, igniteii.com.

Shane Hastie: Tricia, thank you so much. It's been a pleasure, as always, to catch up.

Tricia Broderick: Likewise. Thank you for having me.

Mentioned

• The book: Lead Without Blame
• Tricia’s website
• Tricia on LinkedIn