I’ve built engineering organizations from 1 person to 30. Across agencies, DTC brands, and enterprise. Across the US, Serbia, and India.
And the honest answer to “what makes an engineering team work” is that most of what people call engineering culture is theater.
Values on a wall. Retro formats nobody believes in. “Psychological safety” as a buzzword in a leadership offsite while the same three people dominate every architecture decision.
Culture isn’t what you say in the all-hands. It’s what happens when the deadline moves up and nobody’s watching.
I’ve gotten this wrong more times than I’ve gotten it right. But each time I got it wrong, I got it wrong in a more interesting way. And eventually the pattern became clear enough that I stopped trying to design culture and started paying attention to what actually builds it.
I Chased the Stack Instead of the Problem
Early in my career, I was the guy who wanted to rewrite things. Something newer existed. Something faster. Something that would make the architecture cleaner and the developer experience better and the whole team more productive.
I was wrong almost every time.
At Life is Good, I killed a $500K framework migration in my first quarter. The vendor had a slick presentation. Better performance. Modern architecture. Industry momentum. Leadership was ready to approve.
I asked one question: “Can we run the numbers to prove this is the right move?”
We did. The numbers said no. The migration was technically possible and financially stupid. That $500K went toward features that actually moved conversion. The framework migration still hasn’t happened. And doesn’t need to.
When we rebuilt the platform at Converse, I applied that lesson from the start. The first conversation wasn’t about React versus Next versus whatever the internet was arguing about that week. It was “what does the customer actually need from this experience?”
That question changed the entire trajectory of the project. Not because it was profound. Because it gave engineers something to care about beyond the technology.
Engineers don’t burn out because the work is hard. They burn out because they can’t connect the work to anything that matters. I’ve watched talented people leave teams not because the code was bad or the pay was low, but because nobody could tell them why their work mattered to anyone outside the building.
If your team can’t explain why they’re building what they’re building, your culture problem isn’t a ping pong table away from being solved.
The Hire That Changed How I Interview
The stack lesson taught me what to optimize for. The next lesson taught me who to optimize for.
I’ve hired hundreds of engineers. The ones who became the tech leads, the architects, the people everyone wanted on their project … they weren’t the ones with the cleanest code on the take-home test.
They were the ones who asked “why does this feature exist?” before they started building it.
I had an engineer once who was mid-level by every traditional metric. Decent code. Nothing flashy. But in every planning meeting, this person asked questions that made senior engineers uncomfortable. “What happens if nobody uses this?” “Why are we building this instead of fixing the thing that broke last sprint?”
The senior engineers would shift in their seats. Not because the questions were rude. Because they were right. And nobody else was asking them.
Within 18 months that engineer was leading a team. Not because they were the best coder. Because they were the only one interrogating the work before doing it. They brought the same energy I’d learned to bring to technology decisions and applied it to everything. Every feature. Every sprint. Every assumption.
Technical skill is table stakes. Curiosity is the multiplier.
Here’s what I changed after watching that play out. I stopped optimizing interviews for “can this person solve a hard problem.” I started optimizing for “does this person ask why before they start solving.” Because the engineer who asks why will figure out the how. The engineer who only asks how will build the wrong thing brilliantly.
If your interview process doesn’t surface that quality, you’re selecting for competence and hoping curiosity shows up later. It won’t.
The System That Mattered More Than Any Speech
The stack lesson and the hiring lesson were important. But neither of them was the real turning point. The real turning point was understanding that culture follows systems. Not the other way around.
Every engineering leader says “it’s okay to fail.” Almost none of them have built systems where it’s actually true.
You can’t tell your team failure is acceptable while running 6-week release cycles where a bad bet costs a quarter of the roadmap. That’s not permission to fail. That’s a trap. Your team hears the words and then watches what actually happens when someone makes a wrong call. If the answer is “two months of rework and a very uncomfortable meeting with the VP,” they learn the real lesson fast. And the real lesson is: don’t take risks.
Cheap failure requires infrastructure, not slogans.
Ship in days, not months. Feature flags so a wrong bet is a config change, not a rollback. Blameless postmortems where “I was wrong” is a data point, not a career event. Automated rollbacks so the blast radius of a mistake is minutes, not hours.
I’ve run teams where we shipped daily and teams where we shipped monthly. The daily teams weren’t just faster. They were braver. Because a bad decision on Monday was fixable by Tuesday. On the monthly team, a bad decision lived in production for weeks and everyone learned to play it safe.
The daily team had better “culture.” Not because I gave better speeches. Because the system made courage cheap.
That’s when it clicked for me. Culture isn’t something you install on top of your engineering practices. It’s a byproduct of them. If your systems reward caution, you’ll get a cautious culture. If your systems reward experimentation, you’ll get an experimental culture. The speeches are irrelevant. The retros are irrelevant. The values poster in the kitchen is irrelevant.
What matters is what happens when someone makes a mistake. And that’s determined by your systems, not your slogans.
The Moment I Stopped Designing Culture
Everything I’ve described so far was me learning what culture looks like from the outside. What to optimize for. Who to hire. What systems to build.
The real lesson was about what culture looks like from the inside. And it came from a decision that had nothing to do with technology.
I had two people I could have promoted. One of them made me look good. They executed what I asked for, the way I asked for it, on the timeline I committed to. They were reliable, communicative, and easy to manage. Leadership saw them as a reflection of my leadership.
The other one had spent the last year systematically making themselves unnecessary. They’d documented every process they owned. They’d cross-trained two other engineers on their critical systems. They’d built tooling that automated decisions that used to require their judgment. They’d essentially engineered themselves out of their own job.
In doing so, they’d made the entire team more resilient. But from the outside, they looked less essential. Because they’d distributed their value instead of hoarding it.
I promoted the second person.
It was the hardest promotion decision I’ve made. Because the first person deserved recognition too. They were genuinely good at their job. But promoting them would have sent a message: being indispensable is what gets rewarded here. And that message would have shaped the culture more than any value statement or team offsite ever could.
The second person’s promotion sent a different message. Making the team better is what gets rewarded here. Even if it makes you look less important. Even if it means giving away the knowledge that makes you valuable.
Your team watches these decisions. Every single one. They don’t remember what you said in the all-hands about collaboration and knowledge sharing. They remember who you promoted and why.
Culture is built in the moments that don’t make the deck.
What I’m Still Getting Wrong
I want to end this honestly.
I don’t have engineering culture figured out. 15 years in, I’m still learning what works and what I thought worked but didn’t.
I still catch myself optimizing for speed when I should be optimizing for clarity. I still catch myself making decisions that should belong to my team because it’s faster. I still catch myself hiring for competence over curiosity when the deadline pressure is real and I just need someone who can ship.
The difference between now and 10 years ago isn’t that I’ve stopped making mistakes. It’s that I’ve stopped pretending the slide deck is the culture.
Culture is what your team does when you’re not in the room. It’s shaped by the systems you build, the people you hire, and the decisions you make when nobody’s keeping score.
If you want to know what your engineering culture actually is, don’t read the values poster. Watch what happens when someone disagrees with the most senior person in the room. Watch what happens when a project fails. Watch who gets promoted and who gets managed out.
That’s your culture. The rest is performance art.