It’s the Culture, Stupid!
Principles for Leading Software Teams: Part IV
You can’t have a business conversation these days without someone blathering on about the importance of culture (insert obligatory Drucker quote here). Don’t get me wrong, I think culture is important too, but culture has become a “suitcase word”. Everyone is talking about something different when they say culture — many of them very confused notions. My favorite examples are job postings that tout a company’s culture by enumerating perks like table tennis, foosball, and kegerators. What definition of culture does that fit? Eighties frat house? Maybe more importantly, how do you define culture? Have you ever tried to explain it to someone? I think most of us would claim we have an intuitional understanding, but it’s hard to put into words. If you’re trying to be intentional about your culture (because you believe that’s a path to organizational success), doing so without a definition is going to be tough.
The simplest (and I think best) definition I have heard for culture is “the way we do things around here.” If you had a dial to set “the way we do things around here”, that would be a pretty powerful dial wouldn’t it? If you think code reviews are important and you had the magic lever to make everyone as passionate about code reviews as you, wouldn’t that be nice? Or maybe you think vigorous, candid debate is critical to success. Flipping a switch that made everyone not only comfortable but passionate about engaging in that debate would be amazing. It’s really self-evident, isn’t it? Of course “the way we do things around here” is the most important focus for an organization. When looking at it that way, no one should be surprised by Drucker’s claim that “culture eats strategy for breakfast”.
In the absence of culture, we too quickly fall back on making rules and trying to punish people for breaking them. The enforcer of the standards soon gets tired of doing so and wonders, “Why can’t people just follow the rules?” Funny thing about people, they tend to do what they’re going to do; it’s the culture. It’s a wise manager that understands this and rather than decreeing a bunch of behavioral standards tries to figure out how to get people to want to do the right thing — unaware of the rules.
Relatively early in my management career, I found myself leading a quality group that was expanding rapidly through acquisition. Outsiders saw that we had done a great job with quality and figured if they gave me the acquired units, I could do the same with them. Processes and approaches varied widely, so I figured we needed a playbook with hooks and mechanisms in place where I could make sure people were doing the right things. Before doing a release (this was back in the stone age of on-prem software), I imposed a process requirement for teams to gather a big release packet that proved they had done all the right stuff. Before something was released I had to approve it. I’ll never forget the first time I stopped a release because the release packet wasn’t in order. I couldn’t understand why there was a tidal wave of resistance (up and down the entire hierarchy). Afterall, didn’t they understand that I was just trying to do my job? Didn’t they care about quality? I was too naive to understand at the time. Looking back, I now understand that my process was like wet tissue paper trying to stop the semi truck of organizational will. What I needed was a culture of quality where everyone just did the right thing.
Maybe I’ve convinced you that culture is important, tangible, and something more than a fancy coffee bar (or maybe you already understood that); and now you’re asking, “Okay… so what can I do about it?” First, you need to understand what your culture is. Every organization has a culture — good, bad, indifferent. Knowing where you are, you can think about where you want to go. Doing otherwise is akin to trying to get to a destination on a map without knowing your current location. To understand what the current culture is of an organization, I like to use a slightly more academic definition: the behaviors rewarded by the organization and the values that drive those behaviors.
To be clear, “rewarded by the organization” is more than just understanding what the official rewards are in the organization (like referral fees or bug bounties). Rather, it’s about what is rewarded by the entire system — not just the power holders. What do your peers praise you for? What behaviors get called out on Slack? If the entire organization is bought in, no need for rules: it’s just the way we do things around here.
The second part of the definition tries to dive below the surface. If we’re behaving a certain way, what is the underlying reason? If we can get a handle on those values, we’ll have a much deeper understanding of the culture and can therefore better navigate how we might go about changing it.
Lest this post just become a boring instruction manual, I won’t go into step by step details on how to figure out what your culture is. If you’re curious, feel free to contact me. I’m happy to walk through my process. The high level approach I and some of my colleagues have used starts with a one on one conversation with everyone (or a sample of everyone) in the organization. We have a skilled interviewer ask a couple basic questions: what gets rewarded? what gets punished? I say “skilled” because you need someone that is good at prompting and teasing out details. Ideally, the interviewer should be an outsider so that people feel like they can be brutally honest.
In my experience, online surveys won’t suffice. People won’t complete them, and you won’t get the level of detail you need.
After a bit of classifying and counting, you will begin to get a pretty clear picture of your organization’s culture. Be ready to be surprised and disappointed when you discover what your culture is, but whatever you do, don’t shrink from it. Be open about it, warts and all. A company that can speak candidly about what its culture is, even if it isn’t beautiful, will garner a level of respect with its employees.
Once you understand what your culture is, you can start deciding what you want to embrace and what you want to change. Then comes the heavy lifting of implementing ceremonies and habits that try to slowly alter the way people naturally behave and react. Slow is the key word. You’re not going to change it overnight, and you’re definitely not going to change it just by plastering some platitudes on the wall. (That’s likely to just elicit eye rolls). There’s no real recipe book on changing culture, and to be completely honest, I don’t have a magic list of ideas stashed away. As you’ll see, we’ve successfully experimented with a few things; but currently, it feels like each situation will be unique and require extreme creativity. Whatever you do, don’t go it alone. Pull in others to help brainstorm.
When I started at my current gig, one of the first things I wanted to do was a “culture exploration survey” like I’ve just described. I learned a lot. One of the interesting things I discovered was that the organization valued getting things right the first time. Given that it was traditionally an on-prem software company, that’s not necessarily a bad thing. (Remember, culture just is. Forget about it being good or bad). Given that we were trying to become a true SaaS company though, it was critical that we release software quickly — can’t waste time trying to “get it right” up front. Rather, release, learn, adjust. It’s okay not to get it right the first time.
With that, we set out to “fail in front of the customer as quickly as possible” — literally, that’s what we repeatedly said in our all hands meetings. In an effort to shift our culture that direction, we did a number of things beyond just talking about it. We were building a new platform, so we made continuous delivery a high priority. If you make a mistake, correcting it should be a matter of minutes. We also started our Fail Whale ceremony (see this article for a description) in an attempt to make people feel safe with failure.
So how do you know if you’re having an impact? Do the survey again. One year later, we did the same exercise, and among other things we had become an organization that values quick, scrappy delivery of creative solutions with clear customer value even over generalized, ideally engineered software. Seems like a win, right? Definitely, but there’s still work to do. We also learned that we felt safe to fail but sometimes still struggled with second-guessing our peers. Like I said, culture changes happen slowly, but that felt like a big win to me in the span of a year.
The thing about culture is that it becomes self-reinforcing. People are drawn in by a culture, and people are driven away by culture. Explicitly not building “generalized, ideally engineered software” isn’t everyone’s cup of tea. That’s okay. There are places where that absolutely is the culture, which brings us to an important point. Once you have a handle on where your culture is and where it’s going, you can be intentional about it in your interview process. For example, we are an “extreme collaboration” shop, so we have tried to craft questions to help us understand if you’d rather just get assigned your piece of work and come up for air when you’re done. It’s also kind of fun to be able to trot out a very explicit statement when candidates ask, “What’s your culture like?”
Of the software team goals we’re pursuing, intentional culture most directly affects scalability. If you can get your team just doing things the right way, then you need less management and bureaucracy to force right behavior. It just happens. That eliminates the agents that so often lead to diseconomies of scale. The organization grows and everyone just keeps doing the right thing.
Beyond that, culture is really the blank check of organizational goals. What goal do you care about? Innovation? Start working your culture in that direction!
Do you have some interesting examples of organizational culture? Have you been able to successfully shift a culture? I’d love to hear how you did that. Leave a comment.
Curious to Learn More?
Check out Principles for Leading Software Teams: A Guide for related articles and reference materials.
