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

61–69 of 69 posts

Re: Design Patterns for Managing Up

#61

Post by tchaffee »

barrkel wrote: post #48
tchaffee wrote: post #40

Earlier quoted context omitted.

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. EDI…

You sound like a person who has difficulty operating in an uncertain environment. Sometimes certainty is expensive. In fact, in my experience with complex systems, it usually is. Depending on what you're uncertain about, you may need to modify the system to measure it. Resolving uncertainty can take a long time, particularly if the thing you're trying to be certain about is a rare event or cannot easily be isolated.…

> You sound like a person who has difficulty operating in an uncertain environment.

Not at all. I deal with uncertainty all the time. What I don't like is people inventing answers, just so they have an answer. I think you'll find this "intolerance" increasingly as you deal with people higher and higher up in management. People's time becomes increasingly the most expensive factor by far. Let's stay focused here. That paragraph in the article is advice about what to do when "someone asks you something you don't know". I'm still firmly in the camp of a simple "I don't know, but I will find out for you." YMMV.

Re: Design Patterns for Managing Up

#62

Post by motohagiography »

drharby wrote: post #29
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…

You just described working in a tech org of a major IB

Indeed, turns out I may also have described "gaslighting," https://www.psychologytoday.com/ca/blog/here-there-and-every... , which is perhaps why I sound so grouchy.

Like a startup whose leadership in effect says, "we just raised way too much money and have no path to market fit, let's just gaslight the talent until they attrition out and we can blame them for the time lost, while hopefully our competitors will establish a market where then the board can find a greater fool to buy us before we have to raise another round."

Please, help me be wrong. :)

Re: Design Patterns for Managing Up

#63

Post by tchaffee »

thesumofall wrote: post #39
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…

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 meetin…

That's not the situation described in the article. The situation described in the article is pretty specific: Someone asks you something you don't know. It's right in the title. And it goes on to describe a situation in which you may end up making up something on the spot, trying to be as vague as possible so you can't be wrong.

So yes, if your hypothesis is just something you made up only so you can have an answer, then please don't do that. I don't care how solid the guess is. It's still a guess just to have an answer.

In the situation you described, you do know something and you're sharing that knowledge. I have no problem with people sharing that knowledge. It's not a hypothesis. It's the opposite of "you don't know". It's knowledge about the history of the situation.

Re: Design Patterns for Managing Up

#64

Post by yeahitslikethat »

flyinglizard wrote: post #44
yeahitslikethat wrote: post #12

Earlier quoted context omitted.

You're higher up the food chain than the audience of that article. Just keep doing your job better than they do their job and vent to allies behind closed doors. There's a guy on our team who does #1 one in the article ALL the time. NNP who slows the team by 25% probably. No one knows how to make him stop. Everyone is politely tapping on his fishbowl and it hasn't worked yet for like months.

The real power play is to confidently and assertively state “I don’t know, I’ll get back to you in X hours with an answer” and be on point with the timing. Someone that promises and delivers on time causes people to melt and program managers to fall in love.

What do you say to the person who won't do that?

Re: Design Patterns for Managing Up

#65

Post by wsy »

yanslookup wrote: post #45

Question for the crowd: how to manage up a politically savvy skip manager that routinely trivializes engineering effort? They couch it in sarcasm, something like "oh you can build that in like 2 minutes, it's just an SQL query and 3 lines of python, right?"

This manager wants to make you smaller, so that he can look bigger and exert more power. In my experience, the only way to counter is by also making a strong gesture. For the dialog you sketched, possible responses could be "Then you can surely do it yourself in 2 minutes". Another, more aggressive, option would be to answer "this joke gets old". You need to find your own tone, obviously, which should not be agitated-aggressive, but make clear that he now has an opponent, and you will not be an easy victim for his power games.

Obviously, this is a risky approach; only do it if you can afford switching jobs. But in my experience it is less risky than it looks. Bullying persons have a good sense of their opponent's strength, and will rather look for new easy targets than going into a serious fight. If you can talk to your team mates and make this a team stance, this will of course strengthen your position further.

Re: Design Patterns for Managing Up

#66

Post by rwallace »

Good article! I agree with most of it.

However,

'As a leader, you don't want to tell your team that the reason things are changing is "because _ made me do it." That makes it seem like you have no power, as though you do things just because you are told to. It certainly won't inspire confidence in your team or make them any more likely to embrace the decision.'

Are you sure?

Do you really want to tell your team "We are painting the building purple because fairies love the color purple and will bring us good luck"? Especially when your team already knows you personally don't believe in fairies?

It seems to me "Look, the CEO is firmly committed to the belief in fairies, and has made the policy decision that we are going to paint the building purple. It's up to us to implement that decision," is the least bad thing to say in that situation.

Re: Design Patterns for Managing Up

#67

Post by imhelpingu »

Or instead acting like personal PR is your only contribution to the species, you can just say reasonable things that make sense including things like "I don't know" on a circumstantial basis using your human brain and social instincts.

Re: Design Patterns for Managing Up

#68

Post by alexk »

yanslookup wrote: post #54
alexk wrote: post #51

Earlier quoted context omitted.

I think you would find negotiation practices helpful, e.g. check out the book "Never split the difference" to learn some negotiation techniques and "Elephant in the brain" to understand that this behavior is likely not about technology.

It's not a negotiation in good faith because they are "just joking man!"

As someone who actually builds things you have more leverage than you think in this or any other conversation with your manager, you need to learn how to use it better.

Re: Design Patterns for Managing Up

#69

Post by Joof »

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

Person A may legitimately view person B as more qualified. Whether or not this is true.
Post reply on HN