Bad output is almost never a people problem. It's a system nobody designed on purpose.

The reflex when quality drops is to look at the people.

The developer who shipped the broken feature, the product manager whose spec was underspecified, the designer who handed off without the states documented. Someone made a mistake, someone was not good enough, or someone did not care enough.

That is usually the wrong diagnosis.

What do I check first when the same quality problem keeps returning? I look for the point in the workflow where the output became the easiest thing to produce.

People make mistakes, of course, but in most teams the mistakes are not random. They cluster. The same kinds of errors appear repeatedly, from different people, at the same point in the workflow. That is not a people pattern; it is a system pattern.

A system nobody designed on purpose has failure modes nobody anticipated. The spec that is underspecified is not automatically proof that the product manager is bad at writing specs. It may mean the team has no shared definition of what a complete spec looks like, so “complete” becomes whatever felt sufficient on that particular Tuesday.

The feature that ships with the wrong states is not automatically proof that the developer did not care. The handoff may not have included a state map because nobody decided state maps were part of the handoff standard.

The design that gets misimplemented is not automatically proof that the developer cannot read Figma. The Figma file may have captured intent without capturing the logic underneath it, and nobody owns the translation from design intent to buildable specification.

The practical test is simple. Pick the last bug that irritated everyone and walk backward from the screen into the ticket, the handoff, the Figma annotation, the acceptance criteria, and the decision that created the work. Somewhere in that chain, the team usually finds the missing standard.

Maybe the button label changed in design review and never reached the ticket. Maybe the empty state existed in Figma but sat outside the frame the developer opened. Maybe QA caught the issue, but the fix went into Slack instead of the acceptance criteria. None of those moments looks dramatic alone, which is exactly why they keep repeating.

Remove those people and hire new ones. If the system stays the same, the new people will often produce the same class of errors at the same point in the workflow because the system still makes that outcome the most natural one.

The fix is not talent in isolation. It is making the system explicit: what the standard is, who owns what, what “ready” means, and what happens at the points where the current system produces predictable failure.

One structural decision, consistently maintained, can eliminate a whole class of errors.

That is cheaper than replacing people, and usually more honest.