Project managers, ducks, and dogs marking territory (2013)
rachelbythebay.comI 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.
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.
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. ;)
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.
Oh, "the balloon". A quite common technique.
The 2007-02-02 Dilbert applies: https://assets.amuniversal.com/9df021106cc801301d50001dd8b71...
And Scott Adams also previously worked at a Telco.
That's funny and a good summary
"The problem was that the women who were making the cakes didn't feel emotionally invested enough just adding water, he said. Eggs would make it feel more like baking. In later years, many would portray this as a pivotal moment in the history of cake mixes, the inflection point of a dramatic upward curve."
https://www.bbc.com/future/article/20171027-the-magic-cakes-...
"We love the red line concept! Can you please work that into the rest of the design?"
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)
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.
It's bad but I consider doing this for code review sometimes.
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
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.
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.
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.
Another example of "what you measure is what you get".
And because they keep finding those obviously wrong things, the program justifies itself!
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.
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.
>>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.
> 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.
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.
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.
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.
I didn't know PowerPoint allows you to navigate that way. I've always used either hyperlinked text or little navigation icons in a corner of the slide to quickly navigate to the relevant back up slides.
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.
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.
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.)
I think by scenario you mean “script” (that’s the typical way to say it in English).
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.
That was the script. Russian word for script is "scenariy", which is why I got confused.
oh, yes, script. False friends in translation.
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.
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.
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.
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.
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
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
“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_.
I’m dealing with this in almost daily basis. People are afraid of not having an opinion and appearing stupid.
A prior thread: https://news.ycombinator.com/item?id=9137736
When asked to review something, I like to use a version of Brené 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.
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.
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
That works up until the point someone says they love the squareness of the boxes ;-)
You win either way, so long as you don't care which way the decision goes.
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.
Yup, I call that Wolf Management for the same reason.
It would have been better with the duck left in the game. "Why is there a duck there?" -> "Great story, no one on the team was the sort that bikesheds things" -> "omg, your team was the luckiest like ever!"
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?
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.
Class and status are one hell of a drug
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?
Bad form to remove the duck. Basically every project manager ever. Somehow, “A.I” doesnt seek to replace them.