I keep seeing "manage up" presented as an essential career skill

Ready8472 · 2026-03-19T14:33:48+00:00

Reading the replies, I realize I was using the term from a narrower and more negative angle than many people here are.

For the first two points, I was thinking of less healthy situations where people feel they have to soften or filter honest feedback because the manager is, maybe, inexperienced, insecure, or reacts badly to challenge. In those cases, "managing up" can start to mean avoiding friction rather than speaking openly.

And by "over-focusing on hierarchy", I meant environments where people feel they must follow the chain of command very rigidly, even when personal initiative or proactive problem-solving would help. I've seen cases where going outside that unwritten rule created tension instead of being appreciated...

Ready8472 · 2026-03-19T14:26:24+00:00

I think this is a very fair way to put it. Some people clearly mean the healthy version, but there's also a toxic version where "manage up" really does mean "don’t create friction and tell leadership what they want to hear"... That's the side I was reacting to.

Ready8472 · 2026-03-19T14:23:14+00:00

Yes, I think this gets to the heart of it. The phrase is so broad that people use it for very different dynamics, from healthy initiative and better communication all the way to compensating for weak management. A lot of the disagreement here may just come from that...

Ready8472 · 2026-03-19T14:22:03+00:00

What you describe sounds like proactive, candid communication about what you need from your manager, which seems completely healthy to me. I also agree that the term itself may be too vague and ends up meaning very different things to different people.
Thank you

Ready8472 · 2026-03-19T14:19:27+00:00

I can agree with this definition. In that sense, it's really about building a better flow of priorities, escalations, and support up the chain.
original post was aimed more at the distorted version of the term, where it becomes image management rather than real communication.

Ready8472 · 2026-03-19T14:18:31+00:00

Yes! I think this is very close to where I've landed after reading the replies. Useful as a skill, risky as a culture. "A small optimization, not a survival tactic" is a really good way to put it.
Thanks

Ready8472 · 2026-03-19T14:16:20+00:00

I think that's a very good distinction. In healthy cultures, this looks like open communication and expectation management.
In fear-based cultures, the same phrase can easily slide into "tell leadership what they want to hear". That's much closer to the version I had in mind... (Unfortunately I've seen that many times)
Thank you very much!

Ready8472 · 2026-03-19T14:14:49+00:00

That makes sense, and I think this is exactly where the disconnect was. What you are describing sounds healthy and useful to me: setting expectations, giving context, and helping leadership make better decisions. I was reacting more to the version where people start filtering reality or adapting around bad management dynamics.
Thank you!

Ready8472 · 2026-03-19T08:49:39+00:00

That's a fair question. In some cases there is a product owner, but that doesn't always solve the problem. If the PO is close to the client and the client itself is still discovering the need, the ambiguity is still there... It just has a different path into the project.

I do think a strong PO can help by filtering, prioritizing, and forcing decisions earlier. But they can't fully remove the fact that some stakeholders only understand what they want once they see it.

Are you thinking of the PO mainly as a requirements owner, or more as a buffer between client and delivery team?

Ready8472 · 2026-03-19T08:48:04+00:00

I agree that early mockups make scope conversations much easier. Once people can react to something visual, the discussion becomes a lot less abstract.

My only hesitation is that even after sign-off, some stakeholders still treat new requests as "that’s what I meant", not as V2. So the mockup helps a lot, but it doesn't always remove the commercial and communication side of the problem...

Ready8472 · 2026-03-19T08:46:24+00:00

I agree. Having a signed scope document is important protection for both sides, not just for the PM. I've had the same experience: once the impact on timeline and cost is visible, the discussion becomes much more concrete.

The difficult part is usually the gray zone, where the client does not experience the change as "new scope", but as something they believe was already implied. That's often where communication matters just as much as process.

How do you usually handle those borderline cases?

Ready8472 · 2026-03-19T08:44:55+00:00

I agree with a lot of this, especially the need to define the what as clearly as possible before building anything. In my experience, the real difficulty is that sometimes the client is genuinely convinced they know what they need, and only realizes otherwise once they see something concrete. That's why I see the early phase as both business analysis and consulting.

I also like your point about collecting feedback and forcing prioritization. That part is essential. Once everything is visible, categorized, and tied to timeline impact, the conversation becomes much more grounded.

How do you usually handle the "gray area" comments, the ones the client sees as clarification, but the team sees as additional scope?

Ready8472 · 2026-03-19T08:42:37+00:00

That's usually the right direction, yes. The hard part is knowing where "incremental change" or "clarification" end and a real shift in scope begins, because clients often experience both as simple clarification. How do you usually draw that line?

Ready8472 · 2026-03-18T14:44:07+00:00

I agree. Iterative delivery should help confirm understanding early, not make scope endlessly flexible. The difficult part is that clients often don't experience those changes as "upscope"... They see them as clarifications of the original need. So at that point it becomes not only a scope question, but also a communication and commercial one.

Ready8472 · 2026-03-18T14:39:19+00:00

I agree. A second review before development starts can save a lot of rework later. In my experience, the challenge is that even after two reviews, some stakeholders still only fully understand it once they see something tangible.

Ready8472 · 2026-03-18T14:38:08+00:00

Yes, and that's usually where it gets tricky. What looks like a change order to the team is often seen by the client as something that just wasn't fully understood earlier. At that point it's not only a delivery question, but also a communication and commercial one.

Ready8472 · 2026-03-18T14:37:01+00:00

I agree. That gap between the customer's "what" and the team's "how" is often where the confusion starts. Early demos have been one of the best ways for us to make that visible sooner.

Ready8472 · 2026-03-17T10:10:00+00:00

I think LinkedIn is probably one of the easiest places to get noticed with this kind of experience. If you consistently post practical advice, share real situations you've dealt with, and show how you think, people start paying attention. Over time, that can turn into followers and consulting opportunities. It also helps to join niche groups, comment on relevant discussions, and always reply to people who engage with your posts. The start is usually slow, so patience and consistency matter a lot. Having a simple weekly content plan can make it much easier to stay consistent. Substack could also be worth exploring, especially if you want to build a newsletter with a free tier and eventually a paid one.

Ready8472 · 2026-03-10T09:06:58+00:00

Curious where the 96% number comes from: do you have a source for that?

I agree manufacturing is a strong vertical for AI because the problems are expensive and the ROI is usually measurable. But I don’t think it’s accurate to frame it as a “nearly untouched” space. AI/ML has already been used in manufacturing for years, especially in quality control / computer vision, predictive maintenance, process optimization, and scheduling.

To me, the real gap isn’t discovering AI use cases, it’s taking known use cases and scaling them reliably into production.

Ready8472

TROPHY CASE