Enhancing Team Dynamics and Psychological Safety in DevOps with Brittany Woods

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ, Engineering Culture Podcast. Today, I'm sitting down with Brittany Woods. Brittany, welcome. Thanks for taking the time to talk to us today.

Brittany Woods: Thank you for having me. I'm excited to be here.

Shane Hastie: My normal starting point for these conversations is who's Brittany?

Introductions [00:40]

Brittany Woods: By way of introduction, I've worked in several industries. Well, I guess I've been in the tech industry, but I've worked across several verticals within it, so retail, finance, the weight industry. So I have sort of a broad experience and understanding across what different companies go through.

I started out as an engineer in the infrastructure space. I did server builds when we were still building servers by hand. And it was from there that I got into automation, and then, automation sort of led me into cloud. And then from being a cloud engineer, I moved into the leadership space. And I've been a leader probably the last four and a half years, leading everything from configuration management, configuration automation, infrastructure as code to development teams, very DevOps-centric teams to not-DevOps-centric teams, you name it.

Shane Hastie: I came across you because of a talk at QCon London, Bits, Bots, and Banter: How Tech Teams Work in a DevOps World. What is different about the way teams work in a DevOps world?

What is different about the way teams work in a DevOps world? [01:56]

Brittany Woods: I think the biggest thing is that the way teams work was obviously changing for years, and teams were adopting more agile mindsets, et cetera. But then, as teams made this shift to DevOps model, they were being asked really to do a lot more than they had done previously. And some companies understood the assignment. Some companies looked at that and said, "You know, we have to enable these teams in a different way than we historically did. We can't just say we want you to do things you didn't do before." But other companies maybe didn't see that part. So the way that they adopted DevOps was different.

And DevOps itself is not really a vague methodology, but it's so broad that companies can adopt it in the way that makes sense for them. And because of that, there's this growing number of organizations that have gotten multiple years on their DevOps journey that are taking a step back and looking and saying, "I have teams that I was expecting to be able to deliver faster and do all of these things because that's what DevOps promised me. Why am I not really seeing this golden path," so to speak, "that was supposed to make itself present?"

And so this talk that I gave at QCon was really about what I've seen work in enabling teams, whether that's development teams that you're now asking to do different things, or whether that's the historical operations teams that handled a lot of the stuff developers are now being asked to do, and how their role changes. So it was about giving insights to that, giving insights to team structure, how you can build psychological safety within these new structured teams, and so on.

Shane Hastie: So let's dig into psychological safety. It's almost a buzzword today. You can't open a culture book, a management book without the importance of psychological safety. But what does it really mean?

What psychological safety means in practice [03:56]

Brittany Woods: I think for me, at least in the positions that I've been in and from the level that I'm at, realistically, psychological safety means that your engineers feel safe to be able to experiment. They feel safe to be able to do the things that you're asking of them without repercussion from either you or the business. And that experimentation is key to being able to deliver innovation and to deliver solutions and things on the edge.

So from my level, it's very tactical psychological safety. I think broadly, though, it's really important, and it's become such a buzzword because, particularly in DevOps, when you're asking teams to do things they didn't historically do, you're asking them to step out of their comfort zone. And realistically, you're asking them to trust. So without trust and without that psychological safety, your teams aren't going to be successful.

So I guess, on the broader level, that's probably what I would say it means to me. And if I were speculating, that's why I feel like it's become so important and such a buzzword because a lot of companies, again, went down this DevOps path with a clear instruction book, but it was just clear enough. And so they're getting to this place where they're like, the landscape is changing, the engineers are changing. How can I enable teams to move forward?

Shane Hastie: So how can we?

Walking the talk around trust and safety [05:24]

Brittany Woods: I mentioned trust is really key to all of that. So as a leader, for me, it's about walking the walk and talking the talk. It's about when I say that I want to build trust with my team, actually building that trust, actually coming to bat for them, I guess, like if there is an issue. We all get sort of bogged down when there's an issue, like making sure to cover for ourselves or cover for our team, it's about more than that. It's about showing the team. When things get hairy because of an experiment that failed or something, I'm willing to come forward and say, "Hey, we were learning. We were doing that thing. This is what we learned from it. This is what we took from it," and move forward without yelling, or getting angry, or somebody getting in trouble, or fired, or whatever the case may be.

So it's about coming to the table for your team. It's about building that trust between you as engineer and a leader, but then also facilitating that trust across the team as well. So making sure that a more junior engineer feels safe to experiment among more senior engineers and that they feel like their contributions are just as valid as that senior engineer's contribution.

