Crafting Code Podcast

[00:00:15] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about my upcoming two million word journey into the Stormlight Archive.

[00:00:32] Dave Adsit: I'm Dave Adsit, a VP of engineering, and I have been thinking a lot about 3D printing small models and also multi-world epic fantasy novels, unrelated. Our topic for this episode is company culture. So anytime you mention culture, the very first question is that comes up every time is, well, what is culture? And of course, there's the quips that you get, right? Like the, you know, well, culture is who you hire, who you fired, how you work. Great. Now I have more questions. Who should we hire? Who should we fire? And how should we work? Also, why all three of those things?

[00:01:10] Allan Stewart: Yeah. Yeah. A different quote that I like is from Deal and Kennedy, and they call it, your company culture is the way things get done around here. And that to me is a little bit more succinct. It's like, okay. Because it includes those things, right? Hiring, firing, et cetera. But it's like, well, this is the way things happen around here. And even, even just the turn of phrase, this is how we do it around here. Kind of gives you a feel for what it is, because ultimately I feel like culture is kind of the byproduct of all the different people that you have and how they interact with each other within your company.

[00:01:48] Dave Adsit: Right. And so culture is an emergent property of all of the things you've done intentionally. Right. Right. Including. Hiring and firing and putting in place processes that people may or may not follow and putting in place rules and guidelines and whatever. So all of those things together, the things you do create the emergent property of our company culture, which is how things get done around here.

[00:02:14] Allan Stewart: Right. And it can be pretty important, right? Like I know there's definitely fads out in the industry from time to time, especially around startups or startups that are going big. look to be IPO-ing or the last time I big, you know, something IPO-ed and like, what's, what's going to be the next big X. And sometimes they talk about their cultures and, and, and there, and these fads come up around it. But I think that ultimately company culture does matter a lot, but not for the faddish reasons, but because it basically determines whether or not you'll enjoy your job.

[00:02:54] Dave Adsit: That's right. Right. Right. Right. So there's a lot of survivorship bias in the, you know, the latest tech company to do whatever. Right. And people are like, oh, well, that must be the way all of us should work. And I'm like, well, not really. There's a lot of different ways that we can arrange our work and a lot of different cultures that we can create through that. And different cultures are going to be a better or worse fit from, for different people, depending on what it is that you want to do and how you want to work. Right. Right. Right. Right. Right. Right. into and we, so that we can enjoy work. I think we spend too much of our time at work for us to be completely miserable the entire

[00:03:39] Allan Stewart: time. Right. And I think about this and I can easily imagine there's two different developers at two different companies and they're doing basically the exact same kind of work, right? They're, they're getting their Jira tickets. Right. Right. They're both doing web development or mobile development or whatever. But one of them really enjoys their work while the other hates it or lives in fear and anxiety about what is going to happen next. And that the only really pertinent difference, I mean, obviously two different people, they're going to have, you know, different personalities and whatnot. But get two people that are, you know, as close, similar as you can, and they can have this very different experience or even the same person. But, you know, across time, they're going to have a very different experience just because of the culture around the company and how things are set up.

[00:04:38] Dave Adsit: Right. So one of the things that we say when we talk about culture is you often hear, well, your culture should be opinionated. And the question is then, okay, how opinionated should it be? And how do we? How do we enforce those things? Right. So if we have a highly opinionated culture, it's kind of the one of us, one of us, where everybody acts the same, dresses the same, looks the same. Where, you know, despite any attempts at pursuing diversity in your workforce, you really just end up with a whole bunch of people who are kind of sort of copies of one another. They all behave the same way. So if you have that kind of a highly opinionated culture. Then. Certain things become really easy. If it's. Everyone is thinking the same way about problems, then you're going to agree on what the problem is to tackle, what the solution is to do. And you're going to work the same way. Towards that solution. You, your communication becomes easier because people know the same things. They have the same. Methods of thinking the same experiences before and during work, et cetera. If you have a very lightly opinionated culture, then you can end up with. A lot more diversity of. Perspective of experience of thoughts and tools and approaches. And there's a lot of benefits to that as well, right? You will try a lot more things. Um, but you'll also have a lot more conflict. And if you don't, if you have a lightly opinionated culture, but you don't include good strategies for conflict and good practices in your organization for how to handle disagreement, you could have a really bad time. Well, uh, lightly opinionated cultures that I've seen have often. Devolved into like, just. What is the highest paid person's opinion? We're just going to do that because anything else becomes a fight. And that's also not great. So. That's, I mean, that is one of the big questions is like, how opinionated should we make the culture in this organization, in this company, in this department, whatever. And what are the, what are the outcomes. Of having either a highly opinionated or very lightly opinionated. Culture for this group. Yeah.

