Introduction: Same Task, Different Outcome
Give the same task to two people: "Add a coupon input field to the checkout page." One cleanly adds the field. The other, before starting, asks: "What campaign is this coupon for? Is there a marketing schedule? Is it one type of coupon, or several?"
A few days later, the first person has built one field; the second has built a structure that accounts for the various coupon policies coming soon. The difference came not from ability but from **the depth to which they dug into the context**.
The person who digs into the background of a task looks past the surface request to why the task exists at all. This piece unpacks that "attitude of trying to understand context" into concrete questions and practices.
Surface Request vs. Real Problem
Every request has two layers: the **request** visible on the surface, and the **real problem** lying beneath it. Understanding context is the work of moving between these two layers to find the real problem.
Surface request: "Please add an Excel download button."
|
(why? in what situation?)
v
Real problem: "The team lead spends 2 hours every Friday
manually copying numbers into a report."
-> Better solution: not a download, but automatically
emailing the data already formatted as the report
The person who sees only the surface builds a button; the person who sees the real problem removes two hours every week. Both can say "I did the work," but the value created is incomparable.
> The difference between someone who processes requests and someone who solves problems comes down to whether they ask about context.
Understanding the Business Context
Even technical work ultimately exists to serve some business goal. The person who understands context sees where their work fits into that bigger picture.
Here are useful questions for grasping business context.
[Ask the value chain]
"Which company metric does this feature ultimately move?
(revenue, retention, cost reduction, etc.)"
[Ask about the users]
"Who actually uses this,
and what pain do they face right now?"
[Ask about timing]
"Why are we doing this now?
Is there something more urgent?"
Even writing the same code, someone who knows "this checkout feature is for new-signup conversion" will care more about the user experience when payment fails. Without context, the feature may work but miss its purpose.
Working without business context can yield results that are technically excellent but that no one needs. An elaborately built feature that is never used after launch is more common than you would think.
Grasping Stakeholders and Constraints
Every task has people who affect it or are affected by it — its **stakeholders** — and **constraints** surrounding it. Start without knowing these two, and you end up hearing things like "this needs a security review" after you have already built it.
Here is a table to quickly sort out stakeholders.
| Stakeholder | Question to confirm |
| --- | --- |
| Requester | What outcome do they truly want? |
| End user | How will it actually be used? |
| Adjacent teams | Whose work does it interlock with? |
| Decision maker | Who gives final approval? |
| Operations/support | Who maintains it after launch? |
Grasping constraints is equally important. Constraints are often left out of the first explanation but determine the result.
[Constraints that often hide]
- Deadline: "Actually, we must have it before next week's event."
- Budget: "We cannot use a paid external service."
- Regulation: "If it includes personal data, legal review is mandatory."
- Compatibility: "It must support older browsers too."
- Staffing: "I will have to maintain this alone."
Knowing constraints early lets you design the best solution within them. Knowing them late means tearing down what you already built.
Asking "Why This, Why Now?"
Among context questions, the single most powerful phrase is "Why are we doing this now?" This question pulls out several layers of information at once: urgency, priority, and often the real motive that was hidden.
What "Why this, why now?" pulls out:
- Urgency: what happens if we do not do it now?
- Priority: why this before other work?
- Trigger: what set off this request?
(a customer complaint? a competitor launch? an internal incident?)
For example, suppose a request suddenly arrives to "redesign the login screen." Ask "why now?" and the real background may surface: "data shows 30 percent of new signups drop off at the login step." Knowing this background shifts the focus from a mere cosmetic improvement to reducing the drop-off point.
Of course, tone matters with this question. If it sounds like "why on earth now?", it provokes defensiveness. Pairing it with the intent — "I think I can build it better if I understand the background of this" — turns it into a collaborative conversation.
The Waste of Context-Free Execution
Skipping context and diving straight into execution looks faster, but it is often the slowest path. The waste usually takes three forms.
Waste 1: Rebuilding
Completing something in the wrong direction for lack of context, then rebuilding from scratch. Not only does the time spent vanish entirely, but morale drops with it.
Waste 2: Over- or Under-building
Building without knowing the truly needed scope leads to making things more complex than necessary (over) or missing the core feature (under). Both are expensive mistakes.
Waste 3: A Solution for the Wrong Person
Building without knowing who the actual user is yields a result convenient for the builder but inconvenient for the real user.
The typical flow of context-free execution:
Receive request -> execute immediately -> finish -> "this is not it" -> rework
(when this cycle repeats two or three times,
days are lost over what five minutes of asking could have settled)
How to Collect Context
Context is not completed with a single question. It is a process of gathering bits from several sources to complete the picture.
[From people]
- Ask the requester about intent and background
- Hear the history from someone who did similar work before
- Hear the pain directly from actual users
[From records]
- Read related docs, past meeting notes, the issue tracker
- Find where the reasons for past decisions are recorded
- Check actual usage patterns through data/logs
[From observation]
- Watch how users actually use it, from beside them
- Experience the inconvenience of the current way yourself
A good order is usually "read the records first, then ask people about the remaining blanks." Asking people what is already fully in the docs steals their time, but the intent and context not in the docs can only be learned by asking people.
Case Study: The Difference Between a Junior and a Senior
Comparing how a junior and a senior approach the same task makes the power of context clear.
Task: "There are complaints that search is slow. Make it fast."
[Junior's approach]
Immediately opens the code and starts optimizing the query.
Adds an index and attaches a cache.
-> Search got a bit faster, but the complaints continued.
[Senior's approach]
Asks first:
"Which users say it is slow?"
"On which search terms is it slow?"
"What do they mean by slow — how many seconds?"
"Is everything slow, or only in specific situations?"
-> Turns out one large customer had so much data
that only that customer's search was slow.
Not a global optimization — just fixing that one case was enough.
It is not that the junior lacks ability. Through experience, the senior has internalized that "grasping context before executing is, in the end, faster." This difference is not innate; it can be grown as a habit.
But balance is needed. Collecting context must not turn into endless analysis paralysis. Once you judge that you have gathered enough context, you must move to execution. Understanding context is for better execution, not an excuse to delay it.
The Three Layers of Context
Context is not a single lump but is made of several layers. Being conscious of each layer makes it clear what more you should ask.
[Surface layer] — What
The specific deliverable requested. "Add a coupon input field"
[Function layer] — How
How it should behave. "Support multiple coupon policies"
[Purpose layer] — Why
Why it is ultimately needed. "A campaign to raise repurchase rate"
Most people start work seeing only the surface layer. The person who does work well goes down to the purpose layer. Knowing the purpose layer, you can move toward the real goal without wavering even when the surface request changes. For example, even if the opposite request comes — "remove the coupon field" — if you know the purpose is "raising the repurchase rate," you can propose a better alternative.
Here is a simple bundle of questions to confirm all three layers.
"What should I build?" (surface)
"How should it behave?" (function)
"What do you ultimately want to achieve with this?" (purpose)
Implicit Context: The Things Left Unsaid
The hardest context to handle is the context no one tells you. Every organization has rules, history, and political dynamics that are assumed "everyone obviously knows" and so are never made explicit. This is exactly where newcomers often misstep.
[Common examples of implicit context]
- "That feature was tried before and failed badly."
- "This area is Team A's turf, so consult them first."
- "Because of customer B, this constraint can never change."
- "This code is slated for retirement, so do not touch it."
Such context is rarely in the docs. So you must ask. Especially when you enter a new environment, it helps to ask like this.
"There is probably history I do not know —
is there any background about this work I should know in advance?"
"Has a similar attempt been made before? If so, how did it go?"
The person who absorbs implicit context quickly does not repeat the same mistakes and steps around minefields. This is not a matter of cleverness but of the attitude of asking humbly.
The Timing of Context Questions
Even good context questions lose their effect when the timing is off. Pour them all out too early and the other person feels burdened; ask too late and the work has already gone the wrong way.
[The best timing]
- Right after receiving the work, before touching it (setting direction)
- When showing the first small result (early validation)
- When reaching an important fork (re-confirmation)
[Timing to avoid]
- Right after fully building it (already too late)
- A crisis moment when the other person is clearly busy (exception: questions about the crisis itself)
Especially effective is **early validation**. Instead of showing it after building it perfectly, build it fast even if rough and confirm early: "Is this the right direction?" If a mismatch is found at this point, the loss is small. Context questions do not end with one upfront round; they should repeat at several checkpoints as the work proceeds.
Confirm direction -> build small -> "is this right?" -> refine -> build small -> ...
(this short loop prevents a large mismatch in advance)
Recording Context in Documents
As important as collecting context well is leaving it behind. If hard-won background lives only in one person's head, the next person has to redo the same excavation from scratch. A good team records context in writing and accumulates it as an asset.
In particular, recording "why we decided this way" along with a decision keeps future colleagues from repeating the same debate.
[What is good to leave in a decision record]
- Background: what problem we were trying to solve
- Alternatives considered: what options there were
- Decision: what we chose
- Reason: why we chose it
- Constraints: within what limits we decided
As such records accumulate, even a newly joined person can absorb a large part of the context from documents alone. When the answer to "why are we using this strange approach?" is left in the records, you can prevent the wrong improvement attempts that come from ignorance.
Recording context is a gift to your future self and colleagues. Spend five minutes now writing down the background of a decision, and you can save someone a whole day months later.
Maturity Stages of Understanding Context
The ability to handle context is not completed at once but grows in stages. Knowing which stage you are at now reveals your next direction of growth.
[Stage 1: As told]
Execute the request literally. Do not ask about context.
[Stage 2: Surface questions]
Begin to ask about vague parts. But stay at the surface request.
[Stage 3: Grasping intent]
Ask about the real problem behind the request. Propose better alternatives.
[Stage 4: Defining context]
Go beyond the given context, define the problem yourself, and create context.
Going from stage 1 to stage 2 is relatively easy: just start asking what you do not know. The real leap is from stage 2 to stage 3. It requires the conscious effort to see intent beyond the surface. And stage 4 is the territory of seniors and leaders. Here you do not wait for someone to spoon-feed you context; in an ambiguous situation, you define for yourself "what is the truly important problem right now."
| Stage | Question received | Question thrown |
| --- | --- | --- |
| Stage 1 | "Are you done?" | (no question) |
| Stage 2 | "Is this right?" | "How do I do this?" |
| Stage 3 | "Why is this better?" | "What are we trying to achieve with this?" |
| Stage 4 | "What should we do next?" | "What is the real problem we must solve now?" |
What matters is that the stages are not a ranking of ability but an accumulation of experience and attitude. Anyone can start from the small habit of asking about context and climb the stages above.
Case: The Moment Context Flipped the Outcome
Let us close on the power of context with one small story. A team received the request "show search results faster." On the surface, it was a performance optimization task.
[Surface approach]
"Let us cut search speed by 0.5 seconds."
-> Engineers reworked the infrastructure for days.
-> It actually got 0.4 seconds faster. But user satisfaction stayed the same.
[Context approach]
They ask first:
"When is the real moment a user feels it is 'slow'?"
"Is it the speed that is the problem, or the blank screen while waiting?"
-> Investigation showed that the 'blank screen showing nothing,' more than the
actual speed, was the cause of the frustration.
-> Showing a skeleton screen during loading
greatly improved the perceived speed and raised satisfaction.
The striking thing here is that the context approach produced **a bigger effect** at **a lower cost**. Instead of tearing down the infrastructure for days, they grasped the real problem and solved it with one small screen change. Understanding context does not merely make work more careful; sometimes it finds a far more efficient shortcut.
This is the true value of context questions. Ask "what is the real problem?" rather than "what should I build faster?", and you sometimes even see the path where you do not have to build at all. The fastest code is the code you never have to write.
The Traps and Balance of Collecting Context
Emphasizing context can pull you into the trap of the opposite direction. For balance, let us note them.
[Trap 1: Analysis paralysis]
Waiting for perfect context and never starting.
-> Fix: "start small with what you know now"
and fill in context as you go.
[Trap 2: Excessive question pollution]
Asking everything, even trivia, and wearing the other person out.
-> Fix: find first what the docs can tell you,
and ask only what truly only a person knows.
[Trap 3: The context excuse]
Deferring execution with "I cannot do it because I do not know the context."
-> Fix: even without knowing, set a reasonable assumption
and announce "I will proceed assuming this."
Understanding context is a tool for better execution, not a replacement for it. Once you know enough, you must move. Perfect context does not exist, and there are always parts filled in as you work. The key is to fill only the "fatal blanks" in advance and learn the rest by executing.
Conclusion: The Person Who Digs into the Background Earns Trust
The person who digs into context looks slow at first. They ask many questions and do not move their hands right away. But over time, reputations diverge. Trust accumulates that "that person does not just do what they are told — they see the real problem." And this trust becomes the channel to being given more important and ambiguous work: the kind where you must define the context yourself.
In the end, questions to understand context are both a skill for doing work well and a ladder of growth toward being given bigger work. Next time you receive a task, before moving your hands, ask once: "Why does this work exist?"
Practice Checklist
[ ] Look for the real problem behind the surface request.
[ ] Ask which business metric this work moves.
[ ] Confirm who the actual end user is.
[ ] Quickly sort out the list of stakeholders.
[ ] Dig out hidden constraints (deadline/budget/regulation) in advance.
[ ] Ask "why this, why now?" in a collaborative tone.
[ ] Read records first and ask people only the remaining blanks.
[ ] If possible, directly observe users using it.
[ ] Once you have enough context, execute without analysis paralysis.
References
- Marty Cagan, *Inspired* (product context) — [https://www.svpg.com/inspired-how-to-create-products-customers-love/](https://www.svpg.com/inspired-how-to-create-products-customers-love/)
- Harvard Business Review, "Are You Solving the Right Problems?" — [https://hbr.org/2017/01/are-you-solving-the-right-problems](https://hbr.org/2017/01/are-you-solving-the-right-problems)
- Will Larson, *Staff Engineer* — [https://staffeng.com/](https://staffeng.com/)
- Camille Fournier, *The Manager's Path* — [https://www.oreilly.com/library/view/the-managers-path/9781491973882/](https://www.oreilly.com/library/view/the-managers-path/9781491973882/)
- Lara Hogan, "Stakeholder mapping" — [https://larahogan.me/blog/](https://larahogan.me/blog/)
현재 단락 (1/195)
Give the same task to two people: "Add a coupon input field to the checkout page." One cleanly adds ...