I've built engineering organizations from 1 person to 30. Across agencies, DTC brands, and enterprise. Across the North America, Europe, and Asia.
And the honest answer to "what makes an engineering team work" is 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.
Here's what I've actually learned.
Your Team Doesn't Care About Your Stack. They Care About the Problem.
Early in my career, I chased every shiny framework. I was the guy who wanted to rewrite things because something newer existed. I've since killed a $500K framework migration because the numbers didn't justify it.
When we rebuilt the platform at Converse, the first conversation wasn't about React versus Next versus whatever the internet was arguing about. It was "what does the customer actually need from this experience?"
The 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 meaningful. 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.
Hire the Person Who Won't Stop Asking Why
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.
Technical skill is table stakes. Curiosity is the multiplier.
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 making senior engineers uncomfortable. "What happens if nobody uses this?" "Why are we building this instead of fixing what broke last sprint?"
Within 18 months they were leading a team. Not because they were the best coder. Because they were the only one interrogating the work before doing it.
If your interview process doesn't surface this quality, you're selecting for competence and hoping curiosity shows up later. It won't.
"It's Okay to Fail" Is Meaningless Without Cheap Failure
Every engineering leader says this. 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. It's not permission to fail. It's a trap.
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.
Culture follows systems. If your systems punish failure, your culture does too. No matter what the slide deck says.
AI Made Craft More Important, Not Less
This is the one going to age well.
Right now, every engineering org is chasing AI-powered velocity. Ship more. Ship faster. Let the models write the boilerplate.
And they should. I use AI daily. My teams use AI daily. We've cut cycle times dramatically.
But here's what happens when you optimize purely for speed without guardrails: five engineers with AI assistants solving the same problem five different ways. All technically working. None fitting your system.
You don't have a codebase. You have a junk drawer with a CI/CD pipeline.
Clean code. Thoughtful APIs. Well-tested systems. Consistent patterns. These aren't luxuries from a slower era. They're the load-bearing walls letting you move fast without the ceiling caving in.
The teams skipping craft for speed are building technical debt at 5x the rate and calling it productivity. They'll figure it out in about six months when every sprint is 40% cleanup.
The Uncomfortable Truth About Engineering Culture
Culture isn't built in offsites. It's not built in Slack channels or retro templates or values workshops.
It's built in the moments no deck captures.
The first time a junior engineer disagrees with you in a meeting and you don't flinch. The first time you kill a project you championed because the data says it's wrong. The first time you promote someone who made your job unnecessary instead of the person who made you look good.
Those moments compound. And your team remembers every single one of them.
I got this wrong for years. I thought culture was something you designed. It's not. It's something you demonstrate. Every day. In the decisions nobody's tracking.
15 years in, I'm still getting parts of it wrong.
But at least I stopped pretending the slide deck was the culture.