[00:06:48] Allan Stewart: And I think. Or I don't care about that kind of thinking. And so you just run under a whole bunch of assumptions. Everybody assuming how things should be based on what they see around them, based on sort of the empirical evidence of how people behave rather than anybody questioning things.

[00:07:37] Dave Adsit: Well, and you start to think how much of a culture should be intentionally designed versus accidental or emergent. And I think at the end of the day, your culture will be emergent based on the things you do and the way you behave and the way leaders behave. And again, going back to who you hire, who you fire, who you promote, whatever, how you work will define your culture. But that can be very intentional or very accidental. And again, there are companies where there is an intentional culture and it's good. There's companies where there's an intentional culture. And it's not one I would want to work in. And there's companies where they have an accidental culture that's pleasant to work in or an accidental culture that's awful to work in. And all of these are possibilities. But if we're not designing it, that doesn't mean we don't get one. We still get one. It still emerges from the interactions of the people in the system.

[00:08:33] Allan Stewart: And I think if you try to design it, one of the pitfalls or difficulties that you can find in that is that every time. Yeah. You're working with different people. So excluding situations where a whole bunch of people follow each other from one place to another and you can kind of keep an existing culture. And even then, usually now you're interacting with new people at the boundaries of that group of people. And that changes it. Right. So like it's sort of like the magic in the bottle thing. Like once it escapes, then it's hard to put that back in. You have to create a new different magic. Because your ingredients have changed every single time. And you can't just cargo cult anything because it doesn't work because you don't have those people doing that job in that context. And so you have to kind of it feels like like honestly, it feels like to me a lot of the time you have to start over every time, even if you've done it intentionally before. Because now there's different people and it's different work. You got to try again.

[00:09:42] Dave Adsit: One of the. The engineers on my team said something that really stuck with me as we were making some team changes and I was trying to make changes in a way that would minimize the impact on certain teams. And he's like, well, at the end of the day, every team is immutable. I'm like, I mean, no, we're making some changes. He's like, no, though, like every time we add or remove a person from a team, the team is destroyed and a new team is created. It's like every team is immutable. And it is the sum of the. The people that are on it at the time. So even if you're being very careful about adding people to an existing team, that is now a new team. And some of the some of the things that you do when you're being intentional about culture should be redone. Like you should sit down and redo your team chartering event. Say we're going to we added a new member of the team. We're going to take two hours or four hours in an afternoon and we're going to re charter this team. We're going to keep the. Same mission for the team because that hasn't been changed. We still have the same mission we've been given and we have a lot of ways that we've liked working. But now with a new member, we need to figure out if those ways are still the right ways in the new context. And that I mean, that really stuck with me because that I hadn't really thought about it that way as an engineering leader. A lot of times in leadership, we get used to the idea that we're playing chess with people, right? Like, oh, I put this person with this specific skill set on. Then they'll supplement and compliment the missing skills that they have, but also they'll be able to learn X, Y and Z. You know, we we think we can do that. And at the end of the day, people are too messy and complicated for that to really work.

[00:11:26] Allan Stewart: Yeah, it reminds me of the book Peopleware. In there there's an anecdote about a woman who was on a team and every team that that woman was on was doing exceptionally well. But when they analyze the performance of the people, this particular woman didn't do it. like didn't stand out. I don't think that she was like actively negative in any way, but mediocre. It didn't. Yeah. It's just like, Oh, this is just another person. Like what's the big deal. But because there's all those other interactions that are highly complex, it turned out that whatever she was doing, it was really good. It was magic. It made the whole team perform better. Yeah. Yeah. And so finding, finding it, you know, finding where you should be, I kind of feel like it's one of those like Goldilocks zone things, right? If it's too opinionated, then you get into that echo chamber think tank mindset where, you know, you've got

[00:12:27] Dave Adsit: your blinders. You drive out anybody. Yeah. You drive out anybody who's not exactly like we are. Yeah. It's the whole, it's the political concept of like, well, would I want to have a beer with that politician? Who cares? Do I, I want to call politicians that's competent at the job. Oh, like I need people who are good at a job that I'm not good at there. There's like, yeah, you need to be somewhere in the middle. You don't want to get too far into that highly opinionated echo chamber of is same, same, same all the time. But also you need enough of that, that you can actually be productive and not be like so far out in left field law land that nobody is willing to work together or work in the same way or work in the same direction.

[00:13:04] Allan Stewart: Yes, exactly. And I think of it, it's kind of, it's like the Bermuda triangle. Right. Like sometimes it's hard to find that spot, but there's evidence that it suggests that it exists and there's something magical or dangerous there. I don't know, but, uh, but

[00:13:24] Dave Adsit: it's what you're searching for. Yeah. And so I think you're right. We need to find that Goldilocks zone of close enough to the sun and not too, but not too close, right. Opinionated enough, but not too opinionated. Yeah. Yeah. Loosely opinionate loose enough, but not too loose, um, directed enough, but not too rigid.

