Company culture: why it matters in tech more than anywhere else

Picture two software houses: same stack, same tools, same headcount. In one of them a developer receives a requirement that does not hold up and implements it as it is, because that is what the ticket says. In the other, they stop and ask why.

From the outside the two are identical. The software they deliver, two years on, is not.

That difference is called company culture, and it lives somewhere specific: in what happens when no procedure says what to do.

A definition you can actually verify

Company culture usually gets described through its outlines: the benefits, the team building activities, the photos from the Christmas dinner. Pleasant things, and at best symptoms.

Here is a more useful definition, because it can be verified: a company's culture is whatever passes for normal inside it. What passes for normal when a mistake surfaces. What passes for normal to say when a decision taken above you looks wrong. What gets said to a client asking for something that is not in their interest. None of these situations is written in a rulebook, and that is why they say more than any statement of intent.

Why it shows more in software than elsewhere

The claim that culture carries particular weight in tech needs demonstrating, otherwise it is just a compliment we pay ourselves. There is no need to argue that it weighs more than in medicine or aeronautics: it is enough to observe that in software it becomes visible much sooner, for three characteristics of this work.

The same problem often has more than one defensible solution. Which one is worth taking depends on the context, the budget, who will maintain the system. No manual holds that answer, and no procedure either: it takes judgement, so it takes people who have been given permission to use it.

The bill arrives much later. A shortcut taken today does not show today: the code works, the tests pass, the client is happy. It shows eight months later, when a one-day change asks for fifteen. And whoever took the shortcut is usually not the one who pays. If delivery speed is the only thing being measured, technical debt grows on its own, because individually it suits everyone.

Mistakes become public fast. A wrong decision can reach thousands of users within one release. And in that moment the only thing that helps is for the person who suspects they caused it to say so immediately. If saying it has a cost, they will say it twenty minutes later, and those twenty minutes are downtime.

The common thread is that in software the share of work covered by rules is small, and the share left to judgement is enormous. Where procedure ends, culture begins, by elimination.

Culture leaves traces in the code

It stops being an abstract conversation when you open a project and recognise the technical consequences of a culture:

• Where technical discussion feels like an inspection, code reviews become a rubber stamp. People approve so as not to offend, and defects slip through.
• Where asking looks like weakness, an ambiguous requirement gets interpreted instead of clarified. Testing reveals the interpretation was the wrong one, and the work is done twice.
• Where releasing is frightening, releases become rare. But a rare release contains more changes, so it is riskier, so it becomes even more frightening.
• Where knowledge is power, it sits still and every area of the system becomes somebody's property. The jargon calls it bus factor. It equals 1 more often than anyone admits.

The good part is that these traces are visible from outside, without knowing anything about the company. Release frequency, the average size of a change, the time between discovering a problem and reporting it: they say more than any values page, ours included.

Mistakes are the uncomfortable part

Everyone signs up to "we learn from our mistakes". Then the moment it should be applied is always the worst one: system down, client on the phone, and the instinct pushing you to work out who broke what. That instinct is understandable and ineffective. A team where mistakes are charged to people learns one thing and learns it very well, which is how not to stick your neck out. Problems keep happening, they just stop arriving early.

Then there is a second way to get the lesson wrong, more elegant and more common: closing the analysis with a recommendation in place of a change. "Let's be more careful" is the post-mortem equivalent of "let's keep in touch": unverifiable, and it does not survive the first hectic Wednesday. A test that reproduces that bug, a check that blocks the release if the condition returns, an alert that fires before the user does: those hold, because they ask nobody to remember anything.

Which is why we care so much about release automation, from commit to production with no manual steps. An automated process is culture made permanent, the part of the lesson that no longer depends on human memory. It is the same work we do on client projects, under DevOps and infrastructure.

The same goes for knowledge. We have already written about training, how it works here; what gets lost most often is the step after that, which is writing down why a decision was taken. If that reason is recorded nowhere, whoever comes next reads it as a mistake, "fixes" it, and the original problem comes back.

Seven people, five towns

The office is just outside Bologna, but the team works from Modena, from Friuli, from Campania and from Calabria: four out of seven remote. In an organisation like that, some things which elsewhere stay at the level of values become operational requirements.

What is not written does not exist, because a decision taken out loud between two people is invisible to the other five. Autonomy comes with responsibility for what gets decided, because at a distance there is no direct supervision and replacing it is not the point: what matters is that information circulates. And asking for help has to be cheap, because with no desk next to yours an unspoken doubt is one nobody catches in passing. We do not claim it as a virtue, it is a consequence: when you are not in the same room, communication, documentation and the ease of asking for help stop being nice values and become the conditions for working at all.

The questions to ask a supplier

This could read as an internal matter, something for the careers page, and instead it concerns the buyer directly: the client pays for the supplier's culture. A supplier that never questions requirements builds the wrong parts too. One that keeps a problem quiet until it has a solution lets you find out when it is too late to react. One where a single person knows the project hands it over with a constraint that will last for years. Three things that never appear in the quote and that you pay for anyway.

The trouble is that culture cannot be read off a website, because every website says the same things, ours included. It can be surfaced with a few questions, and they are worth asking anyone:

• "Tell me about something that went wrong, and what you changed afterwards." The most revealing one. Someone with nothing to tell has no memory of their own mistakes; someone who describes the mess but cannot say what changed took nothing from it.
• "What do you do if I ask you for something you think is wrong?" If the answer is "the client is always right", you will find the risk out on your own, in production.
• "What happens the day after go-live?" If the answer ends at delivery, the project comes back to you at the exact point where it gets complicated.

These are questions we are happy to answer, not least because on some of them our answer is uncomfortable. Our manifesto says we do not say yes to please people, which translated means some clients have heard us say no. Every principle has a price; without one it would be marketing.

Stacks can be swapped, culture cannot

Even the best technology stack needs the right team, and it is worth saying why. Technologies and tools can be replaced, sometimes at significant cost. A team's culture cannot: it is built over time, through what gets rewarded, tolerated or corrected every day, and no supplier sells it to you.

For us it means that sharing ideas, talking things through, learning from mistakes and growing together are how we make the technical decisions clients pay us to make. We measure the return on one thing only: the projects we have looked after for years can still be changed in reasonable time. On custom software that is the only test that really counts.

If you have a project to talk about, or want to put those questions to us, get in touch. And if it is our way of working that interests you from the inside, our open positions are here.