So as a leader, that's sort of my perspective at this point. Facilitating that growth for the engineers and facilitating that space for them to be able to build trust with each other. And that sort of lays the foundation for building psychological safety. And then, as you move forward, continuing to show them that there's time to experiment, that there's time to do the right hard thing. That even though we have a deadline, there's space and ability for them to be able to do the things they need to do and to use their engineering backgrounds, and brains, and experience, and all of that to come up with the right solution and not sort of have the right solution for them prescribed before they even start working.

And then, I would say, the other thing is making sure that you share with them and show them that there's always space to learn. So giving them time to learn a new concept or thing, giving them time to explore a piece or an area that they've not explored before. All of these things also build trust, but it builds this environment where engineers feel like they have the space to breathe.

I used to tell my team, use their big brains to come up with a solution to a big problem. And they have the space to take in the information that they need to take in while not being overloaded cognitively, because that's the final point that I'd make. Making sure that, again, as a leader, you're not contributing to cognitive overload, because if a team is being constantly bogged down by multiple things during the day, all at the same time, they're not going to be able to maintain that single thread of thought.

So doing what you can to reduce that cognitive load of having to context switch and all the things that a team may have to do in a day and finding ways that you can either solve for that or finding ways that you can better prioritize and better set the working agreements for your team to make that not the case.

Shane Hastie: Stereotypically, senior engineers are not the most patient people when dealing with more novices. How do we help that senior engineer become more empathic?

Senior engineers need to be mentors [08:57]

Brittany Woods: Yes, that's a really good question. I think, first of all, one of the things that I've always shared with my team is when we talk about their career growth and what direction they want to go, I've always discussed with them that the more senior you become, the more you're looked to as sort of a mentor in that capacity. So sure, you have more experience, and you have more technical solutions under your belt, but you're also looked to help build up those engineers around you and that come after you.

So as you excel as an engineer, that expectation grows. And then you can either decide at this fork in the road, do you want to go into leadership? Do you get value yourself? Does it build you up to be able to build up others, or do you still get a lot of joy and meaning out of solving those hard technical problems? Because the answer to that question will very much show you which direction on that path that you should go.

That being said, though, I think showing them that important part that they play in the careers of the engineers that come after them has helped me in the past. And just making that point of, you may want to be in the technical weeds and that's awesome. But try to take somebody with you, because somebody took you with them. And that's how you were able to get there.

Obviously, all engineers got to where they are, because they have those big brains, and they got to where they are because they can solve the big problems. But there was always a senior engineer that was before them whenever they first started their career, maybe that answered a question for them, or kicked down a door for them, or gave space for them to solve a challenge that built their confidence. So just making that point and trying to get them to understand that it's not without somebody else opening the door, I guess, that you're able to grow. And so try to be that door for somebody else.

Shane Hastie: The unit of value delivery today for most organizations is the team. And you've given us some good advice about psychological safety and trust in a team, but let's dig into what does that team look like and how do they work together today.

Teams need diverse viewpoints and shared goals [11:21]

Brittany Woods: I guess that it kind of depends on the type of team. Historically, you would see teams that comprised of similar experience similar backgrounds, all working toward the same problem and goal. And then, with the influx of DevOps, you saw something similar, but you would often have more DevOps-centered squads. So squads with diversity of thought, diversity of experience, all working toward the same goals, sure, but able to sort of take a different lens to make things.

And then you also had this influx of site reliability engineering teams and platform engineering teams. And so fundamentally, the way they work also changed. So I guess, from the perspective of a platform engineering team, it's all a team with a diverse background. You've got software engineers. You've got infrastructure engineers. You have people that specialize in automation, for example.

But instead of building a thing for them or solving a problem for them, they're now focused on solving problems for others and how they can facilitate others solving those problems in the future. So are they building a platform to enable development teams to build their infrastructure? For example, are they building a platform to enable development teams to visualize their deployments to be able to deploy faster? Maybe, but they're always doing things with another team in mind. How can they do the thing that you historically achieved?

So one of the things I've called this before to my teams is codifying your brain is essentially what a platform engineering team does. They're trying to codify their brain, so other teams are able to leverage it without having to rely on them directly. But then you have the development teams, who, again, are now more than likely made up of a diversity of thought, engineers from different backgrounds. Maybe those engineers used to be a platform engineer because software development is a key facet of that now. Maybe they used to be a tester, so a QA analyst.

