Most people think software delivery is a technology problem.
After a decade of working with engineering teams, I’ve learned it rarely is.
The most common blocker isn’t the architecture, the tooling, or the process. It’s the culture: teams that can’t talk honestly about failures, leaders who reward heroics instead of sustainable practices, organisations that measure the wrong things and then wonder why nothing changes.
We spend enormous energy optimising systems. We spend far less intentionally designing the human environment those systems are built in.
That’s what I call culture engineering: applying the same rigour to your human systems that you give to your software systems.
I started Culture Engineers as a home for everything I’ve learned about this. If you’re wrestling with the people and process side of software delivery, I think you’ll find something useful here.
I wrote about this on my blog: https://culture-engineers.nl/blog/2026/07/01/welcome-to-culture-engineers/
Early in my career, I genuinely believed the blockers were mostly technical. Pick the right architecture. Use the right tools. Follow the right process.
Then I kept running into the same pattern: a team would adopt all the right practices and still struggle to ship. The standups happened, the pipelines were green, the retrospectives were scheduled. And yet.
The real friction was always somewhere else. In the conversation nobody wanted to have. In the leader who praised the hero who stayed late instead of the team that made heroics unnecessary. In the metric that measured velocity while ignoring quality.
That’s when I started thinking of culture as an engineering problem, not a soft one. Something you can observe, diagnose, and improve intentionally.
Culture Engineers is the home I’ve built for everything I’ve learned along the way.
I wrote about this on my blog: https://culture-engineers.nl/blog/2026/07/01/welcome-to-culture-engineers/
What’s actually blocking your team from delivering better software?
If you’ve ruled out the tooling, the architecture, and the process, there’s usually one thing left: the environment in which your team does its work. The norms, the incentives, the conversations that don’t happen.
That’s the part most organisations leave to chance.
I’ve spent years working with engineering teams on exactly this. Not the technology side, but the human systems that determine whether good technology gets used well or gets quietly bypassed.
Culture engineering is the practice of shaping that environment intentionally. And it’s harder, more interesting, and more impactful than most technical problems I’ve worked on.
I built Culture Engineers as a space to share what I’ve learned. Blog posts, frameworks, conference talks, and the occasional honest observation about what actually works.
I wrote about this on my blog: https://culture-engineers.nl/blog/2026/07/01/welcome-to-culture-engineers/
Portrait 1024×1536. Abstract editorial illustration: a single figure stands at the intersection of two overlapping systems, one made of geometric circuit patterns (representing technology) and one made of organic flowing lines and human silhouettes (representing culture). The two systems interweave at the centre where the figure stands. Colour palette: deep navy blue background, warm amber and teal accents, clean white lines. Style: architectural diagram meets fine art print. No text, no stock-photo clichés, no handshakes or lightbulbs.
Monday (launch week anchor) — this is an introductory post, best positioned at the start of a week to set context for the audience encountering the site for the first time.