Opening: "Can You Make the Button Blue?"
It is a Friday afternoon. Your manager pings you on Slack. "Could you make the checkout button blue? Before the demo on Monday."
Here two kinds of engineers diverge.
The first engineer immediately opens the CSS, changes the color code to blue, and files a pull request. Done in thirty minutes. It looks efficient.
The second engineer asks one more thing. "Sure, that is doable. Is there a particular reason you want it blue? If there is something you want to highlight in the demo, I might be able to suggest something that fits better."
The manager replies. "Ah, actually, in the last demo a customer said they couldn't find the checkout button. I want it to stand out more."
In that instant the problem changes entirely. "Make the button blue" was a solution, but the real problem was "the checkout button is hard to notice." Blue might even blend into our brand background and become harder to see. The second engineer can now suggest better options: a high-contrast color, repositioning, a subtle shadow.
This article is not about refusing to do what you are told. To be precise, it is about **grasping the purpose behind a request rather than its surface, and working toward whatever best achieves that purpose**. And that is not rebellion. It is the craft of collaborating with your manager to produce a better outcome.
1. Every Request Has an Intent Behind It
A request is the tip of an iceberg. Below the visible "do this (the what)" sits a far larger mass: "why is this needed (the why)."
"Make the button blue" <- surface (the proposed solution)
───────────────────────────────── waterline
"the checkout button is hard to find" <- the problem
"we need to show conversion in the demo" <- business goal
"revenue pressure this quarter" <- larger context
There is a reason managers state a solution first. They are busy too, and they have already settled, somewhere in their head, on "this should do it." But that answer is just a stopgap shaped by the information and time the manager had. The person who actually stares at this area every day is you.
The key here is attitude. Asking "why?" is not picking a fight; it should be a signal that you want context **so you can help better**. The same question lands completely differently depending on tone.
- Bad: "Do we really have to do this?" (sounds like resistance)
- Good: "If you tell me what you are trying to achieve with this, I can build it to fit that goal best." (sounds like partnership)
2. How to Ask "Why" Politely
Asking "why" feels risky because, asked poorly, it can make you look incompetent or uncooperative. So the question takes craft.
2.1 State Your Intent First
Putting "why I'm asking" in front of the question dissolves the defensive reaction.
[purpose statement] + [question]
"I want to suggest the best approach -- what user problem are we solving with this feature?"
"I want to get priority exactly right -- is there a reason this needs to finish this week?"
"I want to avoid building the wrong thing -- who will use this report, and for what decision?"
2.2 Open Questions, Not Closed Ones
"Does it really have to be blue?" ends in yes/no and quietly reads as opposition. Instead use open questions that draw out context.
- "What outcome are you hoping this change produces?"
- "How will we know it succeeded?"
- "Who is going to see this?"
2.3 Confirm by Restating
Repeating what you heard in your own words catches misunderstandings early and signals to your manager that you are truly listening.
"Let me make sure I have this right. A customer couldn't find the checkout button
in the demo, and for Monday you want it to be clearly visible -- is that it?
If so, rather than just changing the color, I'd like to suggest adjusting
position and contrast together."
3. Proposing a Better Alternative
Once you understand the "why," it is time to rise from order-taker to problem-solver. There is a common trap here, though: falling in love with your own idea and ignoring the manager's original request.
A good alternative always starts by **acknowledging the manager's goal**.
[acknowledge goal] -> [limit of original plan] -> [alternative] -> [trade-off] -> [hand back the decision]
"I completely agree the checkout button needs to stand out (acknowledge goal).
The thing is, blue is close to our background and might actually get buried (limit).
A high-contrast orange, moved a bit higher, would likely be far more visible (alternative).
Orange isn't our primary brand color, though, so we could use it just for the demo
and settle on an official color with the design team later (trade-off).
Which direction would you prefer? (decision back to the manager)"
That last line matters. By not forcing the alternative and returning the decision to your manager, you become the person who **widens the options**, not the one insisting "I'm right." It is fine if the manager ultimately sticks with the original plan. There may be context you cannot see (a legal requirement, a promise to leadership), and above all, the manager carries the accountability. Once you have voiced your view fully, you follow the decision cleanly. This is often called **"disagree and commit."**
4. Managing Up — What It Actually Means
The phrase "manage your manager" can grate. How do you manage someone above you when you have no authority? But here, managing means not control but **actively running the relationship**. It is the work of offering information and aligning direction first, so your manager can support you well.
4.1 Learn Your Manager's "User Manual"
Everyone works differently. Managers are no exception. Observe these, or simply ask.
| Item | What to learn |
| --- | --- |
| Channel | Slack vs email vs verbal, expectation of instant replies |
| Detail level | Do they want a summary, or the full detail? |
| Decision style | Data-driven or intuition-driven? |
| Bad news | Tell them immediately, or arrive with a solution attached? |
| Priorities | What do they weigh most heavily? |
4.2 No Surprises
What managers hate most is not bad news itself but **hearing bad news late, through someone else**. If a deadline is slipping, say so a few days out, not on the due date.
Bad (on the due date):
"Sorry, I don't think I can finish today."
Good (three days out):
"A quick status update. The API integration hit an unexpected auth issue,
so it'll likely take about two extra days. Two options:
(1) push the auth piece to next sprint and ship the rest first, or
(2) move the deadline out by two days. Which do you prefer?"
The latter is not just a report; it organizes options to make the manager's decision easy. That is how trust is built.
5. How to Actually Use Your One-on-Ones
The one-on-one is not your manager's time; it is **your time**. A common mistake is filling it with status updates, but status can travel over Slack or a doc. The thirty face-to-face minutes should go to deeper conversation.
Simply bringing a written agenda transforms the quality of a one-on-one.
[1:1 agenda template]
1. Blockers / where I need help
- I need your input on decision X.
2. Alignment check
- Here's how I understand next quarter's priorities -- is that right?
3. Feedback request
- How was my last presentation? Anything to improve?
4. Growth / career
- What skills should I build to move toward senior?
5. Information to pass upward
- Problem Y keeps recurring on the team; you should know about it.
Items 4 (growth) and 3 (asking for feedback) are easy to skip yet carry the most value. Feedback does not arrive if you wait for it. You have to **ask first, and specifically**, to get a useful answer. Not "how am I doing?" but "was my explanation clear in the last design review? How could I be more persuasive?"
6. The Craft of Giving and Receiving Feedback
6.1 When Receiving Feedback
Defense is instinct. When someone says something negative about your work, your heart speeds up and an excuse leaps out first. But the moment you get defensive, the other person stops giving you honest feedback.
- Listen first. Hear them out before rebutting.
- Make it concrete. To a vague "it wasn't great," ask "could you give an example of which part?"
- Say thank you. Even if you disagree, thank them for taking the time.
- Judge later. You don't have to accept or reject everything on the spot. "Let me think about it" is a fine answer.
6.2 When Giving Feedback (Including Upward)
You can give your manager feedback too -- but the method matters. The SBI model (Situation-Behavior-Impact) helps.
[Situation] In last sprint's meeting,
[Behavior] priorities shifted three times mid-discussion,
[Impact] and the team got confused about what to focus on.
-> Focus on the behavior and its result, not the person.
"You're flighty" (attacking character) X
"Frequent priority changes were confusing" (behavior and impact) O
Deliver upward feedback in private, framed not as blame but as a suggestion for improvement. A good manager welcomes it; even one who doesn't will register your initiative.
7. Finding Balance — This Is Not a Cure-All
If by now you are thinking "so I should ask why for every single request," that is too far. Balance is needed.
- **Just do the small, obvious things.** Asking "why am I fixing this?" about a typo wastes time.
- **In an emergency, act first and ask later.** "Let's debate the root cause first" is wrong during an outage. Put out the fire, then discuss the why in the retro.
- **Watch your trust balance.** If you just joined, executing faithfully first to build trust is wiser. As trust grows, so does the room to ask "why" and propose alternatives.
- **Focus on recurring patterns.** Applying "why" to repeated inefficiency or repeated misdirection pays off more than to a one-off request.
The point is that "understand the why" is not "distrust the instruction." It is the deeply practical stance that understanding the purpose lets you execute better.
8. A Case: Same Request, Different Outcome
A data engineer was asked by his manager to "send the sales report as an Excel file every Monday morning."
He did exactly as told, running the query by hand each week and building the spreadsheet. After six weeks the chore weighed on him. Only then did he ask: "Do you read this report yourself, or do you forward it to someone?"
The answer was a surprise. "I paste it into the team channel so everyone can see it." In that case it needn't be Excel, and a human needn't build it weekly. He built a dashboard that updated automatically in the team channel. The manager's real goal ("the team can always see sales") was met better, and his Monday mornings were freed.
Had he asked "why" in the first week, the six weeks of manual labor would never have happened. Thirty seconds of asking about purpose saves dozens of hours.
9. An Alignment Conversation, Start to Finish
Let's tie the theory together into one conversation -- a fictional one-on-one between a near-junior engineer, Jimin, and her manager. Jimin naturally uses the techniques from this article one by one.
Manager: Could you build us a search feature fairly quickly next sprint?
Jimin: Sure, that's doable. One thing, so I build it well --
what prompted moving search up in priority? (ask intent first)
Manager: Sales keeps hearing that customers can't find the materials they want.
Jimin: Ah, so the core is "let people find the right material fast."
Did I get that right? (restate and confirm)
Manager: Exactly.
Jimin: In that case, rather than building full-text search from scratch,
adding tags and filters to the most-searched materials first
might deliver the effect faster, with search as a next step.
(acknowledge goal -> propose alternative)
Manager: Oh, that would be quicker. But don't we need a search box to look right?
Jimin: Fair point. Then we could ship a light search box plus filters first,
see how people respond, then grow full search. The first cut
won't be perfectly accurate, though. (trade-off)
Which would you prefer? (hand back the decision)
Manager: Good, let's do that. When could the first cut be ready?
Jimin: I'll ship the first cut by Friday and we can review the response
in Monday's 1:1. If it looks like it'll slip, I'll flag it Wednesday.
(manage expectations)
In this conversation Jimin never once said "we can't do that." Yet the original request ("build search quickly") and the final outcome ("filters first, a light search box, staged expansion") are quite different -- because she grabbed the intent ("find materials fast") rather than the surface.
This is all the article is saying. A path that goes, with your manager, toward a better answer -- without rebelling, but without staying a mere order-taker. At every corner of that path stands the same question: "What are we really trying to achieve with this?"
10. Five Common Anti-Patterns
Flip everything above on its head and you get a list of the classic mistakes that damage the relationship with your manager. Honestly check whether any apply to you.
9.1 Building on a Guess Instead of Asking
The most common and most expensive mistake. You spend days building "what they probably meant," only to find it is nothing like what they wanted. The cost of guessing is always higher than the cost of asking. Thirty seconds of a question prevents three days of wasted work.
9.2 Pushing Back on Everything
The opposite trap. Attach a "why?" even to trivial requests and you become an obstacle, not a collaborator. The balance from section 7 matters here. Spend "why" sparingly, on work that is high-impact or whose direction is genuinely doubtful.
9.3 Agreeing and Then Undercutting Behind the Scenes
Nodding in the meeting and then grumbling to a colleague back at your desk, "that makes no sense." This destroys trust fastest. If you disagree, say so in the room, politely. If you missed the moment, go to them privately. Backchanneling is not the answer.
9.4 Hiding Bad News
When things start to go wrong, hiding it -- "let me just fix it on my own somehow" -- instead of flagging it before it's too late. It usually grows into a bigger incident. The earlier the manager knows, the more they can help. A bomb that goes off late cannot even be defused.
9.5 Reporting Effort Instead of Result
"I worked really hard" is not a report. What the manager needs to know is "so what happened, and how." Effort is the input; what the manager is accountable for is the output. Build the habit of speaking in results and their meaning.
11. Alignment Is a Habit, Not a One-Time Event
In truth, all the techniques above converge on a single larger habit: **periodically refreshing alignment.**
The misconception is to see alignment as a one-off event -- align once at the start of a project and you're done. But circumstances keep changing. The market shifts, priorities shift, the pressure your manager absorbs from above shifts. There is no guarantee that last month's alignment still holds today.
[the cadence of alignment]
daily: does what I'm doing today match the agreed direction? (a 5-second self-check)
weekly: confirm in the 1:1 that priorities still stand
quarterly: re-check that my work aligns with the larger goals
Once this habit is in your bones, "understand the why" stops being a conscious effort and becomes the way you work. Without asking anew each time, your manager's goals and context stay alive in your head. Then, even for the same request, "how does this connect to that goal?" arises automatically.
And over time something interesting happens. Your manager starts handing you bigger work with less and less explanation -- because they know you work from intent, not surface. That is the moment trust turns into autonomy, and it is the heart of the path toward senior.
12. A Practical Checklist
Questions to ask yourself when a new request lands.
- [ ] What is the manager truly trying to achieve with this request?
- [ ] Is there a better way than the proposed solution?
- [ ] What is the success criterion, and who will see the result?
- [ ] Does the deadline and priority conflict with other work?
- [ ] (If proposing an alternative) Did I acknowledge the goal, lay out trade-offs, and hand back the decision?
- [ ] If there's schedule risk, did I share it early (not on the due date)?
- [ ] If it's small or urgent, isn't executing immediately, without probing, the right call?
Closing
"Don't just do what you're told" can sound arrogant. But its true meaning is the opposite. It is the effort to serve your manager better by reading even the intent they could not fully put into words.
Good collaboration is not command and obedience; it is two people who share a purpose finding a better answer together. The first step of that process is always the same question: "What are we really trying to achieve with this?"
If you can ask that question politely, but never skip it, you stop being someone who merely processes tasks and become someone who helps set direction. And that difference, in the end, builds trust -- and a career.
References
- Julie Zhuo, *The Making of a Manager* (fundamentals of management and one-on-ones)
- Will Larson, lethain.com — writings on managing up
- StaffEng, staffeng.com — how senior and staff engineers operate
- Harvard Business Review (hbr.org) — "Managing Your Boss" (John Gabarro & John Kotter)
- Kim Scott, *Radical Candor* (giving and receiving feedback)
- Amy Edmondson, *The Fearless Organization* (psychological safety and candid conversation)
현재 단락 (1/151)
It is a Friday afternoon. Your manager pings you on Slack. "Could you make the checkout button blue?...