Driving Cultural Change Through Software Choices

Here's what most people miss about changing engineering culture: you can't mandate your way there. Leadership can change what they reward and focus on, repeat it enough that people's perspectives shift. But it's slow. And worse, it can backfire—overcorrect for stability and you'll chase away great engineers who think their skills aren't valued anymore.

Camille Fournier has a different lever: product features. Developers have way more power than they imagine to change the engineering culture around them. Especially platform teams. When you build software that others will use or that your peers will work on, are you making it easy for them to do the right thing? That's the question.

She's never met an engineer who didn't occasionally copy-paste-modify code. One of her earliest lessons: when you set up a codebase full of tests, other engineers write tests for their code because there are examples everywhere showing them how. That's the forcing function. Not policy. Not top-down cultural mandates. Just making the right pattern so obvious that copying it is easier than not.

If you build platforms, bake in easy integrations for the software values you want to see. Choosing new tools? Pick ones that support the standards you want taken seriously. Writing code? Make it easy for the next person who will copy-paste what you've done to then do the right thing. This is how cultural change actually happens at the code level—not through heavyweight process enforcement like "your checkin fails if you don't reach X code coverage." You want engineers to value these things enough that they don't need a process.

The power move is recognizing that software choices are cultural choices. Every abstraction, every default, every path of least resistance you create—these shape how people work. Platform teams aren't just building infrastructure. They're building the guardrails that determine what becomes normal.