A recent report on the Dutch public broadcasting system pointed to a pattern that shows up in many environments under pressure: too many people steering, too many interpretations of what “good enough” means, and quality slowly turning into something harder to name with confidence.
That is a media governance story, not a software one.
Still, the pattern is familiar.
In software teams, quality rarely disappears all at once. More often, it becomes blurry. Product has one view. Engineering has another. Support sees a third. A commercial request lands in Slack. A release note promises something optimistic. A roadmap decision gets made on urgency, while the deeper question — what quality are we protecting here? — stays slightly out of frame.
And when that happens, quality can start to feel important and vague at the same time.
Quality gets harder when it stays abstract
Most software leaders do not need to be convinced that quality matters. The harder part is making it discussable in a way that helps a team decide what to do next.
Because “we need better quality” is not yet a decision.
It might mean fewer incidents. It might mean clearer behavior in edge cases. It might mean code that a second team can safely change. It might mean that onboarding a new engineer does not depend on one person’s memory. It might mean that the product behaves consistently enough that support stops having to interpret it on the fly.
All of those are valid. But once they are all bundled together under one big word, the conversation gets slippery.
This is where many teams end up with more opinions than evidence.
One person says the platform is stable enough. Another says it is fragile. Someone points at test coverage. Someone else points at customer complaints. A founder hears frustration in a demo prep. A CTO sees a delivery system that still mostly works. Everyone is speaking honestly, but not always about the same property.
That is often the moment where quality turns into committee language.
Not because the people involved are careless. Usually the opposite. They care enough to all bring their own lens. The problem is that the shared object stays too broad.
A calmer move: shrink quality to one property
There is a more useful way to begin.
Instead of trying to assess “software quality” as a whole, pick one property and make that one small enough to test.
This is where ISO 25010 can be surprisingly practical. Not as a grand program. Not as a maturity performance. Just as a lens.
It gives names to software quality properties that otherwise get mixed together: reliability, maintainability, usability, performance efficiency, functional suitability, and others.
That sounds simple, but the naming matters.
Because once a team says, “Right now we are not discussing quality in general, we are discussing maintainability,” the conversation changes. The scope gets smaller. Ownership becomes easier. Trade-offs become more honest.
The same happens if the property is reliability.
Now the question is not whether the system feels solid. The question becomes: what signal would help us see reliability clearly enough to make one proportionate decision?
Maybe it is incident recurrence in one service. Maybe it is failure behavior around one workflow. Maybe it is how often a release creates operational noise for the same class of problem. Maybe it is support tickets clustered around one fragile path.
None of that solves quality forever.
But it does create a place to stand.
Small proof beats broad theater
A lot of quality work becomes heavier than it needs to be.
A large assessment gets proposed. A dashboard grows. A tool is introduced before the decision is clear. Different teams are asked for input. Weeks pass. People become careful with language. The result may be interesting, but not always actionable.
What tends to work better is smaller proof.
One property. One signal. One decision.
That might look like this:
A team keeps debating whether delivery speed is hurting maintainability. Instead of auditing the whole estate, they choose one code area tied to repeated change friction. They define what would count as a useful maintainability signal there. They look at the evidence. Then they decide whether this deserves investment now, later, or not at all.
Or this:
A product leader keeps hearing “performance is fine” and “performance is becoming a problem” in the same week. Rather than debating perception, the team picks one user-critical flow and turns performance efficiency into a specific observable question.
Or this:
Support notices recurring confusion around one feature. The issue may be usability, or functional suitability, or even reliability presenting itself as confusion. Instead of treating the symptom as general dissatisfaction, the team isolates the quality property they actually need to inspect.
This approach is calmer because it avoids pretending everything must be measured before anything can be improved.
It is also more respectful of how real teams work. People are already making trade-offs every week. The goal is not to create a perfect model of quality. The goal is to create enough shared evidence that the next decision is less subjective.
Shared language reduces hidden drift
One of the quiet advantages of using a quality property as the unit of discussion is that it reduces drift between functions.
Without that shared language, many conversations sound aligned on the surface while pulling in different directions underneath.
A founder may say, “We need this to feel more robust.” An engineer may hear, “reduce incidents.” A designer may hear, “smooth out user confusion.” A commercial lead may hear, “avoid embarrassing demos.”
All reasonable. Not the same.
This is where “too many captains” becomes less about hierarchy and more about interpretation.
In software, misalignment often does not come from conflict. It comes from sincere people using the same word to mean different things.
That is why a small, testable signal matters. It gives the team a shared reference point that is outside personal preference.
Not perfect objectivity. Just enough clarity.
And that clarity tends to improve ownership too.
When quality stays broad, responsibility diffuses. Everyone cares, but no one knows what they specifically own next. When the topic becomes one property in one context, ownership becomes more natural. A team can say: this is ours to observe, this is what we see, and this is the proportionate step we want to take.
That is a much healthier starting point than asking an organization to “take quality more seriously.”
Start with the next useful signal
If quality has been feeling bigger than it needs to be, it may help to resist the urge to solve it in one sweep.
Start smaller.
Pick the software property that creates the most interpretive noise right now. Reliability, maintainability, performance efficiency, functional suitability, usability — whatever is creating the most heat without enough light.
Then ask a modest question:
What is one signal that would help us make a better decision here?
That could be enough to move the conversation from opinion to evidence, and from evidence to ownership.
Not because one signal is the whole story.
Because one signal is often enough to begin responsibly.
If you want to make that concrete in your own context, Pathfinder Signal is a simple route: take one ISO 25010 property, turn it into something testable, and use that to support a proportionate next step.