Fostering Psychological Safety and Building Autonomy for Great Culture

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 Brit Myers. Brit is the VP of engineering with System Initiative. Brit, welcome. Thanks for taking the time to talk to us today.

Brit Myers: Thank you so much for having me, Shane.

Shane Hastie: So the way I like to start these conversations is, who's Brit? Tell me a little bit about your background.

Introductions [01:13]

Brit Myers: Yeah, thanks. As you mentioned, I'm the VP of engineering at System Initiative. I'm a software engineer by trade, though I would say I'm sort of an accidental engineering executive, because I did not have quite a long plan leading up into becoming and entering the tech space, but I'm one of those managers who loves managing engineers. I love managing software engineering teams. I love delivering great products to market, and I'm incredibly relentless that so much of how we are doing things and have done things can be better, and I'm on the pursuit to figure out what those ways are, to invent what I can along the way, and share what I've learned.

Shane Hastie: Cool. So you love management. You love managing people. Many people in the engineering space struggle with having to look after and manage people, so what is it that gave you that frisson?

Brit Myers: Yeah, that's a good question. I say I love managing people, but I love leading, and part of that is because I love seeing the potential in what an individual can do or what a group of people can do. Helping them realize what that thing is, I get a lot of intrinsic value, and that is incredibly motivating for me, so it's this selfish thing to be in management for me, because sort of the wins that you experience and the growth that you can see somebody achieve, it feels great, and so I love doing it.

Shane Hastie: What is a great engineering culture?

Brit Myers: Your engineering culture is great if your engineers believe that it is

I think there's not a single answer. I think I can tell you that a great engineering culture is one that everybody and enough people are willing to say it's great, and so it's sort of like the eye of the beholder a bit with this, in my opinion, and you can imagine I've made many mistakes like this along my career. I might think that a change that I make or a decision that I make is going to improve the engineering culture, when in fact it has the opposite effect, right and so my desire for an amazing engineering culture is separate from the tactics that I take to try to influence what that engineering culture is, but whether or not it actually is great, you have to ask the people, "Do you love your engineering culture? Would you recommend another engineer joining your team or working in this organization?"

I think, if you just ask the people on your teams whether or not they think that your engineering culture is amazing, you'll learn, and if they say no, and I am sort of at the leadership level, asking them, they are right. I'm wrong. It doesn't matter what I think it is. If they don't tell me what I think, and they're sort of, "Ah," if what they think is great, but I think it's horrible, and I make a change that gives them sort of a different reaction, then I'm not doing my job. So it's just a long way to say, your engineering culture is great if your engineers believe that it is.

Shane Hastie: So what are some of the tactics that you've tried in order to improve cultures over your experience?

Tactics and experiments [04:04]

Brit Myers: Oh my gosh. So many. So, so, so many. One of the stories I can share that sort of stands out for me, a number of years ago I stumbled across a blog that was titled, "These are the signs that You're working in a feature factory," and at that time, if I had asked by engineers, "What do you think about our engineering culture?" not all of them felt great about it, and a lot of that was partially due to the sort of back and forth between engineering and product, which is natural, and it's expected to be sort of a compromise and a conversation, and that you're making these decisions together.

One thing that I experienced here was that if there's too much imbalance in the conversation, what you end up with is engineers who believe that they're just taking tickets and just taking tasks, and that you're ultimately not treating them as knowledge workers. So one of the things that I did to try to influence that, and create an environment that was more conducive to what the engineers wanted and what they needed, while still delivering what the business expected, in that case, it was process changes around how we talk about the work. Instead of saying, "Put the button on the bottom left," it's "This is the problem that we need to solve. This is the problem the customer has." One solution might be that the button goes in the bottom left.

The button could also go in the bottom. By sort of changing the conversation that happened, now that back and forth about where the button should be was a more tactical conversation, and you got sort of the strategic, "This is the problem we want to solve, and this is the priority that it is." That was fed in much more clearly by separating sort of the problem that you want to solve in the solution. The result was the team members did no longer felt, or I should say felt less like they were working in a feature factory, because now the conversation of what to build was a conversation that didn't exist before.

Shane Hastie: So bringing some, I want to say, almost autonomy into the conversation.

Brit Myers: Precisely, and to be honest with you, throughout a lot of my career, I think you can sort of generalize what I've done, which is bringing some autonomy to the engineers. What's been interesting is that, at every sort of step that you take towards sort of a more autonomous team, what you have to have in order for that to thrive is alignment alongside, and this is something that, at System Initiative, I'm incredibly proud of, and sort of love how these conversations happen across engineering and product, where to some degree, the old Spotify videos of you cannot have, what is it? High alignment or high autonomy without alignment. Then, everybody's kind of going in different ways, right?

