@ahmetcantryk
Short answer: managing up means understanding your manager's goals and constraints, then surfacing risks early — not pleasing them. It's the most practical way to build trust and get unblocked fast, and it has nothing to do with flattery.
What Does "Managing Up" Actually Mean?
Short answer: it means making your manager's job easier — letting them know what you're doing and where you're stuck without needing to micromanage you to find out. It doesn't mean withholding things they won't like to hear, or saying "everything's fine" on repeat — it means the opposite: not hiding problems.
A manager's biggest fear is a risk that stays hidden until it explodes at the last minute. A manager who experiences that repeatedly starts tightening control over their team — more meetings, more approval steps, less autonomy for everyone. Managing up well reverses that cycle.
How Do You Learn Your Manager's Goals and Constraints?
Knowing the metrics your manager answers for to their own manager, the deadlines they feel pressure on, and the constraints outside their control (budget, headcount, executive priorities) helps you time your requests correctly. Don't hesitate to ask directly: "What are you accountable for to leadership this quarter?" is a question most managers are happy to answer.
Requests made without that context land at the wrong time — asking to buy a new tool during a budget-constrained period, for instance, gets read as poorly timed even if it's technically justified. An engineer who knows the context gets the same request approved far more easily, just by framing it right or timing it well.
How Do You Write Status Updates That Build Trust?
An effective status update covers three things: what's done, what's in progress (and roughly when it'll finish), and what's blocked (and who or what needs to unblock it). Vague updates like "everything's fine" leave your manager blindsided the moment something actually goes wrong — the fastest way to erode trust.
Weak update | Strong update |
|---|---|
"Working on the feature, going well" | "API integration is done, UI is at 60%. On track to finish by Thursday, no risk right now" |
"There's an issue but I'll handle it" | "Third-party API is rate-limiting us, fix might add a day — should be clear by end of day, wanted you to know" |
"Everything's fine" | "2 of 3 tasks are done, 1 is blocked waiting on design sign-off — following up" |
This structure is the status-update version of the "specific, actionable feedback" principle we cover in our guide to running effective code reviews — concrete information instead of vagueness.
When and How Should You Surface Risks Early?
Flagging a risk the moment you notice it — even without a ready solution — beats flagging it late with one attached. Managers generally trust engineers who bring bad news immediately more than engineers who try to solve everything alone and report late, because the former gives them room to plan.
When you raise a risk, bundle three things together: what happened, its likely impact (timeline, scope, quality), and the next step you'd recommend. Saying "there's a problem, what should I do?" is weaker than "there's a problem, here are two options, I'd recommend A because..." — the second version reports the issue and positions you as someone actively solving it.
How Do You Disagree Well?
Before pushing back on a decision, try to understand your manager's perspective first — there's often a constraint or piece of context you're not seeing. Asking "why did we land on this?" surfaces far more information than saying "this decision is wrong," and it avoids putting your manager on the defensive.
State your view clearly, once — re-litigating a decision across three separate meetings reads as friction, not contribution. Once a decision is made, standing behind it even if your view didn't win — commonly called "disagree and commit" — is a behavior that builds trust over the long run.
Getting Unblocked and Getting Credit
When you ask your manager for help clearing a blocker, be specific: "I'm stuck on X, could you do Y" gets resolved far faster than "I need help," because your manager knows exactly what action to take.
On credit: making your work visible isn't flattery — a manager can't always know exactly what everyone on their team is doing. Regular, measured status updates (weekly, without overdoing it) both make your work visible and mean you're not relying on memory alone come performance review time.
How Do You Navigate Shifting Priorities?
When priorities shift, understanding why — pressure from leadership, customer feedback, a technical necessity — makes it much easier to adapt to the new priority. Just saying "okay" without understanding the reason sets you up to hit the same friction the next time priorities change.
How Does This Change on a Remote Team?
On a remote team, your manager doesn't get the chance to gauge your status by casually walking past your desk — which makes the frequency and clarity of written updates even more critical. With an asynchronous manager, delivering a problem as a short paragraph with context (what happened, what you tried, what you'd recommend) instead of a single one-line Slack message cuts down the back-and-forth question rounds and gets a decision made faster.
This is a direct extension of the "you have to actively build your own visibility" point we cover in our guide to growing your career as a remote developer — visibility that accumulates passively in an office has to be actively created when you're remote.
What Does an Effective 1:1 Look Like?
An effective 1:1 agenda:
1. Your agenda (not your manager's) - 2-3 items, prepared beforehand
2. Open blockers and the support you need
3. Career/growth topics (not every week, but at a regular cadence)
4. Risks your manager needs to know about
5. Feedback - two-way, give it as well as receive itTurning a 1:1 into a status-report reading session wastes its most valuable use — status belongs in written updates, not this meeting.
Frequently Asked Questions
Do I have to agree with my manager on everything?
No, but stating your disagreement clearly once and then committing to the decision is far more effective than re-litigating it repeatedly. Trust comes from open, respectful communication, not constant agreement.
When should I deliver bad news?
The moment you notice it, even without a ready solution. Bad news delivered late always costs more than bad news delivered early, because it removes the chance to plan around it.
My manager micromanages me — what should I do?
Micromanagement usually comes from a lack of trust. Providing regular, predictable, clear status updates can, over time, reduce a manager's need for tight control — but this doesn't change overnight; it takes consistency.
What shouldn't I talk about in 1:1s?
Reading a status report is a waste of the time — that information should already live in written updates. Using the 1:1 for blockers, career topics, and mutual feedback is what makes the meeting worth having.