[00:13:46] Allan Stewart: Yeah. Don't, uh, don't burn up and also don't freeze.

[00:13:50] Dave Adsit: That's right.

[00:13:50] Allan Stewart: So the other big thing that I think about with company culture is that I have invariably seen subcultures within every, every group that I've worked in, uh, smaller companies have, you know, a smaller subset of this, but smaller companies also, tend to have a lot of opportunity for people to go off. And it's like, oh, well, there's just one or two people that are often doing like an entire department work of worth of work. And so they're their own silo and each silo develops its own culture. Um, and I think that it's important to, at the very least recognize that there will be subcultures within the overall culture, which matters because a lot of time at the company level, especially if it is opinionated, right. If you've got, you know, you're, uh, mission statements and, um, and all your, your company values and, and the, like the clever phrases that are written on the wall and printed out on your swag. I mean, that can be nice. That can be good at times, but that, that represents kind of the desired state for the whole company. And there will be differences and, and engineering has such a specialty, uh, or software development has such a, uh, specialty with, within a business that inevitably it ends up with a new subculture. And even then there are additional subcultures that crop up between like ops and database people and security people and SREs and everybody, right? Because of the different work, the different specialties that they have.

[00:15:32] Dave Adsit: Yeah. So one of the things that you'll find is that every profession has some form of that. The accounting subculture is different from the legal subculture, is different from the engineering subculture. And so when you look at it from that perspective, it's good to have a department or group subculture that can fit within the overall company culture and not conflict. But also you want to have a subculture that supports the specific type of work that you're doing. Yeah. So when I think about company culture, I mean, I've worked in companies that I loved and companies I didn't. And I think that the overall culture of the company is definitely a huge factor in that. Getting more specific, I want to talk a little bit about things that you and I value in a company culture. If you were looking for a new job, which as far as I know, you're not, but if you were, what are some of the things you would look for in a company culture? I mean, I'll start. One of my first ones is I want a company culture of continual improvement. And by that, I mean, no assumption that our first guess is the correct guess and that our current knowledge is sufficient. So I want kind of that Kaizen approach of continual iterative improvement on whatever we're doing. I think when we try to make huge leaps, we often miss. We make a ton of progress if we're doing a little bit of progress all the time. And so I want that to be something that I see in the company. And related to that is being data driven about

[00:17:19] Allan Stewart: whether and how we're improving. Yeah, I like that. One that comes to mind for me is an understanding of the company's goal, which may or may not actually align with the stated goal. You got to have an understanding of the company's Lind Lind Lind Lind Lind Lind Lind Lind Lind product or, um, or there's something else like somebody's kingdom building within, uh, within their culture or, um, or what's really going on is that the company wants to IPO and that's the real goal. And I think having, having clarity on what the real goal is and honesty about that it is the real goal is something that I look for because I want to be able to understand what direction are we going? What is actually going to matter to leadership, et cetera.

[00:18:37] Dave Adsit: If I have to make a decision, I want to make sure that I'm doing decision, making decisions in alignment with the real goal, not the fake goal on the poster. Exactly. Yeah. That makes sense to me. There's a lot, make sure you've got aligned incentives in that case. Um, one of the other things that I look for a lot is a collaborative rather than competitive culture. I want, I want to work in a company that values collaboration between individuals rather than competition amongst them. Um, and we all remember the, we've all heard the stories about Microsoft used to have everybody stack ranked and then every year they'd fire the bottom 10% because those people weren't helping out and they weren't moving things forward anymore. And that drove a lot of really unfortunate. Right. Um, that kind of a competitive environment where I'm being, where I, as a leader, I'm expected to measure my people against each other and, you know, reward the ones who just so hap just happened to be outperforming the others. Uh, it, it re it reminds me a lot of the teachings from Deming around how much we as engineering leaders or as leaders in general are responsible for setting up systems where people can succeed and how much the impact of the system on people is individual outcomes of the people who are contributing become random and almost noise. That again, there are some roles where you very much your outcomes are driven by your personal efforts. I've been told that this is how it is for sales. Uh, and most of the sales orgs that I've seen have a culture aligned around individual incentives and competition in engineering. Uh, one of the classics in, in agile software development is agile software So I've been told that in my book, I talk about how you can't build a complex system on your own, at least not in a timeframe. That's reasonable. Like people do it. It takes years. If you want to go quickly, you have to have a group of people that is aligned around a goal and they should be collaborating. And so for me, one of the things I look for is like, how are we evaluating our staff and what things do we, are we trying to count their lines of their PRs they've generated? This goes back to that, the story you were just telling about, you know, the woman who was mediocre and all of the measurable attributes, but every team that she worked on outperformed the teams around it. She was doing something right. She was some kind of a connector facilitator. She was helping people arrange their work in a way to be effective. I want to arrange work in a way to be effective.

