Cruxly

Cruxly › Behavioral › Competencies

Managing Up

you changed what your manager knew, decided, or protected you from

Open the interactive lesson

What is scored: can you get a manager the information or support you need without waiting to be asked, and without going over their head?

The trap is a story where "managing up" means agreeing with everything and never surfacing bad news — which is the opposite of the competency.

What the interviewer is looking for

This is frequently confused with simply being easy to manage, which is not the competency. What is actually being scored:

  1. You surfaced bad news early, unprompted. The single clearest signal. A manager who hears about a risk in week two can act on it; one who hears at the deadline cannot.
  2. You gave your manager what they needed to do their job, not just what made you look good — status that includes the parts that are going badly, framed usefully rather than either sugar-coated or dumped as a complaint.
  3. You made a decision easier for them, by doing some of the thinking yourself. Bringing a problem with two options and a recommendation is managing up; bringing a problem with no options is not.
  4. You disagreed with them constructively when it mattered, rather than deferring by default or working around them silently.
  5. You adapted to how they actually operate — some managers want detail, some want headlines; noticing which, and adjusting, is part of the skill.

The through-line across all five: you treated your manager as someone you were actively helping succeed, not just someone you reported to.

Weak and strong, same prompt

Prompt: tell me about a time you had to manage up.

Weak.

"My manager was very busy, so I made sure to keep my status updates short and only escalate things that were truly urgent. I think this made things easier for them and we had a good working relationship."

No event, no specific instance of information moving, no evidence anything changed because of what you did. This is a description of being considerate, not a story about managing up.

Strong.

"About six weeks into a project, I realized the estimate I'd given my manager at kickoff was wrong — not by a little, by roughly double, because I'd scoped it before we knew a dependency team's API didn't support batch writes, which meant an architecture change. My manager had already told her director we'd ship by a specific date, in a roadmap review I wasn't in. I could have kept working and hoped to claw back the time, or waited for the next scheduled 1:1, which was five days out. I asked for fifteen minutes that day instead. I brought the number, the reason, and two options: cut scope to hit the original date, or take the full timeline with the batch-write limitation removed from this release and handled next quarter. I had a recommendation — the second — but I made sure she had enough to make her own call, because it was her relationship with the director that was on the line, not mine. She took the second option and told her director within the day, which meant the miss was communicated as 'we found a real constraint and adjusted the plan' rather than 'the team is late.' She specifically thanked me afterward for not waiting for the 1:1 — she said the five days would have mattered if she'd found out later, since the review cycle with her director was weekly. What I'd do differently: I should have flagged the dependency risk in week one, when I first noticed the batch-write question was open, rather than waiting until I'd confirmed it was actually a problem. I sat on an unconfirmed risk for a week because I didn't want to raise a false alarm, and that week turned out to matter."

A specific number that was wrong, an unprompted request for time rather than waiting for the scheduled slot, options plus a recommendation rather than just a problem, and a named reason the timing specifically helped the manager — not just "I told them early" in the abstract.

Question bank

"Your manager was wrong about something" is the sharpest version of this prompt and the one candidates most often soften into a non-answer. The strong pattern is the same as challenging any other technical decision: state the disagreement, the reasoning, and what you'd need to see to change your mind — the fact that it's your manager does not change the mechanism.

Where these answers go wrong

Compliance mistaken for the competency. A story about always doing what your manager asked, cheerfully, is not managing up — it is being agreeable, which is a different and much weaker thing to be scored on.

Bad news delivered late, or not by you. If the manager found out from someone else, or found out at the deadline, the story demonstrates the opposite of the competency, no matter how the rest of it is framed.

No options, just a problem. Bringing an unscoped problem to a manager and waiting for them to solve it is what a junior engineer does. The senior version arrives with a recommendation, even one they are free to overrule.

Going around, not up. A story where you escalated over your manager's head to their manager, without your manager knowing first, reads as a trust violation unless the story explicitly addresses why that was necessary — and it needs a very good reason.

Vague timing. "I told them pretty early" without a specific comparison — what would have happened if you'd waited — does not demonstrate that the timing mattered. The strong version names the alternative and its cost.

How to say it in the interview

"I did not wait for the 1:1. The scope had changed enough that a week's delay in telling him was a week he couldn't use to manage expectations upward himself."

Checklist

Practice this interactively
Share this lessonWhatsAppLinkedInX

Related lessons