What Does Quality Mean in Creative and Technical Work?
[]If you are convening a quality or readiness decision, start with purpose, expectations and binding obligations. Quality is not a decorative label or the amount of effort somebody spent.
A reliable payment system, an expressive game mechanic and a clear strategy document can all be high quality. They are judged against different purposes, risks and audiences, within any legal, contractual, security, safety or accessibility constraints that apply. Calling something “quality” without naming those tests hides the decision that matters.
Quality is contextual, but not meaningless
The original version of this post called quality “entirely subjective”. That went too far.
Some judgements are personal. Players can disagree about whether a game is enjoyable. Readers can prefer different styles. Teams can make legitimate trade-offs between elegance, speed and cost.
Other requirements are observable. The software loses data or it does not. The service meets its response target or it does not. The document answers the decision-maker’s question or it does not. The game crashes under a known condition or it does not.
Quality combines those dimensions. It asks whether the work is fit for its intended purpose and whether it meets the expectations that matter in this context.
Unspoken expectations create avoidable conflict
One person says the work is finished. Another says it lacks quality. Often they are applying different tests that were never made explicit.
A developer may optimise for correctness. A customer may care first about completing a task. An operator may care about diagnosis and recovery. A designer may care about coherence. A finance team may care about control and evidence.
Some perspectives do outrank others: legal, contractual, safety, security and accessibility obligations can establish non-negotiable thresholds. Within those constraints, the team still needs to decide which expectations are essential, which are negotiable and what evidence will show that the result is good enough.
Without that agreement, “improve the quality” is not useful direction. It is an invitation to guess.
More effort is not a definition
I previously argued that high quality meant exceeding expectations, going the extra mile and adding a little more love. That sentiment came from pride in craft, but it can turn discretionary effort into an unlimited obligation.
An extra feature can make a product worse by increasing complexity. Another week of polishing can delay the feedback that would reveal the team is solving the wrong problem. Working late can conceal an unrealistic plan while increasing the chance of mistakes.
Quality does not come from spending more time at a desk. It comes from applying judgement to the outcomes and risks that matter.
That aligns with the broader case for measuring contribution through outcomes rather than attendance. Hours affect capacity, but they do not tell us whether the right thing was built well.
Define quality through dimensions and thresholds
Before work begins, identify the dimensions that matter. For software, these might include:
- functional correctness;
- reliability and recovery;
- security and privacy;
- usability and accessibility;
- maintainability;
- performance;
- cost and delivery time.
Creative work may also need coherence, originality, emotional effect or fidelity to an intended experience.
The list is not the decision. The decision is how much of each dimension this situation requires.
A prototype may accept rough presentation to test whether an idea works. A financial transaction may require strong correctness, auditability and recovery before release. A one-off internal tool and a public platform should not inherit the same quality model merely because the enterprise has one template. Once agreed, those decisions need documentation designed for the people applying them.
Trade-offs should be visible
“High quality everywhere” is not a strategy. Time, money and attention are finite.
If a deadline is fixed, the team may need to reduce scope to protect reliability. If a prototype needs to answer a question quickly, maintainability may temporarily receive less investment. If failure would harm customers, assurance may matter more than speed.
Make those choices explicit. Record what is being protected, what is being accepted and when temporary compromises must be revisited. That is also the question explored in the case for naming value before cutting its supporting numbers.
This lets frontline professionals exercise judgement without silently inventing the organisation’s risk appetite.
The person accountable for the release, decision or service should convene this conversation and record the resulting thresholds. That turns a quality discussion into criteria that a team can apply, review and change when the context changes.
Ask what must be true
A useful quality conversation answers:
- Who will use or depend on this work?
- What outcome do they need?
- What failure would be unacceptable?
- Which expectations are measurable?
- Which judgements require review by an informed person?
- What trade-offs are we making?
- What evidence will allow us to call the work ready?
Quality then becomes something a team can design, test and discuss - not a compliment attached afterwards or a demand to work harder.
Good work should contain care. The organisation’s responsibility is to define where that care matters and provide enough capacity to exercise it, not rely on people donating an undefined amount of extra effort.
