[HN Gopher] Project managers, ducks, and dogs marking territory ...
       ___________________________________________________________________
        
       Project managers, ducks, and dogs marking territory (2013)
        
       Author : lutrinus
       Score  : 119 points
       Date   : 2023-11-22 09:13 UTC (13 hours ago)
        
 (HTM) web link (rachelbythebay.com)
 (TXT) w3m dump (rachelbythebay.com)
        
       | scrapheap wrote:
       | Quite often the person believes they are helping with their
       | suggestions (or at least that's what I believe when I'm the one
       | doing the suggesting). But there is certainly better and worse
       | ways to make those sort of suggestions.
       | 
       | On the other hand, I quite often don't bother rounding the
       | corners of boxes when working on a web UI until one of the last
       | things. That way anyone who just wants to make their mark can
       | just suggest rounding the corners :D
        
         | notahacker wrote:
         | That works up until the point someone says they love the
         | squareness of the boxes ;-)
        
           | mannykannot wrote:
           | You win either way, so long as you don't care which way the
           | decision goes.
        
       | CapitalistCartr wrote:
       | Yup, I call that Wolf Management for the same reason.
        
       | smeej wrote:
       | I tend to interpret this as a sure sign of a manager who secretly
       | knows they're useless.
       | 
       | If you're the manager, your job isn't to do my work. Your job is
       | to optimize my (and the rest of the team's) ability to do our own
       | work. If I've missed something that should be part of a
       | procedure, that should be in a checklist I should have reviewed
       | before submitting my work. You shouldn't have to tell me to tweak
       | it.
       | 
       | If I'm handing the work off to a team that is responsible for
       | small stylistic choices, they too should have a set of standards,
       | but at least if they change their minds about something, that's
       | their role and their job.
        
         | crispyambulance wrote:
         | Things change all the time. People, including managers, are
         | human and specs aren't something that always can be "carved in
         | stone" in advance and carried out to perfection.
         | 
         | There certainly are pathological situations where people really
         | do need to leave a mark and that's why "the duck" technique
         | that Rachel described works.
         | 
         | This pops up in presentations too. Sometimes you know in
         | advance that your presentation is going to have an audience
         | with one or more "well, actually..." types who will try to poke
         | holes a little too aggressively in your argument.
         | 
         | One technique for handling this is to deliberately leave out
         | some persnickety detail in your deck, but cover it exhaustively
         | in an auxiliary slide that you don't show unless someone points
         | out the omission. It works great. Every. Time.
        
           | steveBK123 wrote:
           | Sometimes the purpose of those decks is really just to get
           | stakeholders to think out loud and express what they actually
           | want. A lot of these execs seem incapable of doing so without
           | being shown something they don't want first.
           | 
           | So often theres no reason for a deck to be more than 3 slides
           | because it will immediately derail and turn into an airing of
           | actual needs.
        
           | sokoloff wrote:
           | A tip for presentations: in presentation mode in both
           | Powerpoint and Slides, if you type the slide number and press
           | enter, the presentation will jump to that slide.
           | 
           | If you have notes about which auxiliary slide is relevant to
           | which persnickety comment/topic, you can seamlessly warp to
           | it and it hits harder/makes you look more prepared/polished
           | than a bunch of page up/down and "I know it's here somewhere"
           | filler speech.
        
         | steveBK123 wrote:
         | Yes, I've worked for a couple guys in my career like this.
         | Typically they would bet absolutely unhinged about things like
         | grammar in emails, code style, PR nitpicks, or how the teams
         | wiki looked.. while having no actual input on the teams user
         | facing work product .
         | 
         | It's a good way to demotivate the team into slowing down the
         | trains.
        
       | austin-cheney wrote:
       | A prior thread: https://news.ycombinator.com/item?id=9137736
        
       | preinheimer wrote:
       | I used to live in Montreal. Cabs there need to get a safety
       | inspection like every 6 months.
       | 
       | Talking to some cab drivers there, many of them remarked that the
       | people doing the safety exam -had- to find something. Your car
       | could have been fresh from the mechanic, they'd find something to
       | complain about.
       | 
       | So, starting about 6 weeks out from their next safety, if
       | something went wrong but the car was still drivable, they
       | wouldn't fix it. So the safety guys had something to find, and
       | they were going to pay to fix it anyways.
        
         | resonious wrote:
         | It's bad but I consider doing this for code review sometimes.
        
           | ysavir wrote:
           | I tend to do this in code review. But what I consider
           | critical is that it comes without a "I want this changed"
           | mentality, and instead a "let's find something we can improve
           | on for next time" mentality. The current PR can go in as-is,
           | but we should aim for always getting better at the craft.
        
           | mejutoco wrote:
           | This reminds me...many graphic designers knows to have a bad
           | version of a design. What they do not expect is the customer
           | picking that one. It explains some campaigns though
        
             | psunavy03 wrote:
             | It's not just graphic design. It's customary in military
             | planning to give the commander multiple possible courses of
             | action or COAs to choose from or blend together. But it's a
             | known danger when you're crunched for time that if you plan
             | a "throwaway COA" that's subpar or silly because the boss
             | wants X COAs and you can only come up with X-1, beware.
             | Because there's a chance the boss is going to moth off on
             | the throwaway COA.
        
             | gosub100 wrote:
             | https://en.wikipedia.org/wiki/The_Producers_(1967_film)
        
         | miroljub wrote:
         | Another example of "what you measure is what you get".
        
           | morkalork wrote:
           | And because they keep finding those obviously wrong things,
           | the program justifies itself!
        
         | notahacker wrote:
         | My boat is for sale. Most prospective buyers will get a marine
         | survey which will identify that among other minor things it
         | needs a new bilge pump.
         | 
         | If they don't pay for the survey I'll sort them out with a new
         | bilge pump anyway.
         | 
         | (This isn't an argument against surveyors though. Mine sorted
         | me out with a new gearbox and had half the boat rewired at the
         | vendor's expense)
        
         | brightball wrote:
         | One of my earliest bosses was the main web developer for a
         | telco's marketing department. He would get everything working
         | and ready the way that it needed to be, then prior to showing
         | it to marketing would change something to be clearly wrong. In
         | my example, he just put a red line down the middle of one
         | section that looked out of place.
         | 
         | Marketing would review it and say, "Everything looks good,
         | let's just change that red line there. Thanks!"
         | 
         | I asked him why he did that and he said that if he didn't give
         | them something obvious to change, they would find something
         | that was working that didn't need to be changed.
        
           | sokoloff wrote:
           | The 2007-02-02 Dilbert applies: https://assets.amuniversal.co
           | m/9df021106cc801301d50001dd8b71...
        
             | mathattack wrote:
             | And Scott Adams also previously worked at a Telco.
        
             | begueradj wrote:
             | That's funny and a good summary
        
           | sambeau wrote:
           | I have a friend who works in games who would secretly add a
           | malloc to the initialisation code that would just hold onto a
           | large chunk of memory. Come the point just before release,
           | where everyone was desperately trying to fit the final assets
           | into memory, and about to throw stuff out, he would do an
           | 'optimisation' pass and free up the memory so they could ship
           | without delay.
        
             | groestl wrote:
             | Oh, "the balloon". A quite common technique.
        
           | miriam_catira wrote:
           | At one point, we (lead dev (me) and lead designer) colluded
           | to submit a terrible homepage design to a nit-picky CMO to
           | buy an extra 2wks of development time.
           | 
           | She'd given us 6wks to completely rebuild a small corporate
           | website, and we knew we needed at least 8 (it was still a
           | nearly impossible rush). She exhibited a classic micromanager
           | habit of the inexperienced: she needed/expected everything,
           | including copy layout, to be pixel perfect in Adobe before
           | any coding could start.
           | 
           | So the developers had the real design we knew she'd approve
           | already in development while the design team showed her the
           | version filled with ducks. She performed exactly as we
           | anticipated and work continued as though she was never
           | consulted. It was a risk, but she was extraordinarily
           | predictable in her duck removal...
           | 
           | It's not something I'd do to someone with an opinion I
           | respect. Thankfully she left right after that. Probably with
           | a story of how she single-handedly saved the redesign
           | herself, but whatever. ;)
        
           | redler wrote:
           | "We love the red line concept! Can you please work that into
           | the rest of the design?"
        
         | faet wrote:
         | This is how it is in some motorsports series as well. I had a
         | teacher who was a mechanic for a racing team. They'd leave
         | something 'big' broken for tech so that the people would find
         | it, have them fix it. He said they'd miss a bunch of smaller
         | stuff, but would feel accomplished for finding the 'big' error.
        
         | taeric wrote:
         | I have this same problem with a lot of review culture at many
         | companies. Turns out, if you send people into a meeting with
         | the idea that they will be criticizing something, they will
         | find criticisms. The hard part is distinguishing things that
         | need changing, versus musings that are as much evidence that
         | the team was looking.
        
       | culebron21 wrote:
       | I remember an interview from Soviet cinema director Georgii
       | Daneliya, mentioning that to make their movie pass the approval
       | committee intact (what you'd call "censorship"), they'd make
       | absurd and provocative "sacrifice" episodes (like "sacrifice
       | bolts"). The episodes were fought over and finally seceded to the
       | committee, but the rest of the film went into the theaters.
       | 
       | (Movies had to pass two such committees: one before production,
       | approving the scenario, and the other one approving the final
       | cut.)
        
         | zeroonetwothree wrote:
         | I think by scenario you mean "script" (that's the typical way
         | to say it in English).
        
           | ethanwillis wrote:
           | I don't know if that's necessarily what was meant. But I
           | could easily envision needing to even get the idea (scenario)
           | approved before even being allowed to actually write a full
           | script.
           | 
           | Keep in mind, just _producing_ certain written works was
           | justification enough to be killed.
        
       | roter wrote:
       | When I was finishing my PhD thesis, the suggestion was to insert
       | some low-hanging fruit for the reviewers who would be doing only
       | a cursory review but would need to find their "duck". Didn't do
       | it because my committee was excellent and didn't want to show any
       | disrespect.
        
         | justinpombrio wrote:
         | Yeah, I feel like PhD committee members often have the opposite
         | problem: you _want_ them to read the thing and suggest
         | improvements, but they 're too busy to give more than a skim. A
         | duck would just distract them.
        
       | raziel2p wrote:
       | Why is the PM the meddling one here, and not the artist who
       | (presumably un-prompted) added a duck to the game? Seems clear to
       | me that the artist was the one who wanted to leave their mark in
       | this story. Are some people allowed to and others not?
        
         | lloydatkinson wrote:
         | Unfortunately I think you've hit the nail on the head. Some
         | people ARE allowed while others are not. Sadly it seems the
         | most creative or involved people (devs, artists) are not while
         | a PM is.
        
           | dirtybirdnj wrote:
           | Class and status are one hell of a drug
        
       | matsemann wrote:
       | I learned of this from "New Programming Jargon" a decade ago on
       | codinghorror: https://blog.codinghorror.com/new-programming-
       | jargon/
       | 
       | I still regularly refer to Smurf naming conventions, Stringly
       | typed, Protoduction and others.
        
       | lloydatkinson wrote:
       | This is closely related to the "hairy arm technique" (it's known
       | by multiple names). This is where some people find it is
       | necessary to nitpick everything even when it is unnecessary and
       | the solution is to purposely make one aspect of some plan
       | obviously bad, dumb, or nonsensical.
       | 
       | The person will then insist that be removed, ensuring the actual
       | underlying work isn't impacted by their incessant pickiness.
       | 
       | I've had to use this technique myself a few times, mostly with
       | micromanagers/agile fanatics/product owners and the like.
        
       | marcinzm wrote:
       | I used to work at a startup whose clients worked on behalf of
       | large corporations. I once tried to automate some things to make
       | the company more money as our clients were rather inefficient at
       | their settings but got a lot of push back. Then I talked to our
       | clients and they said that unless they had knobs to turn to
       | "prove" they provided value they'd be fired by their clients (the
       | large corporations). If they got fired then they'd stop spending
       | money with us and so we'd actually make less revenue due to
       | second order effects. It was an enlightening experience.
        
       | wodenokoto wrote:
       | Man, I loved Battle Chess as a child. I would play with the aim
       | of finding new mach ups I hadn't seen, rather than try to learn
       | strategies for winning in chess.
       | 
       | And of course Youtube got us covered today:
       | https://www.youtube.com/watch?v=N7ccs3dRhW4
        
       | quietbritishjim wrote:
       | I think we can be a bit less cynical about this behaviour, at
       | least in some cases.
       | 
       | Perhaps a fresh pair of eyes is always going to notice a bunch of
       | potential changes, which would improve things from their
       | subjective point of view. But humans are notoriously bad at
       | absolute scales (see _Thinking Fast and Slow_ by Daniel Kahneman)
       | so it 's hard for us to decide "I can see a bunch of issues but
       | they're all below the threshold for changing". The top of the
       | scale is always what is most important out whatever issues are
       | left. Adding the duck reshapes the scale so all those other
       | things seem (correctly) trivial in comparison.
       | 
       | To put it another way, if the deadline is tight and the program
       | kept crashing, maybe they wouldn't have even asked to remove the
       | duck! The scale would have changed again, and the bit with the
       | duck on it would have been compressed below the threshold.
        
         | steveBK123 wrote:
         | I think that's a really great way to put it, but also not
         | something the majority of leaders (or people in general) are
         | capable of. Nothing is ever perfect, everyone has a different
         | opinion/view, at some point you need to wrap up a work product
         | and move on.
         | 
         | I found with a former manager the creation of project plans was
         | absolutely hell because of this. Arguably project plans are not
         | something directly deliverable to a stakeholder or with a firm
         | deadline. Sort of like politics in academia, the lower the
         | stakes the worst the battles.
         | 
         | So he would spin through 20 iterations of expressing his
         | discontents with the current plan.
         | 
         | Typical feedback was what he didn't like / was wrong, rather
         | than what he actually desired to see. Sort of like a very hands
         | off editor who doesn't want to write the book for the author.
         | 
         | Often times midway through he would be Don Quixote'ing items in
         | the plan that were added because of his earlier feedback.
        
           | moate wrote:
           | >>Don Quixote'ing
           | 
           | I realize there is no way to say this without sounding like
           | an absolute fucking dork, and this may be a syntaxial choice
           | you're making, but the phrase is "tilting at windmills".
           | 
           | I regularly say "irregardlessly" because it's fun and I know
           | better and if that's what you're doing here I love it and
           | it's amazing, but if not you've got a new phrase in your kit.
        
             | notpachet wrote:
             | > I realize there is no way to say this without sounding
             | like an absolute fucking dork
             | 
             | I don't think you needed this caveat. I appreciated being
             | reminded of the phrase.
        
       | wintorez wrote:
       | I'm dealing with this in almost daily basis. People are afraid of
       | not having an opinion and appearing stupid.
        
       | ulizzle wrote:
       | Bad form to remove the duck. Basically every project manager
       | ever. Somehow, "A.I" doesnt seek to replace them.
        
       | a_c wrote:
       | The flip side is equally true. People don't usually internalise
       | suggestion at face value unless they are in the right situational
       | mindset. For example, telling your colleague directly that making
       | a smaller pull request would make the review process easier may
       | fallen to deaf ears. But someday, maybe having reviewed other
       | colleague's PR, or maybe reading a blog of a famous professional,
       | the same colleague may suggest back to you the very same thing
       | you suggested 3 months ago.
       | 
       | There is nothing wrong people giving suggestion or opinion. It
       | takes taste to discern which suggestion has merit. And it take
       | experience to build up taste
        
       | D-Coder wrote:
       | "You have to give an editor something to change, or he gets
       | fretful. After he pees in it, he likes the flavor better, so he
       | buys it."
       | 
       | -- Robert A. Heinlein, _Stranger in a Strange Land_.
        
       | 99_00 wrote:
       | When I do code reviews I always try to find something to comment
       | on, even if it is just a optional suggestion or question.
       | 
       | If the code review system has a lot of approvals from me without
       | comments in the code review system I suspect it will hurt the
       | organization's perception of my work.
        
       | davio wrote:
       | When asked to review something, I like to use a version of Brene
       | Brown's question, "What does support look like?"
       | 
       | I can rubber-stamp, LGTM, proof-read, rip to shreds, etc. You
       | tell me what you want.
        
       | cushychicken wrote:
       | As someone whose job includes big components of both technical
       | work and project management, I can't help but wonder:
       | 
       | How frequently am I shown ducks?
        
       ___________________________________________________________________
       (page generated 2023-11-22 23:01 UTC)