Having all of that within the same team and having that expertise allows them to deliver faster. So maybe you have people with development backgrounds that are primarily focused on delivery and code, but then you also have those people with backgrounds and testing that are able to help with driving quality within the code that's being released within that team.

So I think they're all still working the same, and that they're delivering an outcome, but the makeup and the composition of that team has drastically changed in recent years.

Shane Hastie: With that composition shift, what has shifted in the ways of working?

Ways of working need to be clear and explicit [14:04]

Brittany Woods: I think, fundamentally, you have to be more upfront about having these ways of working conversations. Something that I've found really important with my teams is going through and having the conversation and revisiting it frequently on what your expectations as an engineer are for yourself and how you plan to work with the team and other teams around you, but then also what those teams around you should expect from you in return. That can be done for the engineers external to a team and for the engineers within a team.

I think another thing, as you're going through those ways of working conversations, we talked about psychological safety. We talked about trust. That helps to build trust, because it's essentially engineers coming to the table and saying, "This is who I am. This is how it's easiest to work with me. This is my experience. This is the things that I've either built my career on or that I have the most experience with. This is what you can rely on me for."

So you're giving that space for all of the engineers to sort of lay that groundwork for that relationship and set those expectations early so there's no surprises later.

So maybe somebody has a background in software development and is part of a development squad, and then somebody else has a background in QA analysis or something. And so instead of them coming to the table feeling inferior, which sometimes happens within a team because they don't have that same experience, they know that about each other.

And they know I may not have the same code experience as this person, this more senior engineer, but I'm bringing this thing to the table, and they know that. So they may not come to me with questions about it, but they'll be understanding when I come to them with questions about it. So it's sort of just like an expectation level set from the start.

Shane Hastie: And what about the bigger ecosystem, stepping outside of the team and helping our team become more effective in that ecosystem?

Communicating beyond the team into the larger organisation [16:08]

Brittany Woods: I think these ways of working also extends beyond just that makeup of the team as well, and just setting expectations of this is what my team does. This is how we work. This is how we function. This is who we are. And these are the things that you can come to us for and rely on us for. And these are the ways in which you can do that. But also, I think organizationally, it's really important to tie all of these things back to the bigger picture.

So I have a mentor, and one of the things her and I have talked about at length is tying teams to the bigger picture. So that's all of those strategic imperatives, or all of those things that your organization is working toward, showing your team, "This is the part that you're playing in it. This is how these smaller things that we're doing tie back to it."

But then, as you start to get beyond just the team, tying that back to a group. So tying that back to maybe a director. And then they're able to talk to their peers about, like, "This is the piece that we're playing. This is how we work. And this is what you can rely on us for." So they're spreading that message, and then that sort of just spreads on and on and upward and upward. So you're setting those expectations all the way up, but you're also showing this is the value that my team is bringing, and this is what you can rely on us for. So people know this is where you stand.

Shane Hastie: One of the hardest areas for many organizations is getting the metrics right. What are the things that we can realistically measure from our teams?

Finding useful metrics [17:45]

Brittany Woods: I think there's many sets of measurements. So part of my talk that I gave at QCon talked about the different things that you can measure, and it's different with different teams. There's all kinds of metrics that exist and frameworks that exist for measuring DevOps. I guess adoption, for lack of better phrasing.

You've got metrics that you can measure teams on to understand what their productivity is. You've got things that you can measure, like from a community perspective, to measure that the programs, and the things that you're building, and the relationships that you're building across the organization are functional. So I think it just depends on the team.

From a platform team perspective, which is arguably where I've had most of my experience working is within a platform team, I think the most important thing you can measure above anything else is adoption. Because if you're building a thing and nobody's using it, or nobody's adopting it, you've built the wrong thing, or you've built a thing that might have seemed right and might be right still, but you're missing something that would make it valuable for teams to use. So that's the key thing you would measure there.

From a development team perspective, with the teams that I've led and the teams that I've helped support measuring things like build times, measuring things like time to delivery, those things are really important because it shows where you have a bottleneck. It shows where you might be missing a platform or where somebody's having to reach out to somebody else, and something sits in a queue for a week. So understanding where those points of friction are, I think, the most critical metrics.

Then you get into measuring things, like doing team health checks. I talked pretty at length about health checks in my talk. That's another unit of measure. How healthy your team feels from a psychological safety perspective, from a delivery perspective? Are they hitting their goals? And if they're not, why? Are they feeling like they can work together and that they're in a safe environment to do so? And if they're not, why? So understanding all of those things are also important.

Shane Hastie: And how do you create opportunities for people to learn and grow?