[00:21:15] Allan Stewart: I like that. Another kind of company culture thing that I would look for is a sense of profession. And I think, especially at the company level, a recognition that, you know, we're going to hire people who know how to do their job, that they're going to do it. They're not just going to be slacking off, but then because we have that, but then we like place trust in that. And so, because I don't want to be micromanaged on how I do my job, especially by people who don't know how to write code. And so likewise, I want to extend that courtesy. I don't understand, I don't understand sales from a psychological standpoint. Like it is foreign to me. And I, but I know that there are people who are good at it and I want them to go and do what I can't. And so having that sense of we're working together, everybody is going to behave in a professional way. They're going to do things the way that it ought to be done to the best of their knowledge. And that we're not going to go push each other, push each other around to try and stir up change, especially when we don't understand what it is that we're asking to change.

[00:22:28] Dave Adsit: Yeah. I really like that. I think that that is an important aspect of a culture that I'd want to work in is letting people, you know, hiring professionals who know what they're doing and then letting them have the space to do their job. That kind of goes back to some of the stuff from drive by Dan Pink, the autonomy mastery purpose. Like we've, we hired people who have sufficient mastery of their craft, or their profession or their skill, and then we give them autonomy to do it. And I think one of the things that might be surprising to people who know me is that I don't necessarily look for an organization that has it all together or is operating in a lean way, or has developed a collection of software craftsmen who follow all the practices I enjoy. And I, I don't look for find it very often. And I feel like that's one of the value adds I can bring is that I can teach people around about things like lean product development and I mean, product development practices, engineering practices. And so if I can find something where we're looking for improvement, it doesn't really matter how bad the starting point is because we can make progress from there. If, if people are willing to be competitive or be cooperative instead of competing with against each other and undermining each other and, you know, ruining each other's business, then I think then we can together move towards whatever the goals are, even if the goals are something like we want to hit a hundred million in revenue so that we can IPO. I mean, not that that's a terrible goal. If you're being honest about it, if you say that our goal is to cure cancer and bring world peace, but really all you care about is whether or not you're going to get that a hundred million in ARR so that you can IPO, that is likely to cause friction in your culture.

[00:24:18] Allan Stewart: Right. Yeah. And I like, um, the, the three drive things that you said, right. Autonomy, mastery, purpose, that, that, that is another one that I definitely look for as well.

[00:24:29] Dave Adsit: To me, that's, that one is about recognizing the reality of human psychology. Um, you know, engineers are not, you know, as professionals and thought workers, engineers are not super well, super driven by like, I don't know, uh, a manager handing out gift cards. Here's a $5 gift card. Here's a $10 gift card. That's not going to really, you know, motivate the typical engineer.

[00:24:54] Allan Stewart: Could have bought, you couldn't have bought that pizza on your own. Better, better stay late, better work late so that you can, uh, so you can get pizza.

[00:25:04] Dave Adsit: Let me pay the first $5 of your $8 coffee for you. Thanks, I guess. No, like nobody turns those things down. Right. But they don't really drive a successful engineering subculture, I would say.

[00:25:18] Allan Stewart: Right. Well, and speaking of subcultures then, right. Like, so I think, those things that we talked about there tend to fit very well in a company culture, but recognizing that there is an engineering subculture or, uh, you know, at least, right. We're, we're here talking about crafting code and the adjacencies around coding. What are some of the things that we value in that subculture? And I know one of the ones off the top of my, of my head is around, um, things like there, there, there are, practices that I really enjoy. And so I like to build up cultures around that, um, but not just for the practice, but for the principle behind it. So, uh, test driven development is one of the ones that I really like. And when we were coming up with some ideas for this, uh, I liked that you kind of pulled that back into like this overarching principle of safety, mm-hmm, which includes psychological safety and other like, um,

[00:26:21] Dave Adsit: more like the technical. Technical safety around tests and automation.

[00:26:24] Allan Stewart: Like we can deliver code and it doesn't blow up or hurt people. Exactly. Exactly.

[00:26:29] Dave Adsit: Yeah. It will surprise you greatly to hear that one of the things that I really, really value in an engineering subculture is a culture of continuous improvement and learning. Just like with the whole company. I feel like it turns out engineers as a profession, we're in a... Somebody once told me that we are trying to climb a mountain while we are contributing to the total mass of the mountain. The mountain is growing. We're contributing to its total mass and we're trying to climb it because there's always something new to learn in engineering. And so for me, there's always a way to improve the code base we're in, make it more effective, make it more efficient, make it more focused, write a better method. Whatever the thing is, we can always be improving ourselves. Our code, our delivery, our efficiency, whatever. And so I value that and very much related to and in support of that, I value a culture of continuous learning in engineering.

