nemo
/
hn-classics
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
hn-classics/_stories/2010/10762751.md

17 KiB
Raw Permalink Blame History

created_at title url author points story_text comment_text num_comments story_id story_title story_url parent_id created_at_i _tags objectID year
2015-12-19T05:26:53.000Z Demoralize Your Teams Quickly and Efficiently with Micromanagement (2010) http://www.stellman-greene.com/2010/11/29/demoralize-your-teams-quickly-and-efficiently-with-micromanagement/ sidcool 203 63 1450502813
story
author_sidcool
story_10762751
10762751 2010

Source

Demoralize Your Teams Quickly And Efficiently With Micromanagement | Building Better Software

Skip to content

Building Better Software

The official website of O'Reilly authors Jennifer Greene and Andrew Stellman

Menu

Demoralize Your Teams Quickly And Efficiently With Micromanagement

November 29, 2010November 29, 2010 ~ Andrew Stellman

Apparently I've earned the dubious distinction of having become an expert in project failure. I've always had an interest in project failure—Jenny and I have been doing our "Why Projects Fail" talk for years now, and we've talked to many people in many different industries (like in our fourth book, _Beautiful Teams_) about what's gone wrong on their projects. We've looked at failures on projects through the years, from small misfires on our own projects to dramatic failures like the Tacoma Narrows Bridge disaster, to try to figure out what software developers can learn from them.

One of my favorite ways that projects can fail is death by micromanagement. It's a nasty, insidious problem for a couple of reasons. It's easy for a boss to fall into the micromanagement trap, especially for a project that's starting to spiral out of control, because when you feel like your project is slipping away from you, it's hard to resist the urge to tighten your grip on every part of it that you can.

And the people on the team have trouble recognizing it because a lot of them have never worked any other way. I've said it before, and I'm sure I'll say it again: I'm willing to bet that if someone was able to conduct an accurate survey, they would find that a surprisingly large number of managers are micromanagers.

On the other hand, if you're a boss or a project manager looking for a great way to demoralize your team and cause your projects to fail, micromanagement is a great way to do it. Here are some handy tips to make sure your team hates you and your project runs into serious trouble:

  • Make sure you don't give your team enough time to do the work, and then blame them for not getting it done on time.
  • Routinely ask people to stop working on whatever they're doing right** **now to take care of urgent emergency work.
  • Then utterly fail to follow up on that urgent emergency work.
  • Never let anyone on your team release anything or even talk to a user without giving it to you to look over first.
  • When they give you that work, make sure you send it back with a whole lot of vague and poorly thought-out changes – but make sure you don't give any extra time to make them.
  • In fact, try to constantly find many small changes that your team should make, just to keep them on their toes.
  • Your team needs constant attention! If it's been more than two hours since you've talked to someone on your team, drop by and tap one of them on the shoulder and ask for an update.
  • All organizations run on status. If the status updates stop flowing, a company can crumble and perish! Also, developers feel lonely if they haven't given a status update in the last few hours. So make sure everyone has to fill out elaborate status reports, and make sure you hold at least three two-hour-long status meetings every week.
  • Did someone on your team do something differently than how you would do it? Reprimand them! They might tell you that it works just fine, and that their way is just as good. But it's not your way, so it's not right.
  • Remember: reading your mind is part of every team member's job. That's how they stay proactive!

Most of all, though, remember rule #1: **Nobody is ever allowed to make mistakes! **If a developer makes a mistake, it reflects badly on you, and the whole team suffers. Never admit that you were wrong about anything. If you said it once, it's now the law and should never be questioned.

If you follow this simple advice, then your team will be demoralized in no time. Also, they'll hate you. Oddly, though, there's a good chance that they won't get their resumes together and start looking for new jobs. I have a theory about this: when you micromanage a team, it drains their will to such an extent that they no longer care. Psychologists call this state "learned helplessness."  The Wikipedia article on learned helplessness has a good description of a classic experiment by Martin Seligman and Steve Maier:

In part one of Seligman and Steve Maier‘s experiment, three groups of dogs were placed in harnesses. Group One dogs were simply put in the harnesses for a period of time and later released. Groups Two and Three consisted of “yoked pairs.” A dog in Group 2 would be intentionally subjected to pain by being given electric shocks, which the dog could end by pressing a lever. A Group 3 dog was wired in parallel with a Group 2 dog, receiving shocks of identical intensity and duration, but his lever didn’t stop the electric shocks. To a dog in Group 3, it seemed that the shock ended at random, because it was his paired dog in Group 2 that was causing it to stop. For Group 3 dogs, the shock was apparently “inescapable.” Group 1 and Group 2 dogs quickly recovered from the experience, but Group 3 dogs learned to be helpless, and exhibited symptoms similar to chronic clinical depression.

In part two of the Seligman and Maier experiment, these three groups of dogs were tested in a shuttle-box apparatus, in which the dogs could escape electric shocks by jumping over a low partition. For the most part, the Group 3 dogs, who had previously “learned” that nothing they did had any effect on the shocks, simply lay down passively and whined. Even though they could have easily escaped the shocks, the dogs didn’t try.

If reading about the Group 3 dogs reminds you of work, then there's a very good chance that you're being micromanaged.

Share this:

Post navigation

< Previous Inflict bad UX on users you secretly hate

Next > Confessions of a jerk

4 thoughts on “Demoralize Your Teams Quickly And Efficiently With Micromanagement”

  1. Pingback: Interesting Read on Managing Teams | Musings of a Code Monkey

  2. Pingback: How to spot bad clients as a Web Developer Freelancer/Agency

  3. Pingback: The Days Of Our Lives As IT-Workers - Programming

  4. Pingback: How micromanagement kills creativity and productivity of developers. - IT大道-IT大道

