Why Common Sense Is the Most Underrated Skill in Product Engineering

The industry talks a lot about technical skills. Frameworks, architectures, algorithms. We celebrate complexity as a proxy for capability.

But when I look back at the production incidents I've dealt with, the systems that failed, and the projects that went off track — the cause is almost never the technology.

It's the judgment.

Where Failures Actually Come From

Production issues rarely result from a framework's weakness or an infrastructure gap. They emerge from logic that was hard to reason about. From edge cases that were ignored because they seemed unlikely. From a fix layered on top of a fix, until no one understood what the system was actually doing.

Technology itself rarely fails. Decision-making does.

The root cause is almost always a judgment call that looked reasonable in isolation but compounded into a problem over time. Someone chose a clever abstraction over a clear one. Someone added complexity when the problem didn't warrant it. Someone fixed the symptom instead of the cause.

What Common Sense Looks Like in Practice

It's not mysterious. Common sense in product engineering shows up as:

• Writing code that's easy to reason about — not just working code, but understandable code. The next person who touches it (often future-you) should be able to follow the logic without a map.
• Addressing root causes, not symptoms — when something breaks, the instinct to patch quickly is understandable. The discipline to find the actual cause is what separates sustainable systems from fragile ones.
• Resisting premature optimization — don't optimize for a problem you don't have yet. Build for the problem in front of you, clearly and correctly, and optimize when evidence demands it.
• Designing workflows that make sense to users — intuitive isn't a nice-to-have. When systems are hard to use, people work around them. Workarounds become technical debt.
• Maintaining system coherence over time — every addition should fit the overall design. When it doesn't, that's the moment to refactor, not to carve out an exception.

The Complexity Trap

Complexity is easy to introduce. A clever pattern here, an abstraction layer there, a framework that handles every conceivable case. It feels like progress. It often reads like expertise.

But clarity requires discipline. It means resisting the urge to show what you know. It means choosing boring and predictable over interesting and clever. It means making trade-offs explicit instead of hiding them in implementation details.

Complexity is easy to introduce. Clarity requires discipline.

The best engineers I've worked with bias toward boring solutions. Not because they lack the skill for complex ones — but because they understand the cost. Every clever abstraction is a future maintainability problem. Every framework dependency is a future upgrade burden. Every workaround is a future explanation session.

The Habits That Build Strong Systems

Strong teams don't win on individual brilliance. They win on consistent habits.

Habits like: defaulting to the maintainable option, challenging whether a feature is actually necessary before building it, treating production systems as long-term responsibilities — not just launch targets.

These habits compound. A team that consistently makes sensible decisions builds systems that are easier to understand, cheaper to change, and more reliable under pressure. A team that optimizes for cleverness builds systems that only the original authors can navigate.

Common Sense as Infrastructure

We talk about technical infrastructure — databases, services, pipelines. We rarely talk about judgment infrastructure.

But common sense is infrastructure. It's the underlying layer that determines whether everything else scales. When it's present, teams spend less time firefighting and more time building. Systems become easier to extend. New engineers can contribute quickly. Incidents are contained rather than cascading.

When it's absent, everything is harder. Good infrastructure can't compensate for poor judgment. Neither can great tooling, strong hiring, or aggressive timelines.

Great systems are not built through brilliant breakthroughs. They are built through accumulated sensible decisions — made consistently, over time, by teams that value clarity over complexity and judgment over cleverness.