[00:27:31] Allan Stewart: Yeah. Yeah. And I'd add with that reflection, right? Oftentimes that will show up in practices like retrospectives, but as part of that learning, closing the feedback loop. And saying, hey, we're not just trying new things. We're not just checking whatever the latest and greatest tech that's coming out, right? Like the newest .net or the checking slash dot every day or whatever it was or is that you do. It's not just that, but it's actually saying, okay, well, but how does that change me? How does that change? Like, let's apply the learning and not just be like, oh, hey, we've learned. We've read. We've read 700 blog articles. It's like, okay, but what did you change?

[00:28:22] Dave Adsit: Yeah, I agree with that. What's hot on X right now isn't necessarily what you should be doing at your company in your context. Learn about it. Take the opportunity. But also, I think one of the things that I think is critical for an engineering culture is creating a continuous flow of value. And that, I mean, we could have a whole conversation about what is value. And I'm just going to borrow. I'm going to borrow from one of the recent books I read on software engineering, which is the statement in there is that value is what you want. Like, what do we want? Like, we want to create a website. We want to do, we want to add this feature. We want to do this. We have a new idea. Value is what you want. And I want a regular delivery cadence, a continuous flow of new value through my engineering team. I want, I actually want to work in small batches with regular deploy and limited work in process to make it work. I want to maximize the flow, the continuous flow. I don't want to wait a month or a quarter to deliver something. I want to deliver part of it now, part of it tomorrow, part of it the next day, part of it next week. And I want people to be able to validate that what we're doing is creating value rather than just work. I don't want to have, I don't want to maximize our outputs if those outputs are not actually moving us towards whatever that goal is that we've set. Right. So I want that regular flow of value in my engineering organization. Yeah.

[00:29:48] Allan Stewart: I like that. Related to the professionalism that I like to see up at the company level. I also like to see professionalism or responsibility at an engineering level, particularly. I think depending on different places that people have worked and definitely some historical trends in the industry would have you believe that the person who writes code is not responsible for that code. That feels wrong, kind of fundamentally wrong to me. I want the people who write code to understand, does it work? How does it work? Right. It gets back into our testing and safety again, of course, by doing things like unit testing it. Hey, do you know that it actually works? Do you have high confidence that there's not bugs in it? Do you understand how it operates in production? Like, do you have measurements? Do you monitor it? Can you understand? What's going on? Or did you just slap some code together, threw it over the wall to QA a few times until they stopped saying that it had bugs in it and then threw it over the wall to ops and hope that it works and then wait for the whoever's dealing with customer triage to come and tell you that there was a bug in it. Right. I want to see instead the responsibility of saying, hey, I wrote this code. It works. I know it works. I'm on call. If something's broken, I'm going to fix it. I'm going to own this. I agree.

[00:31:23] Dave Adsit: I think that there's a lot of practices, like you've mentioned, that support the idea of taking responsibility for what we're doing, behaving as professionals and writing code that has high observability. You can measure it. You can monitor it. You can see the logs. You can understand when something's going wrong. That's one of those practices. I think that being on call when your code is running, don't expect ops to be handling your code base. You and your team should be on call on some kind of a rotation. You should own the features that you've built. Do they actually work? First of all, do they do what the customers need? Second of all, are they usable by actual humans? I mean, this is one of the things I was talking about with one of my engineers just today, the concepts behind. Good UX, human-centered user experience design, where these features take into account what people know and how people behave when it comes to software systems. For example, did you use a cheeseburger to indicate there's a hidden menu right here? Or does your cheeseburger mean delete this record? Maybe if your UX is confused. Maybe if your UX is confusing, that's on you as an engineer, right? So, I mean, I think about responsibility as being really important. And as a corollary to responsibility, I think that I want an engineering culture with high safety. You mentioned it already. You mentioned a couple of the things that we do to increase safety, like source control, test-driven development, automation of tests, infrastructure deploys, all of these increase safety. Having retrospectives. Having retrospectives that are a... That actually follow the retrospective prime directive. You know, we assume everybody did the best they could with everything they knew and all the resources they had at the time. You know, start with that. And then have a retro where you focus on what did we do? What can we do better? What are we going to try? Let's do something, right? All of those help increase psychological safety. One of the ones that we do is blameless incident reviews or BIRs. Anytime anything goes wrong in production, we schedule a meeting between... 36 and 40 hours, 48 hours after. So that, first of all, emotions have calmed down. The adrenaline's out of our system. We can think about things, engage that system too, and talk about what happened. Why did it happen? Go deep with your five whys. And then figure out what are we going to do differently going forward so that this particular problem doesn't get us again. You know, there's plenty of others that are waiting their turn. But this one we're going to prevent because we've put in place systems that prevent this. So that's that type of problem. So I think all of those are things that increase psychological safety. And you can do the opposite. As a leader, you can come in and you can storm around and stamp your feet and yell at people when something goes wrong, and you create a certain kind of culture by having those behaviors. So I think those are some of the things that I really look for and value in an engineering culture. Yeah.

