Most engineers have an uncomfortable relationship with the phrase “managing up.” It sounds like politics, like playing games, like doing something other than the real work. The discomfort is understandable — and it leads to a lot of staff engineers doing excellent technical work that doesn’t get funded, prioritized, or protected.

Managing up is not about manipulation or self-promotion. It’s about ensuring that the people responsible for resource allocation, roadmap decisions, and organizational priorities have accurate information about the work you’re doing and why it matters. When you manage up poorly, decisions get made with incomplete information. That’s bad for the organization and bad for the work you care about.

What Managing Up Actually Means

At the staff engineer level, managing up means maintaining effective working relationships with your manager, their manager, and often skip-level leadership. Specifically:

Keeping your manager informed — not with everything, but with the things that affect decisions they need to make. If your manager is surprised by something in a meeting, you’ve failed to communicate something important.

Shaping how your work is understood — technical work that isn’t explained in terms leadership cares about tends to get deprioritized. Your job is to connect what you’re doing to outcomes that matter at their level.

Surfacing problems before they become emergencies — leaders hate surprises. Early signals about risks, blockers, or timeline concerns are far more valuable than after-the-fact explanations of what went wrong.

Building credibility as someone worth consulting — the staff engineers who get pulled into high-stakes decisions early are the ones who’ve demonstrated sound judgment and the ability to communicate it clearly.

Calibrate Your Communication to the Audience

The biggest error in managing up is using the same communication style at every level. What your team needs to understand about a system is different from what your manager needs to know, which is different from what a VP needs to hear.

A useful mental model: every level of leadership is managing a different span of time and a different scope of concern. Your team is thinking in sprints. Your manager is thinking in quarters. Their manager is thinking in halves or years.

For your direct manager: Technical specifics are relevant. Dependencies, risks, and team capacity matter. What will affect the next planning cycle matters most.

For skip-level leaders: Outcomes and business impact. What did this enable? What risk was reduced? What does this unlock? The implementation details are largely irrelevant at this level unless there’s a decision to be made.

For senior executives: Business outcomes, strategic alignment, major risks. One or two sentences per topic. If you find yourself explaining technical architecture to a VP, you’ve misjudged the audience.

The Weekly Update Habit

Many staff engineers underinvest in written communication with their manager. The engineers who manage up most effectively tend to have a consistent habit: a weekly or bi-weekly status update, usually in writing, that surfaces the right signal without requiring a meeting.

A good update covers:

  • What significant progress happened
  • What decisions are pending or upcoming (especially ones that need their input or awareness)
  • Any risks or blockers worth flagging
  • Anything that might be discussed at their level (so they’re not caught off-guard)

The update should take you 10–15 minutes to write. If it takes longer, it’s too detailed. If it takes less than 5 minutes, it’s probably not surfacing enough.

The discipline here is distinguishing between what happened (exhaustive) and what matters (selective). Your manager doesn’t need to know about every PR you reviewed. They do need to know that the migration you’ve been leading is now blocked on the security review that was supposed to take one week and is now in week three.

Surface Problems Early, with Solutions

The rule of thumb is: the further a problem is from your manager’s awareness, the worse the eventual conversation will be. Don’t wait until a risk has become a crisis before escalating.

But the way you surface problems matters. The difference between:

“The performance refactor is going to miss the deadline”

and

“The performance refactor is trending toward missing the deadline. The blocker is X. The options I see are: (A) descope Y and ship on time, (B) push by two weeks and ship in full, (C) split the work and ship a partial improvement now. I’m leaning toward A, but wanted your input before committing.”

The second version gives your manager something to act on. The first version just creates work for them.

When you have a problem, come with at minimum your assessment of the options. Coming with a recommendation is better. What you’re signaling is: I’ve thought about this, I understand the trade-offs, and I’m asking for input — not asking to be managed.

Translate Technical Work into Business Outcomes

The most common complaint from engineering leadership about staff engineers is that they “can’t communicate business impact.” What this usually means is that technical staff default to describing what they built, not what it enabled.

The shift is simple in principle:

Instead of: “We migrated the data pipeline to the new infrastructure.”

Try: “The data pipeline migration reduced our operational overhead by ~20 hours/week and eliminates the class of incidents we’ve been having around X. It also unblocks the product team’s Q3 work on Y, which they’ve been waiting on for two quarters.”

The second version requires you to have thought about business impact — not just technical completion. This thinking is part of the job at the staff level. If you haven’t thought about the business impact of your work, that’s the gap to close.

A useful forcing function: for any significant project you lead, write one paragraph that explains the work in terms a product manager or finance leader would find compelling. If you can’t write it, the work may need to be scoped differently or you need to understand the business context better.

Managing Expectations on Timeline and Scope

Staff engineers routinely underestimate how much timeline and scope clarity matters to leadership. Leaders plan resources, set expectations with their own stakeholders, and make commitments based on what engineers tell them.

When you give a timeline, give a calibrated one:

  • “Two weeks” as a confident estimate is different from “two weeks” as a guess
  • “We’ll be done in Q3” with no caveats gets held as a commitment even when circumstances change
  • “Our current estimate is Q3, but that assumes we get unblocked on the security review by end of May” is far more useful

Giving a range (“4–6 weeks depending on X”) is often better than a point estimate. It communicates uncertainty honestly rather than pretending confidence you don’t have.

When circumstances change — and they will — update early. The conversation where you say “we’re going to miss the estimate we gave three weeks ago and here’s why” is much easier to have at three weeks than at three weeks before the deadline.

Don’t Mistake Visibility for Politics

Some engineers avoid managing up because they conflate communication with self-promotion. There’s a version of managing up that is self-promotional — talking about your own accomplishments loudly, making sure your name is attached to successes, and staying quiet on failures. That’s not what good managing up looks like.

Good managing up is about organizational effectiveness, not personal advancement. It happens to be correlated with career advancement because effective communication is a core job requirement at the staff level — but the goal should be organizational, not personal.

The tell: if your updates are primarily about what you’re doing rather than what your work is enabling, you’ve drifted toward self-promotion. Reorient toward outcomes, toward what decisions are pending, toward what your manager needs to know to do their job well.

Build the Relationship Before You Need It

The time to establish a strong working relationship with leadership is not when you’re asking for headcount, escalating a conflict, or surfacing a major risk. It’s during the regular course of work.

Invest in regular one-on-ones with your manager that go beyond status. Ask about their priorities and what’s keeping them up at night. Share your perspective on things outside your immediate scope when you have useful insight. Build a track record of delivering on what you commit to.

When you have a working relationship built on trust and consistent communication, the harder conversations — asking for resources, escalating a conflict, pushing back on a priority — go significantly better. You’re not a stranger making a request; you’re someone with an established track record making a case.

What Good Looks Like

Staff engineers who manage up effectively tend to share a few characteristics:

  • Their managers are rarely surprised — they have a reliable sense of what’s happening, what the risks are, and where decisions are pending
  • When they ask for something (resources, a decision, a change in priority), the ask is well-prepared and easy to evaluate
  • They communicate the same technical content differently to different audiences
  • They surface problems before they become emergencies, with options
  • They give timeline and scope estimates that are calibrated, not falsely optimistic

None of this requires becoming a different kind of engineer. It requires treating communication with leadership as a skill worth developing — not a distraction from the real work, but part of it.