Managing Up in Technical Organisations: A Practitioner's Guide
Godfrey Maiwun · January 2026 · Leadership · 9 min read
Managing up is one of the skills most conspicuously absent from technical training programmes. It is also one of the most consequential for career progression — and for the quality of work that technical teams are able to do. A technical practitioner who cannot manage upward effectively will consistently find themselves fighting for resources, losing priority battles, and discovering that decisions were made without their input.
What managing up actually means
Managing up does not mean flattering your manager or telling them what they want to hear. It means taking active responsibility for making the relationship between you and your manager, and between your team and senior leadership, work well — in the service of better outcomes, not personal advancement.
It means understanding what your manager needs to make decisions, and providing it in the form they can use. It means building trust during calm periods so that you have credibility in a crisis. It means knowing when to escalate and when to absorb — and getting that calibration right consistently enough that your manager trusts your judgement about it. It means making your manager's job easier by handling the things you are equipped to handle without being asked.
The translation problem
The most fundamental managing-up skill in technical organisations is translation: converting technical complexity into the language and level of detail that a non-technical executive can act on. This is genuinely difficult because the information that matters at the technical level is not the same information that matters at the executive level — and the instinct of many technical practitioners is to bring technical leaders into the technical detail rather than translating up.
Converting technical complexity into the language executives can act on.
A useful test: if your status update contains the words "latency," "P99," "schema migration," or "idempotency" without accompanying translation, you are writing for an engineer, not for an executive. The executive question is not "what is the technical problem?" It is "what is at risk, what will it cost to address it, and what decision do you need from me?"
The format that works: one sentence on what the situation is, one sentence on the business impact if unaddressed, one sentence on your recommended action, and the specific decision or resource you need. Everything else goes in a supporting appendix that executives can read if they choose to. This format is uncomfortable for technical people who are used to establishing context before conclusions. It is comfortable for executives who make ten decisions before 10am.
Your job is not to make your manager understand the technical problem. It is to give them everything they need to make the right decision without needing to understand it. Those are different tasks, and conflating them produces briefings that are accurate but not useful.
Building trust before you need it
Trust in a management relationship is built in ordinary times and spent in crises. The practitioner who surfaces good news, bad news, and uncertainty with equal candour — consistently, before they become urgent — builds a reservoir of credibility that allows them to bring genuinely difficult situations to leadership without their judgement being questioned.
The specific practices that build this reservoir: delivering on commitments reliably, or flagging early when delivery is at risk. Surfacing problems with recommended solutions rather than problems alone. Being accurate about confidence levels — distinguishing between "I know" and "I believe" and "I am not sure." Acknowledging mistakes directly rather than explaining them away. None of these are heroic acts. They are consistent behaviours that compound over time.
The inverse is also true: trust is eroded by small, consistent failures. Being slightly late on commitments without flagging it. Presenting uncertainty as confidence. Downplaying risks that later materialise. Over time, these accumulate into a pattern that makes leadership less willing to trust your assessments — precisely when you need that trust most.
The escalation calibration
Knowing when to escalate is one of the most difficult judgements in a technical role, and the consequences of getting it wrong in either direction are significant. Under-escalating — handling things below your level when they needed leadership visibility — results in surprises that erode trust. Over-escalating — bringing everything to leadership rather than handling what you are capable of handling — creates a dependency pattern that signals lack of judgement and consumes leadership attention.
Know when to absorb and when to escalate — the judgement that defines careers.
The calibration is contextual, but some principles are consistent. Escalate when the situation has business risk beyond your authority to manage — financial exposure, legal exposure, reputational risk. Escalate when a decision requires resources or authority you do not have. Escalate early enough that leadership has options, not late enough that their only option is damage control. Do not escalate when the situation is within your scope to resolve and you have a clear path to resolution.
When you do escalate, escalate with a recommendation. "I need your input on a situation" and "I have a situation where I recommend X, and I need your support to execute it" are very different escalations. The second one is easier for leadership to act on, signals that you have done the analytical work, and maintains your standing as a person with judgement rather than as someone who brings problems without solutions.
Navigating difficult conversations upward
Technical practitioners often have significant expertise in areas where their non-technical managers have less — cloud architecture, cybersecurity, data engineering. This creates an asymmetry where the practitioner knows something important and the manager may not be fully equipped to evaluate it. Managing this asymmetry well is a specific skill.
The temptation when a manager makes a decision you believe is technically wrong is to assume they do not understand and to correct them. Sometimes that is true. More often, they are incorporating information or constraints you do not have visibility into: budget discussions, organisational politics, strategic context. Before concluding that a bad decision was made from ignorance, ask the question: "Is there context I am missing that informed this call?"
When you genuinely disagree with a direction: state your disagreement clearly and once, with your reasoning, at the decision point. Provide the information your manager needs to understand the risk. Then support the decision if it stands, and track the outcome — because if you were right, that data will inform future conversations, and if you were wrong, you will have learned something.
"Disagree and commit" is not capitulation. It is the professional stance of someone who has offered their input, had it considered, and is now aligned behind the team's direction. The alternative — ongoing low-level resistance to a decision that has been made — is destructive to teams, relationships, and your own reputation for reliability.
Filed under: Leadership