It's true. It is actually true that you can have more autonomy if you have more alignment. The question is, are you willing to put in the work to gain that alignment, and do you have the mechanisms? Do you have the psychological safety to get alignment? And sometimes getting alignment is really messy, and it feels like conflict, when in fact it is conflict, but it's productive and it's conducive conflict, and that is the work. If you're willing to put in the work and to focus on getting alignment across, whether it's across teams or across business domains, across departments at your organization, the outcome of autonomy can have an amazingly positive impact on your engineering culture, but you have to be able to handle both.

Shane Hastie: So if people don't want to work in a feature factory, and the factory metaphor does get in the way, what are some better ways of thinking about the engineering environment, and how do we move towards those?

Moving away from feature factories towards winning collaborative games [07:28]

Brit Myers: An analogy that I've started to use more explicitly lately is, instead of engineers working at a factory, your engineers are athletes on a team, and you're playing a game. The goal is to win the game, and winning the game in that moment might mean getting usage of a new feature at this level in this way. It might be hitting some launch milestone. I mean, what winning is a bit fluid here, but if you think about what is required for a group of people to come together, where they all have different skills, there is no single game that's played the same, and that, I think, is where the factory analogy really breaks down. How many times are you writing the exact same lines of code in the exact same order for the work that you're doing? It's, hopefully, never or maybe a max of three, right? So if you do it once, do it twice, on the third time, maybe you don't ever want to do it again, in which case you're not doing the same thing over and over again.

Where, by using sort of that analogy of these are team members that they're playing together to win a game, they have a shared outcome, they have shared stake in what the outcome is, they have different skills, they have different strengths, they maybe are feeling different ways on certain weeks, or they have different priorities. That mechanism makes it so much easier to sort of describe, how then can I influence the environment so that the team has the greatest chance of winning? As a manager, as a leader, what can I control so that they win the game? Because I'm not out there playing with them. If I was a collegiate athlete, and basketball is my chosen sport, there are some coaches who will yell out calls from the sidelines, and sometimes if a player doesn't run that call at that moment they're getting yanked. They're like, "You didn't do what I said, and so you're not playing."

Other coaches have a different style, where they teach the plays, they give all the tools to the team that they have, and they rely on the point guard or the guards to call the plays and call the shots live, right? So you get into all of the intricacies of how a different coach with a team, a different team member with everybody else, and how those dynamics impact each other, it fits quite well while also holding true the perspective that, as a leader, you're not on the court. You're not on the field. You're on the sidelines, and your goal is to do whatever you can so that they win the game. Knowing how deep you can go is incredibly important. It's humbling in terms of how much power or how much authority somebody actually has, when all I can do is yell out the play, and hope that if they do run it, it works.

Shane Hastie: How do we help those players get better?

Leadership is about helping teams get better [09:57]

Brit Myers: If I stick with the basketball analogy, you have your LeBron, James. You have your top 10 world athletes, but by and large, everybody in the league has some base level amount of skill. Some are higher in some areas, and some are lower in some areas, but it is incredibly dependent what team they're playing on, where they actually need to grow. And so the answer that sort of came to mind was like, "Well, it depends," and it does, because the question is both, how does that player want to grow? How does that engineer want to grow? Where do they see themselves going? Are they somebody who sees themselves coaching someday, or are they going to be a lifer, and they just want to be the best that they can be at the job that they have? That would change, then, how you can help them grow. How do you need them to grow?

So there's conflict or there's tension sometimes, where an organization needs people to grow in this way, but they want to grow in this other way, and what do you do in that situation? Sometimes the right thing to do is to say, "Well, you should find a place where you can grow and where you can be supported, because you're not going to grow in that way here." The most basic examples of, if there's a specific technology stack that you want to use, and that technology stack is not the one that your organization uses, you've got to find other ways to get exposure and to grow in that area, right? It really just depends, but it's a combination of, what is that person's potential, where do they want to go, where do you need them to go, and what does the team need from them? Then, over the course of understanding all of those axes, then ideally, together, you can navigate the conversation, so whether you're setting goals or tuning the feedback that you're giving, assuming that you're giving constant feedback, then the question is how do you know what to tune the feedback to?

Shane Hastie: What about when the organization wants to change direction? You mentioned leading organizations through transformations. How do we make those smoother?

Tackling organisation transformation [11:52]

Brit Myers: I think the only way to make them smoother is to do them more often. If you lean more into the factory example, once you have a factory, assuming the product that you're building is the same, you probably don't really make many changes to that factory, right? But the reality is the product that we're building are changing by the minute, by the second, by the hour. The question I think is less about how do you make it smoother to transition.

