Parag Chitnis

Engineering Judgement Framework > Judgement > Thinking Quality

ENGINEERING JUDGEMENT FRAMEWORK

LEVEL 4

|

JUDGEMENT

Thinking Quality

The quality of your decisions depends on the quality of your thinking.

Strong engineering doesn’t begin with tools. It begins with thinking.

Most technical failures are not caused by lack of intelligence. They are caused by unclear thinking — assumptions treated as facts, guesses treated as strategy, and uncertainty hidden behind confidence.

Engineering judgment begins when you learn to separate:

  • What is verified?
  • What is assumed?
  • What is inferred?
  • What is unknown?

Clarity is a competitive advantage.

TABLE OF CONTENTS

Knowing What You Know

Clear thinking starts with an honest assessment of what you know and don’t know. Not everything we think is true is actually true. Not everything said with confidence is factual.

Mature decision-making means labelling information as:

  • Facts – Verified truths supported by data or direct observation
  • Assumptions – Unvalidated beliefs treated as true
  • Inferences – Conclusions drawn from facts and assumptions
  • Guesses – Plain simple speculation

When you fail to separate these, you build decisions on invisible gaps. And these gaps show up later as rework, delays, escalations, or outages.

The key question isn’t: “Can this system change?”
It is: “How painful will the change be?”

Example

You are troubleshooting performance issues in your system, and someone says:
“The database is the bottleneck.”

It sounds plausible. But what category does that statement belong to? Let’s break it down carefully:

  • Fact: Response time increased from 200ms to 600ms after the last release.
  • Fact: Database CPU usage is at 80% during peak load.
  • Assumption: High CPU means database queries are inefficient.
  • Inference: Optimizing queries will solve the performance issue.
  • Guess: Increasing the database cache size will fix the problem.

Notice what happens when categories blur. If you jump to query optimization or caching without validating the assumption, you may ignore the real issue and the problem will remain unsolved. The real issue might be:

  • A 3x traffic in increase
  • A missing index
  • A new API call that introduced additional load
  • A network latency issue
  • Another downstream service slowing responses

Failing to distinguish between what you know and what you don’t is how teams get blindsided and mistakes narratives for reality.

The Danger of Blended Thinking

Most teams do not explicitly misclassify information. They blend it. Facts, assumptions, and guesses get spoken in the same tone.

For example: “Users don’t care about that feature.”

Is that a fact? Or an assumption based on limited feedback? Or a guess based on personal opinion?

Blended thinking leads to:

  • Overconfidence in weak evidence
  • Premature design decisions
  • Resistance to revisiting earlier conclusions

Strong engineers slow down just enough to ask: “What category does this statement belong to?”

That single question improves decision quality dramatically.

Embrace the Unknowns

Every meaningful engineering decision contains unknowns:

  • Scaling limits
  • Usage patterns
  • Integration complexity
  • Third-party behaviour
  • Performance under stress
  • Cost variations
  • Timeline shifts

The cost of discovering a wrong assumption increases over time. An untested belief in early design becomes technical debt in implementation, an architectural flaw in production, and an outage under load.

Uncertainty should not live in someone’s head.

  • Document it.
  • Track it.
  • Test it.
  • Revisit it as new information emerges.

This reduces surprises later.

Example

Imagine you are designing a new feature expected to serve 10,000 concurrent users. Your star engineer says, “I’m confident it’ll scale fine.” That’s not a fact. That’s uncertainty disguised as confidence.

A mature team would say:

  • We don’t know how the system behaves beyond 2,000 concurrent users.
  • We don’t know the database write behaviour under burst load.
  • We don’t know how the limits of third-party APIs.

Now uncertainty becomes actionable:

  • Run a load test for 15,000 users.
  • Simulate peak database writes.
  • Do a stress-test on external integrations.
  • Build a fallback mechanism.

You haven’t eliminated uncertainty. You have reduced its danger. By testing early, you discover weaknesses when change is still cheap.

Strong engineering isn’t about not having any unknowns. It is about identifying them early enough so that they cannot hurt you later.

Take Decisions Under Uncertainty

Uncertainty is inevitable. Paralysis is optional.

If you wait for perfect information, you will never move forward. Markets shift. Requirements evolve. Dependencies change. At some point, you must decide with incomplete information.

Engineering judgment is not about eliminating uncertainty. It is about structuring decisions so uncertainty cannot cause disproportionate damage.

Instead:

  • Make reversible decisions where possible.
  • Contain the blast radius.
  • Design for course correction.
  • Avoid irreversible commitments too early.

Example

Suppose your team must choose between two architectural approaches:

  1. Adopting a new event-driven system that promises scalability but is unfamiliar to the team.
  2. Extend the existing monolithic architecture, which is stable but less flexible in the long term.

You lack certainty about:

  • Real performance gains
  • Operational overhead
  • Team learning curve
  • Long-term maintenance cost

A weak response is to delay the decision for months waiting for more clarity.

A mature response is to structure the uncertainty:

  • Run a limited pilot for one module using the event-driven approach.
  • Keep the rest of the system stable.
  • Measure operational complexity and performance impact.
  • Ensure rollback is possible if it fails.

Instead of betting the entire system, you make a controlled move. You reduce downside without blocking progress.

Good judgment isn’t about eliminating uncertainty. It’s about making progress in spite of it.

Thinking Quality is a Technical Skill

Clear thinking is often labelled as slow process or soft skill. It is not.

Poor thinking leads to:

  • Misdiagnosed problems
  • Over-engineered solutions
  • Unnecessary rewrites
  • Preventable outages

Clear thinking leads to:

  • Faster root-cause analysis
  • Better design trade-offs
  • Fewer surprises
  • More stable systems

Engineers who consistently separate facts from assumptions:

  • Detect flaws earlier
  • Avoid ego-driven decisions
  • Improve team discussions
  • Earn long-term trust

The quality of your engineering decisions depends on the quality of your thinking. Strong engineers are not defined by how fast they respond, but by how clearly they think before they respond.

Thinking quality is not a soft skill. It is a technical advantage — one that reduces errors, sharpens trade-offs, and improves outcomes under pressure.

It is also not a personality trait. It is a skill — one that can be learnt, practiced, and strengthened.

And as you rise in your career, its importance only increases. Because at higher levels, you are no longer judged by how well you write code — but by how well you think.

CONTINUE THE JOURNEY

NEXT ARTICLE

Engineering Judgement

Judgement begins where certainty ends.

Continue Reading

Previous

Whole-System Thinking

Next

Engineering Judgement