Engineering Judgement Framework > Execution > Problem Framing
ENGINEERING JUDGEMENT FRAMEWORK
LEVEL 1
|
EXECUTION
Problem Framing
The quality of a solution depends on the quality of the problem.
Good engineering starts with one thing: defining the right problem.
Prefer a video instead of reading? Here it is.
TABLE OF CONTENTS
Start With the Real Problem
Before touching design, architecture, or implementation, the most important question is: What problem am I actually trying to solve?
Not what feature was requested. Not what ticket exists in the backlog. But what real-world problem is the system meant to address, and why it matters.
Getting the problem right before solving it prevents wasted effort and misaligned solutions.
Example
A team receives a request: Add a dashboard to track customer churn. The obvious response is to start designing charts, metrics, and reports.
Building a dashboard would show churn more clearly, but it wouldn’t reduce churn. The real solution might be improving support workflows, speeding up response times, or fixing the root causes of customer complaints.
By starting with the real problem instead of the requested feature, the team avoids building something impressive but ineffective, and focuses on solving what actually matters.
Solving the Right Problem at the Right Level
Every system exists to solve a core problem, the primary reason it was built. To address it, the system is broken down into sub-problems or functions, each with its own goals. These are further divided into smaller components and so on. This creates a hierarchy of parts each with its own specific challenges.
Good engineers understand these problems at multiple levels. You must solve the immediate problem in front of you, but never lose sight of how it fits into the larger goal. Optimizing a small part while harming the overall system is not progress.
Example
Imagine you are building a food delivery platform.
- The core problem is: Help customers get food quickly and reliably.
- One sub-problem is: Assign delivery partners efficiently.
- A smaller part of it might be: Optimize the route for a single delivery partner.
If you focus only on the route optimization, you might design an algorithm that minimizes travel time for one rider, but ignores fairness, rider workload, or ignores overall system efficiency. That could improve a small metric while making the overall system worse.
Clear engineering thinking begins with asking:
- What problem am I solving right now?
- Where does it sit in the larger hierarchy?
- Am I optimizing a part at the cost of the whole?
Avoid Solving Symptoms Instead of Root Causes
Fixing surface problems feels productive. Solving root causes creates lasting impact.
A slow system might need caching, or it might need a fundamental redesign.
Recurring bugs might need patches, or a rethink of architecture, testing, or ownership.
Strong technical judgment means asking:
- What’s causing this, not just what’s breaking?
- If we fix this once, will it stay fixed?
Treating symptoms creates cycles of rework. Addressing root causes reduces future cost and complexity.
Example
A team notices that users frequently report timeouts when uploading files. The quick fix is to increase the timeout limit or retry failed uploads. This reduces complaints temporarily, but the underlying issue remains.
A deeper investigation reveals the real cause:
- The upload service processes files synchronously
- Large files block smaller ones
- The system wasn’t designed for growing file sizes
Instead of repeatedly adjusting timeouts, the team redesigns the upload pipeline. They move processing to background jobs, improve storage handling, and add progress feedback for users.
When you fix symptoms, you reduce noise. When you fix the root-cause, you remove the problem and prevent it from returning.
Clarify Constraints Before Designing Freedom
Every engineering problem exists within constraints:
- Time
- Budget
- Resources
- Regulatory requirements
- Legacy systems
- Organizational priorities
Ignoring constraints leads to elegant but impractical solutions.
Mature problem framing starts with asking:
- What are my boundaries?
- What is flexible?
- What is not?
Constraints are not obstacles to creativity. They shape creativity. When engineers understand constraints early, they avoid proposing solutions that will be rejected later for reasons unrelated to technical quality.
Example
A startup wants to launch a real-time collaboration feature for its document editor.
The ideal solution would involve:
- Persistent socket connections
- Real-time conflict resolution
- Distributed state synchronization
- Horizontal scaling from day one
Technically elegant. Future-proof. Impressive.
But the constraints are clear:
- The team has three engineers.
- The launch deadline is eight weeks.
- The legacy design does not support persistent socket connections.
Moreover, 90% of users collaborate asynchronously, not simultaneously. So, instead of fighting the constraints, the team reframes the problem:
- The goal is not: “build real-time collaboration.”
- The goal is: “allow multiple users to work on the same document without overwriting each other.”
With that clarity, they design a simpler solution:
- Introduce optimistic locking.
- Add visible edit indicators.
- Show version history.
- Notify users of conflicting edits.
- Defer true real-time synchronization to a later phase.
The resultant system isn’t the one they imagined. But it solves the actual user need within the available limitations.
Because the team respected the boundaries — time, people, budget, usage patterns — they built something stable, usable, and aligned with business reality.
Six months later, with more resources and validated demand, they invest in real-time solution.
Their constraints did not limit them, rather they focused them.
Software development doesn’t start with solutions. It starts with defining the right problem. When you take the time to frame problems correctly, you avoid wasted efforts and build systems that really work.
The quality of your solution will never exceed the quality of your problem. Getting the problem right is not a delay. It is the right beginning.
CONTINUE THE JOURNEY
NEXT ARTICLE
Defining Success
Success cannot be achieved if it was never clearly defined.
Continue Reading
Previous
Engineering Judgement Framework
Next
Defining Success
