Early in my career I thought managing up was a euphemism for office politics, the kind of thing people did instead of shipping. I was wrong, but not entirely. The version I feared does exist: the manager who spends more energy crafting the narrative than building the thing. What I missed was that the alternative to managing up is not purity, it is silence, and silence gets your team underfunded, misunderstood, and eventually reorganized out from under you.
Over the years running engineering in regulated fintech, I have come to see managing up as a discipline with its own integrity. Done well, it is mostly about giving the people above you an accurate, useful model of reality so they can make good decisions. The hard part is doing that without contorting yourself into someone you would not respect. This post is about how I try to hold both.
What Managing Up Actually Is
Managing up is the work of making your manager and your manager's manager effective with respect to your domain. They have limited time, dozens of competing inputs, and a partial view of what your team does. If you do not actively shape that view, it gets shaped anyway, by the loudest stakeholder, by a stale dashboard, or by whoever happened to be in the room when a number went sideways. Managing up is choosing to be a deliberate input rather than letting noise fill the vacuum.
I find it useful to separate the function from the failure mode. The function is communication, prioritization alignment, and risk surfacing. The failure mode is impression management detached from substance. These two get conflated because they use some of the same surface behaviors: talking to executives, framing updates, choosing what to highlight. The difference is whether the underlying reality matches the picture you are painting. If it does, you are managing up. If it does not, you are managing a perception, and that is a debt that comes due.
In a regulated environment the stakes are sharper. When I tell a board-level stakeholder that a control is in place, an auditor may later test that exact assertion. I cannot afford a culture where polish drifts ahead of fact, because the gap eventually shows up in a finding with my name attached to it. That constraint, which can feel like a burden, is actually a gift: it forces honesty to be the default, not the exception.
Why It Feels Like Losing Yourself
The reason managing up triggers a self-betrayal alarm is that it asks you to translate. You spend your days thinking in systems, latencies, failure domains, and migration sequencing. Then you walk into a room where the operating language is revenue, risk, and timeline, and you have to compress something true and intricate into something short and legible. Every compression loses information, and it is natural to feel that the lossy version is a lie, or that you are betraying the craft by simplifying it.
There is also a status dimension that nobody names. Translating upward can feel like you are performing deference, and engineers who got into the field precisely because it rewards being right over being agreeable can experience that as a small humiliation. I felt this acutely as a new manager. I read every request to reframe my update as a request to dilute it, and I dug in on technical precision as a way of protecting my identity.
What changed my mind was watching the cost of refusing to translate. A staff engineer I respected enormously gave technically flawless updates that no executive could act on. His projects were chronically deprioritized, not because they lacked merit but because nobody upstream could carry his case forward. He had preserved his self-image perfectly and lost every resource argument. Losing yourself is real, but so is making yourself irrelevant in the name of integrity.
Separating Translation From Distortion
The line I try to hold is simple to state and hard to live: translation changes the resolution, distortion changes the facts. When I tell a CFO that a platform migration carries a six-week window of elevated incident risk, I have dropped the details of the consistency model and the replication topology. I have not changed what is true. If instead I told her the migration is low risk because I was afraid of looking slow, I would have crossed into distortion.
Holding this line requires you to know, before you walk into the room, what the irreducible facts are. I write them down. For any significant update I keep a short list of claims I will not soften regardless of how the conversation goes. These are usually the load-bearing risks and the honest dates. Everything else, the framing, the order, the level of detail, is negotiable. The non-negotiables are not.
The goal is not to say everything you know. It is to make sure that nothing you choose to leave out would have changed the decision being made.
That test has saved me more than once. When I feel the pull to omit something, I ask whether its absence would lead a reasonable executive to a different choice than they would make with full information. If the answer is yes, it stays in, however inconvenient. If the answer is no, I can drop it for clarity with a clean conscience. The discipline is not in saying everything; it is in being ruthless about what materially matters.
Building an Accurate Upward Model
Most upward conflict I have seen comes not from disagreement but from mismatched mental models. Your manager thinks the project is about feature velocity; you know it is actually about paying down a reliability deficit that will otherwise cause an outage during the next volume spike. You are both rational and you are talking past each other. The job is to align the models before you align the decisions.
I do this by being explicit about the model itself, not just the conclusion. Instead of saying we need two more engineers, I explain the causal chain: here is the load we expect at quarter close, here is where the current architecture saturates, here is the lead time to fix it safely, therefore here is the staffing ask. When someone can see your reasoning, they can correct it if you are wrong and trust it when you are right. A conclusion delivered without its model invites either blind acceptance or blind resistance, and both are fragile.
A few practices have made my upward models more accurate and more durable:
- State assumptions out loud, including the ones you suspect your manager does not share, so disagreements surface early rather than at the deadline.
- Quantify uncertainty honestly with ranges and confidence levels instead of false single-point estimates that you will be held to later.
- Update the model in public when reality changes, so that being wrong becomes a normal event rather than a credibility crisis.
- Tie every technical concern to a consequence the business already cares about, because an unconnected risk reads as a preference.
The Currency of Trust
Everything in managing up runs on trust, and trust is built almost entirely through calibration. When I say something is a hard date, it has to be a hard date. When I flag a risk, it has to be a real one. The first time an executive catches your hard date slipping without warning, or your dire risk failing to materialize twice in a row, the value of all your future statements drops. You become noise to be discounted rather than signal to be acted on.
I treat my own forecasts as a track record I am accountable for. I would rather give a wider, honest range and land inside it than a tight, optimistic number that I miss. Over a few quarters this compounds: people learn that when I am calm, things are genuinely fine, and when I escalate, they should drop what they are doing. That earned calibration is worth more than any single persuasive presentation, because it lets a short message carry real weight.
The inverse matters too. I try never to spend trust I have not earned by overdramatizing to get attention. The temptation to inflate a risk so it finally gets resources is strong, especially when you have been ignored. But every inflation is a withdrawal from the account, and the account is the only thing that makes you effective when something is actually on fire. Guard it the way you would guard a production credential.
Disagreeing With Power
Managing up does not mean agreeing up. The healthiest relationships I have had with my own managers were ones where I could disagree clearly and they could overrule me cleanly, and we both moved on without residue. The skill is to disagree on the substance while staying aligned on the goal, so the conversation never becomes about loyalty or ego.
My approach is to make the disagreement concrete and bounded. I say what I would do differently, why, what I expect to happen under each path, and what would change my mind. Then, critically, I name the threshold at which I will commit fully even if overruled. Disagree and commit is not a slogan to me; it is the thing that makes disagreement safe to express, because everyone knows it will not turn into sabotage or sulking.
There is a harder case: when you are asked to do something you believe is genuinely wrong, not merely suboptimal. In regulated work this is not hypothetical, and it is where managing up meets your actual values. I keep a private line that I will not cross regardless of pressure, around safety, compliance, and honesty with regulators. I have only had to invoke it a couple of times, and in both cases stating it plainly, early, and without theatrics changed the decision. The line exists precisely so that all the everyday flexibility above it stays healthy rather than corrosive.
Reading Your Manager's Context
You cannot manage up well without understanding the pressures on the person above you. My manager is also managing up, to a board, to investors, to peers whose cooperation she needs. When she pushes back on my timeline, it is often because she has made a commitment in a room I was not in. If I treat her pushback as ignorance, I will fight the wrong battle. If I treat it as a constraint to design around, I usually find a better path.
So I invest in understanding the context behind the asks. What did she promise, to whom, and by when? What does she get measured on this quarter? What surprised her recently that made her more risk-averse? None of this is manipulation; it is the same empathy I would extend to a downstream service whose constraints shape my API. The more accurately I model her situation, the more often I can offer options that solve her real problem and mine at once.
This is also where managing up stops feeling like submission and starts feeling like partnership. When I can anticipate the question my manager will get from the board and hand her the answer before she has to ask me for it, the dynamic inverts. I am no longer being managed; I am extending her reach. That is the version of managing up that does not cost you anything, because it is just good engineering applied to a human system.
Preserving the Engineer Inside
The part I had to learn deliberately is how to do all this without the technical core of me quietly atrophying. It is easy, once you are good at the upward conversation, to drift into a role where you only ever talk about work rather than understand it. That drift is how leaders lose the very judgment that made them worth listening to. I have watched capable people become fluent narrators of systems they no longer actually comprehend, and the gap is invisible until a crisis exposes it.
I protect against this with small, non-negotiable habits. I still read the postmortems in full, not the summaries. I still sit in design reviews where I am the least knowledgeable person and ask the dumb questions out loud. I do not write much production code anymore, and pretending otherwise would be its own kind of distortion, but I keep enough hands-on contact that my upward translations are grounded in something I have actually touched. The translations are only honest if the source is real.
There is an identity claim underneath all of this. I refuse to define myself by how I am perceived upward, because a self built on perception is brittle and anxious. I define myself by whether the systems my team owns are sound and whether the people on it are growing. Managing up is a service I perform in support of those things, not the thing itself. Keeping that ordering straight is what lets me do the upward work fully without it hollowing me out.
Conclusion
Managing up without losing yourself comes down to a few stubborn commitments: translate resolution but never facts, hold a written line of things you will not soften, build trust through calibration rather than drama, disagree on substance while committing on direction, and keep your hands close enough to the real work that your words stay true. None of this requires you to become someone you would not respect. It requires the opposite, a clear enough sense of who you are that you can flex everything around that center without ever touching it. Do that consistently, and managing up stops being a tax on your integrity and becomes one more system you are responsible for keeping honest.