Managing Up as an Engineer

If you’re an engineer who flinches at the phrase “managing up,” you’re not wrong to flinch. The phrase has been worn into uselessness by LinkedIn carousels and corporate training decks, and most of what gets called managing up in those venues actually is just politics with a more PR-friendly name. So engineers who care about craft tend to opt out of the whole category — and then quietly notice, two or three promotion cycles later, that a peer who does roughly the same technical work is two levels ahead.

The peer is not better than you. The peer just understood the part of the job nobody told either of you about: the version of your work that exists in your manager’s head is the one that gets evaluated, defended in calibration meetings, and translated into compensation. The work itself is necessary. Making the work legible to the person responsible for representing it — that’s the part most engineers under-invest in. This article is about that work, in concrete terms, with no carousels.

What managing up actually means

The most useful definition I’ve heard for managing up comes from the engineering equivalent of API design: you are reducing the cognitive load on the system that surrounds you, so the system around you works better. Your manager is a system. They are running at high context-switching rates, juggling six to twelve direct reports, three to five projects, and at least one source of organizational drama you have no visibility into. The amount of attention they can spend on the version of you in their head is bounded. Your job is to make sure the version they have is accurate, current, and easy to repeat in rooms you’re not in.

Three rooms in particular: the calibration meeting where promotion decisions get made, the staffing meeting where projects get assigned, and the one-on-one your manager has with their manager every couple of weeks. In all three rooms, the version of you that gets represented is the version your manager remembers from the last few touchpoints. If those touchpoints are vague or sparse, the version is vague or sparse. That’s the whole game.

The version of your work that exists in your manager’s head is the one that gets evaluated. Making the work legible to that person is the part of the job that most engineers under-invest in.

Practice 1: The weekly written update

Once a week, you write a short summary of what you shipped, what you’re blocked on, and what you’re working on next. You ship it to your manager — or, if your team has a shared channel for this, you post it there and tag them. Five to eight bullets. No more.

The format that works:

• Shipped this week: 2–3 bullets, each a thing that exists in the world now. “Deployed the rate-limit middleware to staging” is shipped. “Made progress on the rate-limit middleware” is not shipped.
• Blocked on / risks: 1–2 bullets. The point is not to complain — the point is to give your manager information they can act on before the risk becomes a fire.
• Next week: 2–3 bullets, what you plan to ship. Putting it in writing creates a soft commitment that gets you to ship it.
• Need a decision on: If applicable, the specific question you need answered.

The cost is fifteen minutes on Friday. The compounding benefit is: your manager always knows where you are, never has to ping you for status, and walks into every meeting about you with a fresh, accurate, easy-to-defend picture. A year later when promotion conversations happen, your manager has fifty-two of these to draw on. The engineer who didn’t write them has whatever their manager happens to remember.

The objection most engineers raise here is some version of: “If my manager needs a written update to know what I’m doing, that’s a failure of their management.” The objection is partially true and completely irrelevant. The cost to you is fifteen minutes. The cost of the alternative (being misrepresented in your own absence) is measured in years.

Practice 2: The 1:1 that has an agenda

Most engineers walk into 1:1s with no agenda, let their manager drive the conversation, talk about whatever is top of mind, and walk out without a single decision having been made. That meeting was a hangout. Hangouts are fine. They’re just not what 1:1s are for.

The 1:1 that actually moves the needle has three components: an agenda you ship to your manager an hour before (so they have time to think), three sections (what I shipped, what I’m blocked on, what I want to think through with you), and one explicit decision or ask at the end. The decision can be small — “should we deprioritize X to make room for Y this week?” — but it has to exist. The 1:1 that ends with “okay, talk next week” is the one that quietly tells your manager you don’t actually need them, which means they will start spending the slot somewhere else.

One more rule: keep career conversations on a separate cadence. Once a quarter, run a dedicated career 1:1 — what you’re trying to grow into, what gaps you see, what evidence would change your manager’s mind about your level. Don’t bleed those conversations into the weekly 1:1 or you’ll end up with neither a good operational meeting nor a good career one. The career conversation deserves its own forty-five minutes with a notebook open, not a five-minute add-on to a sprint check-in.

Practice 3: Surfacing risks before they become problems

This is the practice that distinguishes senior engineers from staff engineers in the eyes of most managers. The pattern is simple to describe and hard to do:

1. You notice something that could become a problem. The migration plan has an edge case nobody’s named. The vendor deadline assumes a thing that isn’t true. The PM’s scope estimate is off by 2x.
2. Most engineers wait until the problem is undeniable, then escalate. By then it’s expensive.
3. The engineers who get promoted faster surface the risk in writing, with a recommendation, while there’s still time to do something cheap about it.