[00:34:42] Allan Stewart: I think if we... Yeah. while, we probably could come up with a whole bunch of other things, but let's move on and talk about, um, some of the things that we look out for. Um, at least at the very least, this might be a warning flag, or you might want to just outright avoid a culture that has certain aspects to it. And whether it's your, the subculture that you're in or the, um, or the parent company culture, because I think having something misaligned on either of those can, can be a problem. I've, I've had a lot of fun working in a subculture that I enjoy, but a parent culture that I didn't agree with. And so I'd go and do that again if I had to, but my preference would be for the parent company culture to have a high alignment so that I don't eventually want to quit that culture. And so, um, the first one that I'll put out is something to watch out for is lip service to platitudes. It's really easy for companies, especially when they get interested in company cultures and they start talking about, oh yeah, what do we want to do here? And, and I don't want to sit through long orientations that try to indoctrinate me on all of the, um, five things that. And then I'm going to post it on my post Lind Lind Lind Lind Lind Lind Lind Lind Lind Lind And that it's like, oh, yeah, we believe in this. We spent the time and money to paint it on the wall, but we don't actually base our decisions off of it. So those kind of lip service things just drive me crazy.

[00:36:39] Dave Adsit: I have some thoughts about that related to how cultures evolve. But let's talk about that in a minute. First, I want to say that my number one red flag for any kind of culture thing is when somebody says at Company X, we're not or we're all one big family. No, you're not. And if somebody says that to me in an interview, this interview is basically over because I know that they don't know what a family is, first of all. And they have expectations that are unreasonable for employees. Right. When people say we're one big family in almost every case that I've experienced, that means we want you to work overtime for free. We want you to show up more than is reasonable based on how we're compensating you. Right. Right. Right. Right. Those companies tend to be the ones that don't treat their staff very well in general and have no qualms about firing people over small infractions or small downturns in a market, which is not those are not things you can do when it comes to family. Like at worst, I can ground one of my kids. I haven't figured out a way to fire any of them, nor do I even want to. Right. So for me, that's the biggest red flag is we're a family. No, we're a big family.

[00:37:53] Allan Stewart: And you're expected to listen to your parents and shut up.

[00:37:57] Dave Adsit: Yeah, that's right. Yeah. Which is kind of related to another one on our list, which is a weaponized culture. Right. So in a weaponized culture, when you fire people, you know, we talked about hiring, firing and working, like who you hire, who you fire, who you promote, how you work. Those are all things that help define your culture. In a weaponized culture, people will often cite the cultural values. As a reason why someone was fired. The cultural values painted on the wall that we pay lip service to are generally super vague.

[00:38:32] Allan Stewart: Right. Well, it wouldn't be a very good weapon if it was specific enough.

[00:38:37] Dave Adsit: Yeah. I mean, you wouldn't be able to use it generally if you if it were.

[00:38:41] Allan Stewart: Yeah, you can't you can't bring out the not a culture fit club and hit somebody over the head with it. Yeah. Like, I don't know. Like, I'm more open to the idea of hiring to culture. Trying to find a culture fit when you're hiring because you're looking at somebody you don't know and say, hey, will they fit in with us and and work together well with us? But once you've already have somebody ostensibly went through that process. Now, when you start firing them because they're not a culture fit, feels like something has gone wrong and it's probably not with that employee.

[00:39:17] Dave Adsit: Right. That is definitely a sign that you have either a bad hiring process or a bad training. And onboarding process or something else has gone wrong. But I think you're right. Usually not a culture fit is just a club that's used as an excuse by weak managers to fire somebody without telling them the real reason why. And I would say, while I agree with you that we should be looking for a good culture fit in the hiring process. This is one of the areas to be very careful because it is very easy to hire people. People who are very similar to us. And then you get into one of those very rigid, tight cultures where everybody is kind of the same. Yeah, absolutely. I mean, it's good to say, hey, culture matters to us and we're going to look for it in hiring. We want somebody who's going to contribute to our culture rather than detract from our culture. But I, I will say it's an area to be cautious because if you go too far into that, you're going to find yourself building an echo chamber. And. Likely to the detriment of your overall success.

[00:40:27] Allan Stewart: Yeah, I totally agree. You just have to not ignore it either, because if you completely ignore it, then then it turns out to be not a good hire because you can't actually work together.

