Hacker News Reader

Comment by Foy | Hacker News Reader

I hear nightmarish stories of micro-managers all the time. They feel that in order to do their jobs they have to tweak EVERYTHING that crosses their desk.

One memorable anecdote I came across was about an animation artist who was in charge of animating the queen for a 3d chess game. Because he knew his manager's weakness he threw in a duck... Yes, a duck. Fully animated with sound effects and everything.

Sure enough, when he showed his work to his manager he said "It's perfect, but get rid of the duck."

So maybe the moral of this lesson is that when things are running 100% smoothly, it's wise to toss your micro-manager a bone by doing something intentionally a little wrong to give them something to meddle with. ;-)

View on HN

The duck story is battle chess: http://en.wikipedia.org/wiki?title=Talk:Battle_Chess#The_duc...

I've often had the opposite problem: companies where the CEO is so disconnected from the company (usually by working remotely 80% of the time) that the company doesn't have direction and languishes.

Oh thanks! I was wondering where exactly I had heard that.

Aww, so there never was a duck.

Speaking of managers ignoring things, I'm reminded of the last episode of the 90s sci-fi tv show 'Sliders', apparently the producers thought the network exec werent reading the scripts, so they deliberately broke a rule, and wrote a scene where someone was shot in the head and it wasn't picked up on.

cf. http://en.m.wikipedia.org/wiki/Sliders#section_2

I've heard the same advice applied to PhD theses: Examiners always want to change something, so leave something in which you won't mind having them tell you to change.

I have witnessed this advice applied to contract drafts. Lawyers from the other company were routinely given some bullshit clauses to prove their usefulness in vetting the contract.

The really entertaining part is when they don't catch them. Every clause is negotiable - don't leave it to your lawyers alone to negotiate.

Obligatory Dilbert (7/12/1997):

http://dilbert.com/strips/comic/1997-07-12/?Page=2

A friend of mine who buys and restores old houses deals with a similar issue. Buyers hire inspectors when they want to buy a house, who are supposed to alert them to major liabilities that might be lurking. But those inspectors aren't well trained and also have a need to appear to be "useful" to the people who pay them, so if you're selling a house that doesn't have any obvious flaws, such as a broken furnace or crumbling foundation, then they will entertain themselves by pointing out trivial items that dont' really affect the house's suitability, but can often scare buyers away or cause headaches for the seller. (For example, cracks in the foundation of an 80 year old house that likely appeared within months of the house being built and haven't budged since.)

To counter this, my friend purposely leaves 3-4 fixes that he intended to complete all along un-done for the inspector to notice and fixate on. Then the inspector gets to look useful, the buyer gets a good house, and everyone's happy.

I had a micromanager who hit everyone with 3 to 4 status pings per day. Even on work-from-home days, which defeats the point. His status pinging was a compulsion like email checking, but it eventually caused the team to fail.

Consequently, I hate status meetings and standups and the various so-called Scr(ot)um tactics used to make people feel watched. I realize they're probably necessary as an occasional annoyance, but I think they're an unnecessary pain in the ass most of the time. Their real purpose is to intimidate people into being productive, and that Theory-X bullshit doesn't work in the modern economy.

There is a large set of humans who get more work done when they're held accountable for it. I'm one of them. Call it "intimidating people into being productive" if you must, but it works. Even in the "modern economy."

The manager in the example you gave was indeed taking things a bit far.

I'm not really sure how you're implementing scrum. Our scrum standups are always just the programmers, once a day in the mornings, and are used to keep all the programmers on the same page and talk to each other to find out if features might have a codependency, or if other blockers can be solved by something else another dev is working on. There's no "watching" of people or "intimidation".

You might want to speak to your manager next time something like that is happening, because there's no way it can be good for your productivity or the other people on your team. It's certainly not a normal practice. At the very worst, if someone isn't pulling their weight they should be dealt with in private.

Yeah, but next you'll tell us at your standups you actually stood up. No one gave me an answer when I asked why they called our meeting standup meetings.

In my current project we do actually stand up, although only due to the pleasure of the team leader. The main reason it's called a "stand up" is to serve as a reminder that it should be very short, 5 minutes max, or otherwise the time most people would feel comfortable standing for a meeting.

Yeah, thanks for the answer. I was being facetious, because our micromanager would divert the meetings to be daily 25 minute meetings! Daily.

A daily 30 minute standup with 10 programmers (three minutes each) is 5 hours of development time lost. That's 25 hours a week, over half a full-time developer. It's probably more. Let's say stand-up is at 0900. Nobody getting in early is going to really get in the zone because they know standup is coming. Then after standup there's another 15 - 30 minutes getting into the flow. Then it's nearly lunchtime. In other words, standup pretty much kill half the day.

Can you really say they are worth it?

The problem is trying to communicate this to management. I was told that standups are non-optional.

You can do standup meetings in lots of different ways. Our standups are maybe 5min max for a team of 6 and they're very worth it.

Our standups are at 11:45, so we have impetus to keep it brief and get to lunch. In any case, even if it does cut into a stretch of programming, it serves as an invaluable reminder to go get lunch.

Yeah, I agree that I'd be annoyed with standup at any time before 11:30, but 11:45 is perfect and basically doesn't interfere with anything. In a certain sense it doesn't cost any dev time at all if you take it for granted that your developers should stop coding midway through the day and eat lunch. (We absolutely do not eat lunch during standup - we have standup, then we physically leave the office to go eat.) Sure, some days we end up in endless meetings which mean we're stuck in the building eating takeout, but that has nothing to do with standup.

We experimented with 10 AM scrum but I found that if I came to the office at 9ish, I used to get distracted with the thought of Scrum. Eventually, we decided to move it to the afternoons at 4:30 which works out well because you are almost done with your work day and you can get distracted all you want.

A 30 minute standup counters the whole idea of a 'standup' meeting.

The goal is 45 seconds a developer not 5 minutes. Round up to 10 minutes a day * 5 days a week = one 50 minute developer meeting a week which is fairly common.

PS: You do lose a little time gathering, and people generally spend some time organizing there thoughts etc. But, keeping track of a short synopsis is useful, as is knowing what other people are working on, and most importantly when someone get's stuck working on the same things for a few days. It also adds a lot of pressure to get at least one thing done every day, which many people slack on.

10 people seems like a very large team for a single project, do you have multiple teams in the same standup? If that's the case then you're certainly wasting time as cross project communication is only rarely going to be useful.

We have a daily meeting that's not supposed to exceed 15 minutes. We're still trying to get into the swing of making that happen. But I find them invaluable for learning what other people are up to that day. And they frequently result in people being able to solve their problems after the meeting because someone else was able to help.

This sort of daily communication can be really helpful. But it's also really easy for it to devolve into a long meeting that's much less useful. And if management is using it to apply pressure to get more work done, they're making a huge mistake.

Reply on news.ycombinator.com