What is a good engineering culture even?

The DORA 2023 report came out in October, and I’m just catching up with it now. This year’s report subtitle? Culture is everything. And I agree.

I feel like it’s important to note at the outset of this post that DORA is directed at uncovering approaches to software engineering that result in consistent delivery of the most business value. Sometimes when I talk about engineering culture, I feel like many people perceive it as a soft concern. The idea that people vs technology are separate considerations - even mutually exclusive skills - feels so deeply embedded as a belief that if you want to talk about how the two interact, it can be an uphill climb.

Anyway, I’m thinking a lot about these things because I’ve had some recent conversations where other software engineers have insisted to me that the best practices I bring up are mythological - and by best practices I mean things like automated tests, CICD, loosely-coupled architectures, feature flags, or actually practicing a little-a agile development methodology. These are not new concepts. They aren’t rare! They are not the abominable snow monster.

The Abominable Snow Monster Effect

Every once in awhile I’ll see the Dead Sea Effect around technical cultures referenced. The blog where I first came across the term describes large organizations that drive away their best employees with bloated processes and bad management.

But recently I’ve started to wonder about what I’m calling “The Abominable Snow Monster Effect” because it’s December, my kid is really into Rudolph, and I think it captures something about how we can tend to conceptualize culture within engineering orgs.

The Abominable Snow Monster effect describes how a majority of professionals in tech have only ever experienced low-performing cultures, and have grown so doubtful of practices they constantly hear described that they become blockers to moving toward higher performance. Since only a few companies are good at this stuff, they are careful to only hire from other high performing companies. A great deal of talent ends up stuck in low performing organizations because of a self-selective pattern that puts a cap on broader achievement.

The abominable snow monster from Rudolph, raising his arms and baring his teeth

The Mythical Beast

Like the abominable snow monster, whenever you talk about best practices identified by DORA, the agile manifesto, and even dusty engineering management tomes (honestly a lot of this goes back to Fred Brooks and The Mythical Man Month), unless you’re in the right room, someone will eventually guffaw or roll their eyes and say “well yeah, you’re right, we’re not doing that -but no one really does that.”

And I don’t mean just some idealistic perfect implementation. In the last year, I’ve talked with senior engineers who recount being explicitly told they weren’t allowed to write automated tests (and being warned by CTOs for doing so anyway on their own time). I’ve argued about observability with engineering managers who think it’s not worth the time investment to evolve rather than abandon platforms. A colleague questioned my promotion of CICD work, because as he put it “leadership has talked about continuous delivery everywhere I’ve worked in the last 5 years, and I’ve never seen anything come out of it.”

I might also believe that good engineering cultures were the equivalent of mythical beasts; often written about but never encountered in real life. The latest DORA report puts the percentage of organizations clustering in the top-performing categories at 18%. In certain areas, that’s the proportion of white squirrels. Still rare! But hardly mythical.

Fear of the Unknown

If one in five is not that unusual, and the people that work at those places are shouting from the rooftops about how to build high performing engineering cultures, why does change end up such an internal battle?

I feel like the discourse around AI use, another DORA practice identified as highly valuable, pretty clearly articulates the fear that backs that resistance. This article, A Coder Considers the Waning Days of the Craft has been shared all over the place and continues to make me roll my eyes. I actually agree with the conclusion, but it’s a lot of paragraphs dedicated to fear of obsolescence before it lands. Are folks who work with computers no longer going to be valuable in a world with large language models and high interest rates?

As it starts the last paragraph: “So maybe the thing to teach isn’t a skill but a spirit.” If good cultures are comprised of actions that contribute to customer and business success, your valuing of those outcomes is more important than your specific skillsets. And that’s a threatening claim for someone who has invested very heavily in a particular skillset, on the basis of having always preferred to leave strategy and customer-centricity to a separate function.

From DORA however:

Some analysts and technologists hypothesize that AI will make software teams more performant without negatively affecting professional well-being. So far our survey evidence doesn’t support this.

I’m using ChatGPT on a small side project for a family member right now. What is most breathtaking to me about it is how simultaneously incredible and awful it is at the same time. I plan to continue to dabble with AI developer tools, and I expect to continue to feel mixed about their potential. Which makes them a lot less scary. I do expect that over time they will change my approach, and hopefully make some tedious things easier about my job. I look forward to seeing an organization try to replace me with AI because I think that would be hilarious. As my friend Tim will tell you, “don’t be intimidated by AI - help shape it’s future”.

More realistically and candidly though, I also remember being concerned about devops principles and sysadmin work becoming a part of software engineering. I was so intimidated by hardware in grad school I built a computer just to try to get over my distaste for it. Part of the joy of writing code, for me, is how in many ways it loosens the constraints of physical space.

You know what changed my mind? I worked with an awesome lead at Vanco who championed fully automated CICD workflows. We could spin up ephemeral test environments on a handful of servers. Every merge to main deployed into prod. The application we worked on was an archaic monstrosity, but the fast feedback of being able to iterate on it made it’s quirks (the entire thing was Classic ASP JScript) indescribably more tolerable. I’ve since seen the way that the same affordances supercharge development on more modern application platforms. It isn’t that I like hardware more than I used to - it’s that I recognize how these expanding competencies enable me to do more with greater impact of the parts I do love.

Using Engineering Culture to Succeed

In Rudolph, only the abominable snow monster could reach the top of the tree to place the star easily at the conclusion of the film.

enter image description here

Honestly, I kept thinking while watching the film that Yukon Cornelius is an ideal software startup engineering leader.

He wants to make a lot of money, but he’s willing to pivot in response to his context to get there:

Yukon Cornelius: You’re going to stay with me, and we’ll all be rich–with the biggest silver strike this side of Hudson Bay. Sil-verrrrrrr! Hermey: I thought you wanted gold. Yukon Cornelius: I changed my mind.

He hangs out with misfits and sees their talents. He constantly saves others from, and then eventually integrates the Bumble (abominable snow monster) by learning it’s unique traits: it can’t swim! it bounces! It only wants to be helpful and happens to be giant!

Not to mention, he never leaves his friends behind and is absolutely willing to drag their sled with his own hands.

If you wanted more useful, less metaphorical advice out of the end of this blog post, maybe check out DORA, or some of these other great links:

I mostly wrote it because I’m tired of arguing with colleagues about whether we can make anything better or if we’re all just trapped in a dystopian software hellscape where we build immediately discarded widgets online as fast as we can until we die? (I don’t think aiming to have a greater impact is naive, I know it’s eminently possible, please strive for more!)

And by more I mean that the recent DORA report found good documentation supercharges value returned by development. Maybe just fix your docs to start.