[00:40:41] Dave Adsit: Yeah, we all value collaboration. And this guy was a super big condescending jerk and mean to everybody who interviewed him and like, but we hired him anyway because he is different from us. Not necessarily the right way to go. So, you know, speaking of cultures, one of the things to watch out for, it's usually a sign of trouble to come is when you're engineering subculture and your overall company culture are very far out of alignment. Yeah. Which isn't to say that they need to be perfectly aligned. There's a, there was an article in Harvard Business Review years and years ago that I used to pass around. If I can find a link, I'll send it over. But they used to, they talk about the importance of developing skills. You got to have a little bit of skill in your engineering team over trying to align your engineering team to your business goals because higher skilled engineers will deliver on business goals better than low skill engineers that are super aligned. Hm. Hm. Hm. Hm. Hm. Hm. Hm. Hm. Hm. Hm. Hm. Hm. Hm. and stack ranking and performance reviews on a regular basis. And in engineering, you're like, we're all in this together and we're one big team delivering this value together. And we don't know who contributed what, and it doesn't matter because we all contributed together. You might have a bad time. Yeah. Like you're, you're going to have, you're going to create some friction at the very least at the leadership level, but likely across the entire system. Yeah. I think those gaps

[00:42:14] Allan Stewart: become potholes that you fall into because there's different expectations between departments or between parts of the organization, but then also sometimes they go to war with each other, right? Like because cultures, right? Like the, the tribalism of a culture, you, once you start getting into disagreements, because it's not that, not that you're just not aligned, but you're actually like counter aligned. Then, then it becomes difficult because in order, I mean, at the very least you're going to have to decide in order to, you know, you've got mutually exclusive objectives, which one are you going to go for? And oftentimes it's worse than that. And it's, you know, it's just, it can get very

[00:43:04] Dave Adsit: antagonistic. Yeah. Right. Which leads you to having one of the things that I watch out for is the blame driven responsibility or often, I'm typified by the, uh, the phrase I need one throat to choke, right? Whose fault, whose fault is it that X, Y, and Z happened? Who's taking responsibility. I'm going to yell at that person. I'm going to basically choke that person for their bad behavior. Even if they are the leader of a group of 400 people, they are responsible in the worst way, the most negative way for all of the behavior of all 400 of those people. Yeah. Right. So that's when I, I watch out for,

[00:43:44] Allan Stewart: yeah, I feel like one throat to choke is not acceptable generally in society, right? We don't, uh, we don't typically look for stranglers. And surprisingly we say it a lot in, in, uh, business meetings. Yeah. It is likewise not acceptable within business. Correct. Um, there are some worrying practices that will sometimes, they may not be part of the, uh, established culture directly, but it's like the culture of actually how they are working, right? Like it's sometimes it's not the stated thing, but, um, things like people have to spend a lot of time tracking hours. Uh, I worked at one company where, because of the time tracking system was so awful, I would regularly spend an hour every week figuring out my time card. And it was, it was awful. Um, people who work like the expectation that you will, that you will work long hours or work over the weekend, um, or you only deploy at night because you're afraid of what will happen when the deploy happens. Um, I, those are all practices that I think are indicative of a culture that you might want to watch out for.

[00:45:00] Dave Adsit: Right. And there are times when you can go into a company that has a culture like that, where you're, you're fear driven and you're doing off hours deploys. And, and if you're in a leadership role, you can fix it. But if you're in an, an individual contributor role, you're not likely to have a positive impact on that. And so you need to be careful about what kind of a company you go in. And again, these are potential red flags. These are not necessarily red flags. Like all of us should be open to working occasionally late nights or a weekend for some reason, but not as a typical practice on a week after week type of a basis. Right. It leads to burnout and it doesn't create good outcomes and good flow. All right. So we've talked about what we're looking for in a company culture and engineering culture. Um, what things we want to avoid in our engineering culture? How do we build a culture?

[00:45:53] Allan Stewart: Building a culture is difficult because we have to be, I think it's important to be intentional. We, in order to find that Goldilocks zone that we're looking for, we, we actually have to look for it. We have to try, we have to take action. It's, it's not going to just magic. If it did, a lot more companies would be, um, functional instead of dysfunctional. Um, it, it, it, it doesn't happen naturally. You have to actually work at it, but you also have to be careful about how hard you drive on, on certain things because of that record, because what we talked about before, every new situation is different and it's going to be different this time. You can't just take what worked for you in the past and assume that it's going to keep working. Um, and I think, I think there's, there's some interesting things around like the small company struggle of you're working at a startup and there's only 10 people in the whole startup. And there are many, many ways that you could work and they, and a lot of them are viable and you have to choose between a bunch of different viable ways. And then as you grow, I feel like larger companies then run into the situation of there are many non-viable ways that we could work and we have to try to find one that will work. or something else that has happened. And now you need to change up your culture again. You have to find it again.

