Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design Patterns for Managing Up

queue.acm.org

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Design Patterns for Managing Up

#31

Post by tchaffee »

thesumofall wrote: post #20

I believe the better approach to #1 is to: - say that you’re not sure - articulate an hypothesis of what it might be to the best of your knowledge (it's likely you’re going to be 80% right) - propose to launch an effort / work stream / project to figure it out In many cases managers are just happy with an 80% answer and will reject to waste efforts to dive deeper. Managers can deal with uncertainty and with situation…

> articulate an hypothesis of what it might be to the best of your knowledge (it's likely you’re going to be 80% right)

Please don't do this. Many managers and clients have a far better bullshit detector than you give them credit for. They might never say it directly to you, but you just lost their respect by trying to guess instead of being honest. When programmers I interview try to bullshit their way through an answer they clearly don't know, it's almost always the end of the interview. Especially because I make it super clear at the beginning that I prefer "I don't know". A solid "I don't know but I do know I can get you an answer or an update in a couple of hours" is the approach that earns my respect every time. And likely you'll be right 100% of the time with that answer.

Re: Design Patterns for Managing Up

#32

Post by danaris »

thesumofall wrote: post #20

I believe the better approach to #1 is to: - say that you’re not sure - articulate an hypothesis of what it might be to the best of your knowledge (it's likely you’re going to be 80% right) - propose to launch an effort / work stream / project to figure it out In many cases managers are just happy with an 80% answer and will reject to waste efforts to dive deeper. Managers can deal with uncertainty and with situation…

> - propose to launch an effort / work stream / project to figure it out

...This is only applicable if it's something major, that would require research or experimentation, rather than "let me go talk to Drew after this meeting" or even "I'll look it up on Wikipedia."

I suspect that those would cover a majority of the cases of this.

Re: Design Patterns for Managing Up

#33

Post by Arubis »

motohagiography wrote: post #3

Concise articulation, and valuable. My comment is that this is happy-path advice. Corporate culture has changed to where instead of handling conflict according to principle (e.g. Harvard negotiation project, getting to yes, principled negotiations etc), today people are trained to out-passive each other, and marshal political campaigns to isolate opposition. (salience, political survival, working the ref, etc.) The m…

I’d recommend the works of Venkatesh Rao: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-... https://www.ribbonfarm.com/be-slightly-evil/

Re: Design Patterns for Managing Up

#34

Post by maroonblazer »

I disagree with #4, your manager giving negative feedback.

Asking a manager to clarify the feedback shouldn't put that manager on the defensive. If the manager hasn't gone to the trouble of getting those details then they need to be educated on how to deliver negative feedback.

Instead of simply saying "I hear you. I will be more mindful of that in the future.", a more productive response would be:

"Based on what you've shared it's not clear to me exactly what I did wrong or how I might do things differently in a similar situation in the future. Are there additional details you can share? Can you get those details so that I can make this a part of my learning plan?" What advice do you have for me for how to better handle this situation in the future?"

You've now educated the manager as to what level of detail you need when it comes to feedback. They should know that they can't just toss incoming feedback over the transom. They need to dig into the details and do what it takes to help you grow.

Re: Design Patterns for Managing Up

#35

Post by falcor84 »

james_s_tayler wrote: post #6
PaulHoule wrote: post #4

Earlier quoted context omitted.

Sometimes when the "knives are out" you can't win or why would you want to?

Well you at least don't want to bring a pillow to a knife fight.

Actually, wouldn't a pillow be a reasonably effective way to deflect a knife?

Re: Design Patterns for Managing Up

#36

Post by bicubic »

Is there any similar themed advice for managing same-seniority coworkers handballing their responsibilities?

Person A owns task

Person A: I don't know much about task, but person B seems like an expert. Person B, please take over task

Person B is no more or less qualified at task than person A

Re: Design Patterns for Managing Up

#37

Post by lolptdr »

bicubic wrote: post #36

Is there any similar themed advice for managing same-seniority coworkers handballing their responsibilities? Person A owns task Person A: I don't know much about task, but person B seems like an expert. Person B, please take over task Person B is no more or less qualified at task than person A

Perhaps you shouldn't allow handover of such responsibility or tasks. Force Person A to own task but allow Person B to assist Person A. Surely Person A won't mind help Frontera on B.

Re: Design Patterns for Managing Up

#38

Post by rocqua »

tchaffee wrote: post #31
thesumofall wrote: post #20

I believe the better approach to #1 is to: - say that you’re not sure - articulate an hypothesis of what it might be to the best of your knowledge (it's likely you’re going to be 80% right) - propose to launch an effort / work stream / project to figure it out In many cases managers are just happy with an 80% answer and will reject to waste efforts to dive deeper. Managers can deal with uncertainty and with situation…

> articulate an hypothesis of what it might be to the best of your knowledge (it's likely you’re going to be 80% right) Please don't do this. Many managers and clients have a far better bullshit detector than you give them credit for. They might never say it directly to you, but you just lost their respect by trying to guess instead of being honest. When programmers I interview try to bullshit their way through an an…

He's not suggesting "Guess and pass it of as true".

Instead, the idea is to say "Well, I am not sure. However, If I had to guess, I'd say X" where X is your best guess. You can follow up with "If needed, I could find out for sure in {time-frame}"

Re: Design Patterns for Managing Up

#39

Post by thesumofall »

tchaffee wrote: post #31
thesumofall wrote: post #20

I believe the better approach to #1 is to: - say that you’re not sure - articulate an hypothesis of what it might be to the best of your knowledge (it's likely you’re going to be 80% right) - propose to launch an effort / work stream / project to figure it out In many cases managers are just happy with an 80% answer and will reject to waste efforts to dive deeper. Managers can deal with uncertainty and with situation…

> articulate an hypothesis of what it might be to the best of your knowledge (it's likely you’re going to be 80% right) Please don't do this. Many managers and clients have a far better bullshit detector than you give them credit for. They might never say it directly to you, but you just lost their respect by trying to guess instead of being honest. When programmers I interview try to bullshit their way through an an…

This is absolutely _not_ about bullshitting your way out of it. Far from it. It is about articulating an hypothesis (based on your experience) of what the answer is most likely to be. It is saying: "We're not yet sure why the server crashed, but from my experience it is most of the times the A/C system, for which I would suggest checking the logs now". It is honest, articulates a way forward, and might in many meetings just be sufficient to keep the discussion moving forwards. Again, it is the job of a manager to deal with controlled uncertainty.

Re: Design Patterns for Managing Up

#40

Post by tchaffee »

rocqua wrote: post #38
tchaffee wrote: post #31

Earlier quoted context omitted.

> articulate an hypothesis of what it might be to the best of your knowledge (it's likely you’re going to be 80% right) Please don't do this. Many managers and clients have a far better bullshit detector than you give them credit for. They might never say it directly to you, but you just lost their respect by trying to guess instead of being honest. When programmers I interview try to bullshit their way through an an…

He's not suggesting "Guess and pass it of as true". Instead, the idea is to say "Well, I am not sure. However, If I had to guess, I'd say X" where X is your best guess. You can follow up with "If needed, I could find out for sure in {time-frame}"

Fair clarification. I don't appreciate that approach either. Just go find out what the problem is and report back. Unless someone specifically asks you to guess, you are just wasting everyone's time. And in a meeting with clients and upper management, that could add up to $$$ thousands per hour. "If I had to guess". You usually don't have to. So don't do it. Just my $0.02. Maybe other managers see it differently.

EDIT: I should clarify why this often goes badly. "If I had to guess, it's the filter in the gas line". Now everyone thinks it's a $20 problem, and they appreciate having an expert like you around to help them mentally frame the extent of the problem. When you come back with "actually the entire engine is warped and needs to be replaced", everyone is going to be disappointed. Like it or not, that disappointment is attached to you now. Trust is lost. There is almost nothing ever to be gained from guessing.

Post reply on HN