One Commit at a Time: Incremental Design for Engineering Culture
Culture isn’t a memo.
Every small decision: who you hire, how you handle mistakes, and even what tools you approve, shapes your team.
Here’s how I think about engineering culture, one commit at a time.
As an engineering leader, I’ve learned that culture isn’t defined by a reorg, a values slide, or an all-hands speech. It’s versioned over time, commit by commit, decision by decision.
We all recognize the major inflection points: re-platforming an aging system, overhauling architecture, restructuring teams. But most of what shapes an engineering org happens in smaller, quieter moments.
Hiring is one of those moments.
I’ve consistently involved engineers directly in hiring. Not just to improve outcomes, but to begin building trust before someone even joins the team.
The current team plays an active role at every stage. They help define the process itself, from resume screening to creating and maintaining the take-home project, which I consider essential for evaluating real-world engineering skills.
The take-home exercise isn’t just a filter. It’s a collaborative artifact that gives the team insight into how a candidate approaches problems, communicates decisions, and writes code.
After interviews, we hold a structured decision-making session that includes everyone who interacted with the candidate. The decision is made collectively. It’s not based on a single manager’s instinct. It reflects the input of the people who will work alongside the new hire every day.
Tools matter too.
I invest in the right tools, even if they cost more up front, because time lost to friction and poor developer experience adds up quickly.
There’s a balancing act, of course. You can’t say yes to every tool someone wants to try (front-end engineers, I see you), but you also can’t ignore repeated signals about what’s slowing people down.
The goal is a focused, intentional toolbox. When a new tool is proposed, we evaluate it quickly and honestly. Cost is part of the equation, but rarely the most important one.
If a $5,000 per year tool saves 20 minutes a day across a 30-person team, the ROI is immediate. And that’s before accounting for the morale boost of removing pain points.
Small productivity gains compound quickly. So do signals that leadership is listening.
Happy teams stay. They outperform. And they last longer than the 2.1-year industry average.
We also stay close to the people we build for.
One of the best lessons I’ve ever learned came from a user we worked with at Microsoft. His name was Ned. We called him Angry Ned… affectionately, but honestly.
Ned didn’t sugarcoat anything. His feedback was raw, direct, and sometimes uncomfortable. But it was real. And it was exactly what our team needed.
He helped us see the product from the outside. He reminded us that the things we were proud of didn’t always translate to something useful for the people we were serving.
I didn’t always agree with Ned. But I always listened.
Our users are the reason we build software at all. When you engage with them directly—even when it’s uncomfortable—you build better products and stronger instincts.
We conduct blameless post-mortems.
Our focus is on finding solutions, not assigning blame. Mistakes happen. They’re part of building anything worthwhile.
Repeated issues deserve attention. But punishing someone for a one-time instance of being human doesn’t strengthen the team, it does the opposite.
Psychological safety isn’t optional if you want teams to move fast, speak up, and learn.
We also make time to celebrate.
High-performing teams work hard, and they should have fun together too.
One of my favorite ways to reinforce that has been team go-karting. It’s consistently a hit. It brings out the competitive mindset in a healthy way, encourages laughter, and helps people connect outside of the day-to-day.
And it’s symbolic, too.
When you’re racing, you’re going to bump into each other. That’s part of it. Just like in a high-performing engineering team, friction happens.
What matters is how you respond.
We expect a little bumping. It’s part of working together. And the better we get at handling it without getting defensive, the better we move as a team.
Trust is not something you can declare.
It’s earned through consistency and built incrementally through small decisions made with care.
These things don’t show up in board slides or dashboards. But they shape everything from how fast we move, how well we build, and how long great people stay.
Your culture is built one commit at a time.
What will the next small incremental improvement in your engineering culture be?