I think it's more about how do you encourage, whether you call it continuous improvement, or I don't know if there's another word, but you can call it continuous improvement. How do you account for continuous improvement, and how do you build enough sort of flexibility in your organization so that it can evolve the way it naturally will, as a result of the technology and the work that you're doing evolving? To some degree, the fact that transformation is hard is more a result of how rigid we've made certain aspects of organizations. It's not because change is hard. It's because we made it hard on purpose, so there's just a lot of undoing that you end up having to do as you sort of go on that journey.

Shane Hastie: As a leader, how do I build that ability to change easily into the organization and into the culture?

Brit Myers: I think I have a fundamental belief that the organization will change organically if you let it, and so if your culture, if the environment is not supportive of making changes, that's where it sort of becomes hard. So I guess the answer is, if you can lean more into autonomy, if you can seek that alignment about what types of change are okay, and how do you sort of process them if they need to be processed, then by giving the teams the autonomy to do the work, what you will end up with is this organic changing system.

Shane Hastie: You've used the term "psychological safety" a couple of times. It's become almost a hackneyed phrase. How do we make it real?

Making psychological safety real [13:53]

Brit Myers: I don't know. I don't know that I'm qualified to answer that question, but I can say what I have done to do the most that I can to create some psychological safety, and that is how an organization, how a leader reacts to questions, pushback, or even how a leader navigates conflict, hard conversations, or disagreements. All of those things are opportunities for leader to send signals about, is this the type of conversation that is safe? Is this topic off limits or is it on limits? And so, I focus a lot on managing my own reactions and being intentional about how I communicate so that I'm constantly sending these signals that, "Yeah, I want the questions. I want you to disagree. I want to hear when you disagree. I want to be able to tell you that, even if you disagree, this is what we're doing and we're going to commit to it."

And knowing that you're able to do that, all of those things sort of add up to, I think, what can result in a more psychological safe environment than otherwise. You have to model it in your reactions. You have to model it in conversations. You have to model it even in, for example, skip level conversations, or when the proverbial boss is in the room, are there things that you don't talk about? Because that's a signal about how safe certain types of conversation and certain types of topic are. And so, I think just by being very intentional, and knowing that all of those are signals that influence whether or not somebody's willing or feels safe to confide, safe to disagree, safe to question, all of those things, they all add up. You have to be on, very on, all of the time. When you're not, you own it and say, "Hey, I reacted poorly. That is not what I intended. My reaction was because of this. I love that you asked the question. Please ask that again."

Shane Hastie: So what advice would you have for the new manager leader, somebody who has stepped into a leadership role in that technical space? So I'm an engineer. I've moved into a technical leadership space. How do I do this?

Advice for new technical leaders [15:57]

Brit Myers: So one piece of advice I would have is to give yourself some grace, because this now explicit authority that you have, regardless of how big it is or what sort of context you have around it, the new authority you have, you're going to make mistakes, and it's okay. I feel like I did not hear that enough early. I mean, you hear you're not expected to have all the answers and sort of those types of things, but it's different than saying, "You're going to make mistakes. You're going to learn from them. It's okay." That would be sort of my first advice, is to expect to make mistakes. My second piece of advice is to sort of remember what your role is. One of the things that was pretty easy for me, that I've seen others sort of fall down on is, as an engineer, you are making decisions every single day.

You're defending decisions every single day, to some degree or another, accountable to those decisions every single day, even if it's just to your team, because you're the person who wrote the code. If somebody's going to ask you a question, you're accountable to answering them if you're there. The shift in I, as an engineer, I am individually contributing to what we are trying to do. As a manager, as a leader, it's not about what you personally are doing. It's about what your whole team is doing, so you have to think so much less about the impact of just your behavior and starting to say, "Okay. How can I impact the outcomes of all of these people, whereas before you were very focused on the outcomes that I was producing myself."

That can be a shift, but one of the reasons they can end up incredibly happy, or maybe their team isn't happy is if they're trying to hold onto the idea that you are both individually contributing to something, and contributing through the team or through the people that you're leading. I think the more you lean into and give up that you're individually not contributing, I'm not producing artifacts myself, then the faster you will grow as a leader, because it kind of pushes you more into the leadership space and where you end up spending more time focusing on how you can help others and how you can support others at the cost of how you individually are adding to something.

Shane Hastie: Some really interesting points and good advice in there. If people wanted to continue the conversation, how do they get hold of you?

Brit Myers: You can find me on LinkedIn. Go ahead and search for my name. If you're interested in exploring more how engineering culture is influenced by DevOps culture and how DevOps culture comes to be, we have a Discord at System Initiative. We'd love for you to join and bring all of your questions and ideas there as well.

Shane Hastie: Wonderful. Thank you so much for taking the time to talk to us today.

Brit Myers: Thanks for having me, Shane.

Mentioned

• System Initiative
• Brit Myers on LinkedIn