[00:47:44] Dave Adsit: And we haven't talked a ton about values. You know, like every company I've worked on has their list of values that they selected. But I think that one of the things that has to be part of a values conversation is the fact that values are going to change and evolve based on context as well. And too many companies I've worked at have been resistant to that. You know, you've got the, when you're the very small company, you're like, okay, great. We value, we look at all of our people and we say, these people are being successful. We value the things they're doing. Let's make our company values like that. Well, and it turns out that the things that make a startup productive and effective and successful are very different than the things that make an enterprise company successful perpetually. And you need to value different things at different scales of your organization. And so the small company struggle versus the large company struggle is really important to take into account as you're building and defining a culture. And all of the change management things that we do in engineering all the time apply to changing your culture, developing your culture as well, right? Repetition, repetition, repetition, consistency. What do they say? If you haven't gotten tired of hearing yourself say it, no one else has heard it yet, right? They say you have to say things to your engineering team. Say it. Seven times before they've actually started to hear it. And that's probably just your team of people. I just work in engineering. So I think of it as engineering team. And you're going to have to do a lot of training and retraining. We all come to our job with all of the baggage of our previous jobs. And if we did everything like we had done at previous companies, we get outcomes maybe similar to those previous companies. But at this new place, maybe I've got to be retrained. Maybe I've got to unlearn some bad, bad behavior that I had in the past and learn some new behavior. Like very, very rarely have we gone into a team or a company where people are doing test-driven development, continuous integration, mob programming. Those are practices that I have found valuable and I have to train people how to use them, how to do them, how to apply them on a regular basis, right? So those are some of the things that you're going to do that training and that teaching and re-education. And you're going to do that a lot. You're going to have to repeat that. in order to get people going. I think there's a bunch of specific practices that I've applied on multiple teams in order to get things moving in a good direction. And a lot of them have to do with the things that I specifically value in an engineering culture and an engineering team, right? So I want my teams to be doing daily standups, weekly retrospectives, blameless incident reviews rather than finger-pointing incident reviews. I... As an engineering leader, I always put together an engineering all-hand so that we can align the team once a week, have an ongoing training, have an opportunity for reinforcing the values, the mission, the direction we're going together, give teams an opportunity to share what they're working on and celebrate some of the things that they've gotten done and kind of build that culture around delivery and creation of value. One of the things that... has been super valuable in the teams that you and I have been on together is team playtime. I don't know how many games of Dominion we've played over lunch or just like on a random Thursday afternoon. It's been a lot.

[00:51:19] Allan Stewart: Yeah, it's definitely in the thousands.

[00:51:21] Dave Adsit: It's definitely... We've... Well, I would say that at the very least we have worn out not fewer than three sets of the base cards. Sure. Just because of being handled so much that they're no longer really usable. So that playtime actually helps us to build more connection and collaboration and delivery through shared purpose, shared understanding, breaking down some of those communication barriers. And those are super valuable. I think the other specific practices that are valuable for me is like a weekly peer-to-peer training or learning time. And it's specifically for me peer-to-peer because everybody on our teams knows something that... Everybody else doesn't. And it is... It may be something small. It may be... But it could be something very valuable. So I like to have people teach each other what they know about parts of our system, tools that we're using, et cetera, and build kind of that collaboration. Build that concept of continual improvement through collaboration. Not everything needs to come from the leadership. Right.

[00:52:28] Allan Stewart: And I think as you're doing this, you're trying to build a culture. It can be very difficult to balance the culture building with the work that needs to be done. And it goes into the kind of age-old question, right? It's like, should we write quality software? Is it worth the cost? Well, yes, because it actually makes you go faster. And I think the same is true here, that intentionally building a culture helps you go faster in the long run. But it can be difficult. And I think you have to avoid falling into the trap of doing too much or doing too little based on where you're at. And I think that's where you are in an organization. And so because of that, I really love the practices around experimentation and measuring or reflecting, right? Look and see what's working and use that as a starting point. And then you just go into like, I don't know, I guess maybe that's the context-free practice, right? Our context-free practice for actual code is source control. Your context-free culture practice, is continual improvement or Kaizen, if you prefer, right? Like how are you doing a little bit better now than you were before? And as long as you're always trying to get better and making that an active part of your cadence, then that works, right? So you're trying things out, especially that experimentation aspect of it, where you're saying, I don't know if this will work. This worked for me in the past, or I've heard about it. I've heard about this, or I'm noticing this problem. Let's try some ways and see if it works. See if there's an improvement. And if there's not, well, then let's abandon it because we don't want to just add process for process sake. But if it is working, why is it working? Let's adopt that and have it be part of what we do.

[00:54:27] Dave Adsit: It's the PDSA or PDCA, Plan, Do, Check, Act cycle from Deming and from Lean. We need to try things, reflect on those things, and actually be data-driven in what we do going forward. And I think that culture is something that is built over time. Again, it's an emergent property of all of the things that we've talked about. The overall culture that you have in your department, in your team, in your company comes from the things that you do, the people that you have on the team, how you act, how you behave with one another, how you work, all of these things create the emergent property of culture for your group. And that is what really matters when it comes to how individuals are going to enjoy that work, which I think has to be one of our goals as a leadership group, is creating a system where people can find joy in the work that they are doing.