What Good Looks Like in Engineering Culture

I’ve spent over a decade as a software consultant, embedded in engineering teams of all shapes and sizes. Some have been extraordinary. Some have been dysfunctional. Over time, I started noticing that the best ones share a set of emergent behaviours that have little to do with process frameworks or tooling choices, and everything to do with culture.

Here’s what I’ve observed.

Stupid questions are welcome

The best teams actively encourage people to ask questions they think might be obvious. This is harder than it sounds. In many teams, there’s an unspoken pressure to appear competent at all times, which leads to people quietly struggling rather than asking for help. The best cultures flip this — asking a “stupid” question is treated as a sign of intellectual honesty, not weakness.

Failure is socialised

When something goes wrong — a bug hits production, an estimate was wildly off, a design decision turns out to be flawed — the best teams own it collectively. There’s no finger-pointing. The conversation is “what happened and how do we prevent it?” not “who did this?” This requires genuine psychological safety, not just the buzzword version.

Bidirectional trust

A good culture has trust flowing in both directions between the business and the engineering team. Engineers trust that the business won’t throw them under the bus or pile on unreasonable deadlines. The business trusts that engineers are making sound technical decisions and communicating honestly about progress. You need both elements for any team to operate proactively and autonomously, and that bidirectional trust builds confidence over time.

Customer-centricity

The best engineers I’ve worked with think about the end user constantly. They don’t just build what the ticket says — they ask why the ticket exists, who it helps, and whether there’s a better way to solve the underlying problem. This is the difference between a team that ships features and a team that delivers value.

Shallow hierarchies

In the best teams, a junior engineer can challenge a principal’s design decision without it being career-limiting. Ideas win on merit, not seniority. This doesn’t mean there’s no leadership — it means leadership is about enabling, not gatekeeping.

Technical debt is BAU

Every team accumulates technical debt. What separates the good from the bad is whether they treat paying it down as a normal part of the work, or as a special project that never gets prioritised. The best teams fix things as they go, refactor continuously, and don’t need a “tech debt sprint” because they never let it pile up that far.

Good teams don’t have knowledge silos. They pair, they mob, they do show-and-tells, they write things down. Not because a process tells them to, but because they understand that hoarding knowledge makes the whole team fragile. The best engineers I’ve worked with are generous with what they know.