What Building Good Engineering Culture Actually Looks Like

Every engineering leader can describe the culture they want: psychological safety, ownership, blameless retrospectives, autonomy with alignment, high standards, continuous improvement. The words are easy. Most teams have some version of them.

The harder question is what happens when those values cost you something.

What do you do when production breaks and someone is clearly responsible? When the team challenges your preferred approach? When people need structure but not supervision? When someone is not meeting the bar?

At LYTT, building an engineering team taught me that culture is built in four layers: what leaders model, what systems reinforce, what teams learn to carry without you, and what standards you are willing to protect.

Culture starts with what leaders model

Teams pay attention to what leaders do in difficult moments long before they believe what leaders say in calm ones. One of the clearest examples for me came during a production incident.

We had deployed a new version of a service straight to production, and the deploy step that should have caught the issue had missed it. The liveness check passed, but it was checking whether the container was up rather than whether the software was actually working. The deployment looked healthy, rolled over, and a customer hit the problem before we did.

I joined the call because I was on call. What I remember most clearly is that the engineer involved was already blaming himself before anyone else had said anything. He had braced for it. The rest of the team was watching too, because incidents like that quietly answer an important question: what happens to me when I am the one who breaks something?

I kept the conversation on what had allowed the failure to reach production. A customer had been affected and that mattered, but blaming the person who made the change would not stop the same class of failure happening again. Our deployment verification had a blind spot, so we changed the health check to verify that the software was functioning rather than simply that the container was alive.

That experience shaped how I think about blamelessness. Accountability still matters, but it is most useful when it leads to a change in the system rather than stopping at the person closest to the mistake.

Lower-stakes moments taught the same lesson. In one technical discussion, I pushed for a particular API approach for a downloads feature. The team argued for presigned URLs instead. They were right, and I changed my mind in the room. Once someone senior states a preference too strongly, it is easy for everyone else to start converging around it, so publicly changing my mind mattered more than repeatedly telling people they were free to challenge me.

The same principle applied when the news was simply unpopular. At one point, customer onboarding work landed on engineering because there was no one else positioned to take it on and the business had ranked it above new feature work. I explained why it mattered and acknowledged that much of it would be tedious rather than trying to make it sound more exciting than it was.

Over time, these moments establish what people can expect from you. If incidents become searches for blame, people become cautious about surfacing bad news. If disagreement rarely changes a leader's mind, people stop bothering to disagree. If difficult messages are constantly softened, people eventually stop trusting the version of reality they are being given.

Culture scales through systems

Behaviour matters, but eventually it has to survive without the leader being present in every room. As the team grows, you need mechanisms that make the behaviours you value easier to repeat.

One of the simplest examples was our biweekly tech demo. It started as a space where anyone could show what they were working on, with almost no cost to presenting: no slides, no polished narrative, no expectation of a finished result. I demoed rough proof-of-concepts early on because the team needed to see that unfinished work was genuinely welcome.

Over time, the demos became more polished, as these things often do. What interested me was that the team eventually noticed this themselves and deliberately pulled them back toward informality. At that point the practice no longer depended on me to preserve its original purpose.

We also created an internal technical roadmap because engineers had good ideas for improvements but no legitimate path for those ideas to become prioritised work. The team could raise technical opportunities, discuss them alongside product priorities, and move the strongest ones into the official roadmap.

The pathway had to lead somewhere. If people continually suggest improvements and nothing is ever acted on, the mechanism quickly becomes theatre. We protected enough capacity to deliver some of the work, which made technical direction visible and discussable rather than something handed down from above or fought for through side conversations.

Lightweight architecture decision records served a similar purpose. Writing down a decision and its reasoning changes the shape of later disagreement. Someone revisiting it is no longer arguing with the person who made the call; they can examine the assumptions and trade-offs that were true at the time. It also makes reversing a decision easier when the context changes, because changing direction does not require pretending the original choice was foolish.

Tech demos, roadmaps and decision records are only mechanisms. Their value came from the behaviours they supported: sharing work early, surfacing ideas, exposing trade-offs and making technical direction less dependent on who happened to be in the room.

Culture is proven by what the team carries without you

The harder test comes when people start making decisions you would not have made yourself.

I saw this when I handed two engineers full ownership of building an end-to-end test suite. One was a leader who was still relatively new to the technology; the other was a senior engineer with deep knowledge of the stack. I gave them the outcome rather than prescribing the implementation.

Their first proof of concept used an approach I would not have chosen: generating tests from given-when-then specifications. My instinct was to steer them back towards the shape I would have built, but instead I asked questions. Some tested their thinking and some were because I was genuinely learning the approach as they explained it.

I could see places where the solution might eventually become unwieldy, but it solved the problem and they understood the trade-offs they were making. More importantly, it belonged to them.

If every delegated problem has to converge back to your preferred solution, you have not created ownership. You have created a slower route to your own judgement.

There is an opposite failure mode, though. Sometimes stepping back stops being useful and the right move is to get closer again.

I noticed this with a backend engineer working on latency issues in one of our heavier visualisation endpoints. He had not told me he was stuck, but over several standups the detail had disappeared from how he described the work. With him, that was usually a signal that something was wrong.

When we looked at it together, the problem was not capability. I had given him too many threads at once and the breadth of the work had jammed him. I paired back in for a while, broke the problem into smaller pieces and helped turn it into a sequence he could work through. Once the shape of the problem was manageable again, he delivered something material.

That experience changed how I thought about autonomy. The goal is not maximum distance between the leader and the work. People need enough ownership to exercise judgement and grow, but also enough context and support that difficulty does not quietly become paralysis.

Culture is also what you will not tolerate

Engineering culture is often discussed in terms of trust, autonomy and psychological safety. Those things matter, but they sit alongside standards.

I learned this through a senior contractor who was not performing at the level the team needed. There was genuine context around the situation: the technical direction had shifted after he joined, and the role we now needed was no longer quite the role he had originally been hired for. That was partly on us.

At the same time, the team needed someone at that level to reduce load, and instead the work was creating more of it.

I coached, paired, clarified expectations and set out what improvement needed to look like and over what timeframe. He made a real effort, and I do not want to flatten that part of the story. But the output did not move far enough, and eventually I ended the contract.

That decision mattered culturally as much as the support that came before it. If a team repeatedly compensates for someone working below the expected level while nothing changes, the standard gradually becomes optional. The cost gets absorbed by the people who are meeting it.

The important thing was to keep the decision grounded in observable reality rather than turn it into a judgement about him as a person. What did the role require? What was being delivered? What support had been provided? What had improved, and what had not?

Psychological safety does not require avoiding difficult conclusions. It requires treating people with respect, considering context, giving direct feedback and giving them a fair opportunity to respond. The standard still has to be real.

The culture is in the moments

Looking back, the moments that shaped the team were rarely the ones where we talked explicitly about culture. They were the incident where someone expected blame, the technical disagreement where the team changed my mind, the solution I chose not to override, the engineer who needed more support than I had realised, and the contractor situation where support eventually had to become a decision.

Those moments are harder than writing values because they reveal what the values mean when there is a cost attached.

A useful way to examine an engineering culture is to ask:

• Can people surface failures without becoming afraid to be associated with them?
• Can they challenge senior judgement and genuinely change the outcome?
• Can they show unfinished work without having to perform competence?
• Can they make meaningful decisions without waiting for permission?
• Can they expect support while still knowing that the standard is real?

For me, good engineering culture is built in those layers: what leaders model, what systems reinforce, what teams learn to carry, and what standards you protect. You can shape the conditions for it, but you cannot simply declare it into existence.

The testing is the building.