The format that works is the one Amazon’s six-pagers use, in miniature: here’s what I’m seeing, here’s why I think it matters, here’s what I’d recommend, here’s the version of the argument against me that I find most compelling, here’s why I still recommend the original. That last step — steelmanning the argument against your own position — is the one most engineers skip, and it’s the one that makes the rest land. It signals you’ve actually thought about it and aren’t just defending the first opinion you formed.

The output is usually a Slack DM, sometimes a doc. It takes twenty minutes. The compounding effect is your manager starts to think of you as “the engineer who sees around corners” — which is the language used in calibration meetings to argue for staff and principal promotions.

Practice 4: Making your career goals explicit, in writing, on a page they can read

Engineers consistently underestimate how often their manager forgets what they said they wanted in the last career conversation. Not because the manager is callous — because the manager has six other people who also said things they wanted, three projects to staff, and a board deck due Friday. The conversation that felt momentous to you was the eleventh similar conversation that week for your manager.

The fix is a one-page document you maintain. It lives in your shared drive or your 1:1 notebook. It contains:

• The next role you’re trying to grow into, named explicitly (e.g., “Staff Engineer, Platform team”), with a target timeline (“next 12–18 months”).
• The 3–5 capabilities you’re investing in right now, with the evidence you’re building for each (a project you led, a doc you wrote, a system you owned end-to-end).
• The kinds of work you want more of, and the kinds you want less of.
• One specific ask for the next quarter.

You bring this page to your quarterly career 1:1, you update it after each one, and you reference it explicitly. You are not being “too direct.” You are doing your manager an enormous favor — you are giving them the script they can use to advocate for you in rooms you’re not in. The alternative is they advocate for you using their best guess about what you want, which will be approximately correct on a good day and quite wrong on a bad one.

Practice 5: Disagreeing in writing, with the other side steelmanned

The fastest way to lose credibility with a manager is to disagree loudly in a meeting without having done the work to think through their position first. The second fastest way is to never disagree at all — they will start to wonder if you have judgment.

The path between those failure modes is: when you disagree on something that matters (a tech direction, a project priority, a hiring decision), you write up your position in a document. You present your recommendation, you present the strongest version of the argument against you (this is the steelman step), and then you explain why you still recommend the original. You send it to your manager, you give them a day to read it, and then you talk.

This format does three things at once. It makes you look thoughtful instead of contrarian. It gives your manager the time to actually consider your argument instead of reacting on instinct. And it leaves a written artifact — which is useful if the decision goes your way and you’re proven right later, and useful in a different way if the decision goes the other way and you need to revisit it in three months.

One subtle rule: the document should not include the words “I think you’re wrong.” The document is about the decision, not about the person making it. The decision can be wrong while the person making it is doing the best they can with the information they had. Keeping the two separate is the difference between engineers who get listened to and engineers who get reputations for being difficult.

What to do when your manager is bad

The honest answer is: managing up gets more important, not less, when your manager is struggling. With a great manager, managing up is an accelerator. With a manager who’s overstretched, distracted, or just not great at the job, managing up is how you protect your scope, your timeline, and your performance review. The five practices above don’t change — you just do them more deliberately, and you keep better records.

What does change is the time horizon. If you’ve done all of this for six months and you’re still being misrepresented in calibration, blocked on scope you should be getting, or treated as more junior than your work warrants, the answer is not better management of the manager. The answer is a different team or a different company. Managing up has limits, and one of the most important pieces of self-awareness in any engineering career is knowing where those limits are.

One useful diagnostic: ask yourself whether the gap between “the version of you in your manager’s head” and “the actual you” is closing or widening over the last quarter. If it’s closing, keep going — the work is working. If it’s widening despite real effort, the system is broken in a way you can’t fix from inside it.

The compounding effect

Each of these practices costs less than an hour a week. None of them require a personality change, none of them are particularly hard, and none of them involve pretending to be someone you’re not. They’re just deliberate. Most engineers don’t do them because nobody told them they were part of the job.

The compounding effect over a five-year career is enormous. Engineers who manage up well show up in their second or third role at a level above their peers, with managers who advocate for them in rooms they’re not in, with promotion packets that almost write themselves because the evidence has been accumulating in weekly updates for the whole calibration period. Engineers who don’t do this work tend to do excellent technical work and quietly wonder why their careers feel slower than the work should warrant.

None of this is a substitute for the underlying engineering work. If you ship bad code or miss commitments, no amount of managing up will make that look like good work. But assuming the technical work is there — and for most of the engineers reading this, it is — making the work legible is the highest-leverage thing you can do for your own career.