Creating opportunities for people to grow [20:01]

Brittany Woods: So I think, first and foremost, it's making space for them. So making space for people that may not try to make space for themselves. So there's that part. There's making space for them to learn.

So as a leader, saying something as simple as I've talked with product and every Friday afternoon is learning. So whatever it is that you feel like you want to brush up on or learn, try to wrap up your things by lunchtime, and then after lunch, come back renewed, and focused on learning a thing. And showing them that you're willing to negotiate on their behalf and give them that space is again important for trust. But that's one way to help promote learning and growing.

There's other things that I've done with my platform teams in the past to make sure that we're not building silos within the team, and that's just having knowledge share sessions, so a weekly knowledge share where you're giving them space to build a new skill, which is presenting to each other, presenting to other engineers, but you're also showing them the value of that mentorship we talked about earlier, showing them the value of teaching the people around them.

But in doing that, you're building the team up, first of all, but you're also making sure that, again, you're not building these tiny little silos within your team where you've got a whole team that's supporting the platform, but only this one person is able to help with this specific question because they're the only person that knows how it works. So being very careful and being very practiced about how you spread your knowledge, I think, is really important too.

Shane Hastie: What's the future direction of teamwork?

The future of teamwork? [21:46]

Brittany Woods: I think that's a really hard one. So when I look at where we were, DevOps was the biggest thing that teams and companies were pursuing to where we are. And you see things like SRE and you see things like platform engineering, I feel like the next iteration of that is just honing where we were, which is DevOps. You'll see blogs, and you'll see things about is DevOps dead and all of that. The argument that I've always tried to make is DevOps was like this umbrella methodology, if you will.

And from that, we got crisper, and we said, "Okay, in order to do these things, in order to follow this methodology, we need to break that down further, and we need to enable these teams." And that's where you started to see SREs and platform engineers come into play.

So I think we'll continue to break that down, and we'll say, "Okay, we've broken down SREs and platform engineers and dev teams into these functions, and this is how they're working. This is how we can make it even better. And this is how we can facilitate those things. That overarching goal that we've been trying for for years."

I don't know necessarily what that looks like. It's all driven by these points of friction, but I think we're just going to continue further breaking that down and further figuring out this is how we get to that nirvana, so to speak, that we've all been trying to achieve for all of these years.

Shane Hastie: And where does generative AI fit in those?

Brittany Woods: There's always the AI question.

Shane Hastie: There's got to be the AI question.

Where does generative AI fit in the future of teamwork? [23:22]

Brittany Woods: There's got to be. I think it's interesting. I've been to a couple conferences now that took their entire agenda and sort of geared it toward AI. And I think the interesting thing is people think of AI as this big, overarching overlord. And it doesn't always have to be that way.

Generative AI and AI in general, but specifically generative AI, it's all about that help task. It's all about those helper things that make my job, and your job, and everybody's job easier. So I think as you start to see companies start adopting things like all of the Microsoft suite of helper tools, the Copilots, every software I think at this point has one. As you start to see engineers adopting those frameworks, I think you'll start to see growth when it comes to engineering quality, more focus on the client and the end-user experience.

I think you'll start to see those things come into play. So it doesn't have to be this big AI-driven world where everything is done automatically. And you, and I, and everybody else doesn't have a job anymore. It can just be these things that are making it easier for me to be an engineer and making it easier for me to test the code that I've just written, like Copilot, can help me do that and help me understand test cases that maybe I, as a human, didn't think about, but it could see because it's processing tons of things.

I mean, I think that's where we are, at least in the short term. I'm not an AI expert by any means, but I think it's just seeing engineers getting used to and embracing things that help make their life easier and help reduce that cognitive load that we talked about earlier, in favor of them using their human brain to be able to develop these solutions because it takes us teaching for AI to be successful.

Shane Hastie: Let's use some really useful points and lots of food for thought here. If people want to continue the conversation, where do they find you?

Brittany Woods: I am on Bluesky, which I don't know if a lot of people have adopted that yet, but that's sort of where I'm at in terms of social media. I'm always on LinkedIn and available to chat. And then I have and maintain just a technical blog/personal page. Any of those areas, you can reach out to me. I'm always happy to have a chat really on anything. I'd love to meet new people.

Shane Hastie: I'll make sure we include those links in the show notes. Brittany, thank you so much for taking time to talk to us today.

Brittany Woods: Thank you for having me.

Mentioned:

• QCon London
• Brittany Woods on LinkedIn
• Brittany Woods' blog