Leave a Reply Cancel reply

You must be logged in to post a comment.

Welcome!

Our books

Head First Agile

** Head First Agile** is a highly visual brain-friendly guide to help you learn important agile concepts and ideas. It covers Scrum, XP, Lean, and Kanban, and it also helps you prepare for the PMI-ACP certification.

Learning Agile

[ ![Learning Agile][43] ][44]

** [Learning Agile][44]** is a comprehensive guide to the most popular agile methods, written in a light and engaging style that makes it easy for you to learn. [Read the first chapter for free!][45]

Head First PMP

[ ![Head First PMP][46] ][47]

[Head First PMP][48] gets you prepared for the Project Management Professional certification exam by helping you become a better project manager.

Head First C#

[ ![][49] ][50]

[Head First C#][50] is one of the most popular books for learning C#. In our opnion it's the easiest and most fun way to do it, too!

Applied Software Project Management

[ ![Applied Software Project Management][51] ][52]

[Applied Software Project Management][52] helps developers and project managers build better software by diagnosing and fixing the most common project problems.

Beautiful Teams

[ ![Beautiful Teams][53] ][54]

[Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders][54] is a collection of stories and interviews with veteran team leaders that takes you behind the scenes with some of the most interesting teams in software engineering history.

Open source projects we maintain

  • [Publication Harvester][55]
  • [SC/Gen and Social Networking Report][56]
  • [Scientific Distance Report][57]
  • [pbprdf — generate RDF for basketball play-by-play data
  • [MGRS to UTM coordinate converter][58]

Categories

[Agile][59] [Architecture][60] [Articles][61] [Books][62] [C#][63] [Careers][64] [Code][65] [Estimation][66] [Gold Plating][67] [News][68] [PM Clinic][69] [PMI][70] [PMP][71] [Presentations][72] Project Management [Project Management Professional exam][73] [Q&A][74] [Quality][75] [Requirements][76] [Software Development][77] [Software Engineering][78] [Software Process][79] Teams [Test-driven development][80] [Uncategorized][81] [Usabililty / UX][82] [Users][83]

[Proudly powered by WordPress][84] ~ Theme: Penscratch by [WordPress.com][85].

Send to Email Address Your Name Your Email Address ![loading][86] [Cancel][87]

Post was not sent - check your email addresses!

Email check failed, please try again

Sorry, your blog cannot share posts by email.

[43]: [44]: http://shop.oreilly.com/product/0636920025849.do [45]: http://cdn.oreillystatic.com/oreilly/booksamplers/9781449331924_sampler.pdf [46]: http://www.stellman-greene.com/blog/wp-content/uploads/2007/04/head-first-pmp-cover.jpg [47]: http://www.headfirstlabs.com/PMP [48]: http://www.headfirstlabs.com/books/hfpmp/ [49]: http://www.stellman-greene.com/blog/wp-content/uploads/2007/08/head-first-c_-cover-small.png [50]: http://www.headfirstlabs.com/books/hfcsharp/ [51]: http://www.stellman-greene.com/blog/wp-content/uploads/2007/04/aspm-cover.jpg [52]: http://www.stellman-greene.com/aspm/ [53]: http://www.stellman-greene.com/blog/wp-content/uploads/2008/09/beautiful_teams_zebras_small.png [54]: http://oreilly.com/catalog/9780596518028/index.html [55]: https://www.stellman-greene.com/PublicationHarvester/ [56]: https://www.stellman-greene.com/SCGen/ [57]: https://www.stellman-greene.com/ScientificDistance/ [58]: https://www.stellman-greene.com/mgrs_to_utm/ [59]: https://www.stellman-greene.com/category/agile/ [60]: https://www.stellman-greene.com/category/architecture/ [61]: https://www.stellman-greene.com/category/articles/ [62]: https://www.stellman-greene.com/category/books/ [63]: https://www.stellman-greene.com/category/c/ [64]: https://www.stellman-greene.com/category/careers/ [65]: https://www.stellman-greene.com/category/code/ [66]: https://www.stellman-greene.com/category/estimation/ [67]: https://www.stellman-greene.com/category/gold-plating/ [68]: https://www.stellman-greene.com/category/news/ [69]: https://www.stellman-greene.com/category/pm-clinic/ [70]: https://www.stellman-greene.com/category/pmi/ [71]: https://www.stellman-greene.com/category/pmp/ [72]: https://www.stellman-greene.com/category/presentations/ [73]: https://www.stellman-greene.com/category/project-management-professional-exam/ [74]: https://www.stellman-greene.com/category/qa/ [75]: https://www.stellman-greene.com/category/quality/ [76]: https://www.stellman-greene.com/category/requirements/ [77]: https://www.stellman-greene.com/category/software-development/ [78]: https://www.stellman-greene.com/category/software-engineering/ [79]: https://www.stellman-greene.com/category/software-process/ [80]: https://www.stellman-greene.com/category/test-driven-development/ [81]: https://www.stellman-greene.com/category/uncategorized/ [82]: https://www.stellman-greene.com/category/usabililty-ux/ [83]: https://www.stellman-greene.com/category/users/ [84]: http://wordpress.org/ [85]: http://wordpress.com/themes/penscratch/ [86]: http://www.stellman-greene.com/blog/wp-content/plugins/jetpack/modules/sharedaddy/images/loading.gif [87]: http://www.stellman-greene.com#cancel