Demoralize Your Teams Quickly And Efficiently With Micromanagement

~ Andrew Stellman ~ 4 Comments

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.

Inflict bad UX on users you secretly hate

~ Andrew Stellman ~ 1 Comment

About a year ago at a conference, a programmer came up to me for some advice about an unfortunate user interface he’d built. It was a pretty miserable affair: a combination of displaying too much information and offering too many choices, while at the same time burying the one thing that the user actually wanted to work with. It was full of classic UX – user experience – mistakes and usability problem, and I suggested the usual suspects: go back to user stories, develop some use cases, try to figure out what the users actually need.

That did not go over well. I’d assumed that the programmer was still working on gathering feedback, since he was asking me to look over his design. So I was surprised when he mentioned that it would be difficult to make changes to it, because it had already been rolled out and his users were using it.

That’s when I decided that this was a devious supervillian who secretly hated his users. Or, possibly, just a thoughtless jerk—I couldn’t really decide for certain without seeing his secret lair. (Hint: If he has a secret lair, it’s probably the former.)

My point is that if he did hate his users, then inflicting bad UX on them was a perfect way to make them really miserable.

You can’t just add usability at the end of the project

You’d be surprised at how often programmers are completely unaware that they have serious UX and usability problems. Just a few days ago, someone told me, “Our users are using our software, so we don’t have any usability issues!”

One of my favorite sayings is that there are only a few ways to do something right, but a million ways to do it wrong. Usability is no exception. And one problem with user experience and usability is that it’s not always easy to diagnose UX problems in software that you wrote. Good UX is designed in from the beginning; bad UX can show up at any point along your project.

That’s why an approach that I like for fixing usability problems is to concentrate on the team, not just the software. Here are a few quick questions to ask yourself. If any of these situations sound familiar, you might have usability problems:

  • A user is explaining what he needs you to build. Halfway through a sentence, you stop him and say, “That’s great! I know exactly what you need.”
  • The first thing you did on your new project was start up the form or page designer in an IDE and drag controls onto a window—before talking to any of the users.
  • You’ve gotten halfway thorough a project without knowing the name of anyone outside of the programming team who’s going to use the software.
  • When you deliver the first version of the software for users to test, it’s the first time they’ve seen the GUI.
  • You find out that there’s an entire feature that your users aren’t using… or a feature they don’t even know about.

If any of that sounds familiar—or, even worse, if you’re now pissed off at me because you don’t see what’s wrong with any of those scenarios—then you should definitely consider getting some UX help right now. (I’d offer to help you myself, but I’ve got my hands full with my own projects!)

One of these days I’m going to start an organization called PeTU: Programmers for the Ethical Treatment of Users. We’ll set up a protest outside the office of any development team that inflicts bad usability on their unsuspecting users. For the sake of all our sanity, please stop inflicting bad UI on unsuspecting users! If you don’t, I’ll have to stage an outlandish, somewhat juvenile protest outside your office.

A Few Things Every Job-Seeking Programmer Should Know About Project Management (part 2)

~ Andrew Stellman ~ 1 Comment

I’ve met a lot of programmers who really hate project management. And it’s not that surprising, because project management done poorly can be a pain. But if you’re a developer looking for a job, employers are more and more likely to expect you to know something about project management. Luckily, good project management can make your life easier, and it’s worth knowing about it—not just for job interviews, but to help you get the most out of your own projects. In part 1 of this post, I talked about a few basic things that I think every developer ought to know about project management. Now I’ll finish up by going into a few details that can help you run your projects more smoothly—and deliver better software.

Why you should care about project management

I’ve had a lot of developers over the years tell me outright that they think project management is stupid.

Some of the best developers I’ve worked with had pretty negative opinions of project management. At best, they’d say something like, “Well, that sounds good for another team, especially a really big team, but our projects run just fine without the extra overhead.” At worst, they think it’s malignant bureaucracy imposed on them by pointy-haired bosses. One bad experience can sour a good developer on project management. And that’s pretty unfortunate, because good project management can make a developer’s life a lot easier.

So why should a developer care about project management? I think the answer is in the Why Projects Fail talk that Jenny and I have done many times over the years, where we outline many different ways that projects fail. We got the idea from that presentation because we’ve spent years talking to many different people about the different kinds of project problems. We had to figure out exactly what it means for a project to fail. Obviously, if your project completely crashes and burns, it’s a failure. But the funny thing about a software project is that you can almost always deliver something – even on a project that everyone agrees is a failure, you’ll have code that compiles and runs.

So we came up with this definition of project failure:

  • The project costs a lot more than it should
  • It takes a lot longer than anyone expected
  • The product doesn’t do what it’s supposed to do
  • Nobody is happy about it

When we go through these things, we always get a lot of head-nodding, especially from developers. More importantly, we’ve never met a single professional software engineer with more than a few years of experience who hasn’t been on at least one failed project. We always ask for a show of hands to see if there’s anyone who’s never had a failed project. And we’ve yet to meet anyone who has. (We did get someone who raised his hand once, but I talked to him afterwards, and he was just messing with us.)

What does this have to do with project management? Well, everything! Have a look at a typical project management textbook, and you’ll learn about the “triple constraint” (which some people call the “iron triangle”) of scope, time, and cost.

(source: Head First PMP, 1st ed., O’Reilly 2007)

Project management really boils down to managing that triple constraint: balancing the scope of the work to be done, the cost of doing the work, and the time it takes to get the work done, all in order to get the best quality that you can. If you do that right, your project runs well, and your team is happy. If you do it badly, your project stinks, and you end up with a failure. And that’s why you, as a developer, should care.

I’ll go into a little depth about each of those things – scope, time, cost, and quality – just to give you an idea of why you should care about each of them. But the one that developers care about most is scope, so I’ll spend a little more time on that first.

Scope: the work and features that go into the project

Every project can be broken down into a small number (say, ten to twenty) features. For big projects, those features are big (“solid rocket boosters,” “reuse and reentry”); for small projects, those features are small (“holds 12 fluid ounces of liquid,” “screw-top cap”). And similarly, every project can be broken down into a small number of tasks that are needed to build those features. Project managers call the list of features the product scope, and they call the tasks the project scope – and a lot of people just talk about all of it as scope.

I’m consistently amazed by how much work a project team can put into a project without before they realize they’ve got a scope problem. Jenny and I talked about this in our book Applied Software Project Management in the section on scope problems:

A change in the project priorities partway through the project is one of the most frustrating ways that a software project can break down. After the software design and architecture is finalized, the code is under development, the testers have begun their preparation, and the rest of the organization is gearing up to use and support the software, a stakeholder “discovers” that an important feature is not being developed. This, in turn, wreaks havoc on the project schedules, causing the team to miss important deadlines as they frantically try to go back and hammer the new feature in.

Applied Software Project Management, p31

Does that sound familiar? If so, talking about the scope earlier in the project can really help. One way to help fix this is to put together a Vision and Scope document. It’s a really simple document, usually only a page or two, but it can really help prevent scope problems. It’s also a staple of project management. Once in a while, I’m pulled into a project that’s been running into trouble. I’ll spend a few hours talking to each of the team members, managers, and anyone else I can find who knows something about the project or needs it done. I’ll throw together a quick vision and scope document, and what I’ll often find is everyone had very different ideas of what would actually get built. And it’s usually a big relief, because everyone – especially the lead developers! – realizes that they were going down a path that would have had them waste a lot of time building the wrong software.

(source: Head First PMP, 1st ed., O’Reilly 2007)

Faster, better, cheaper—choose two… right?

There’s a whole lot more that I’m tempted to write about managing time, cost, and scope in order to get to the right quality level, but I really want to pare this down to the basics. There’s an old (and somewhat cynical) project management saying: “faster, cheaper, better: pick two.” What it means is that there’s no way to reduce cost, shorten the schedule, and increase quality all at the same time. At least one of those things absolutely has to give.

But there’s a reason that’s a saying and not a law! All three of those constraints are related to each other, and there’s almost never an easy, obvious trade-off where you can sacrifice one to improve the other two. If there were, project management would be a lot easier. It’s really easy to fall into a trap of trying to do the impossible, but the first step in avoiding a trap is knowing that it’s there. In this case, just knowing that every project is a balancing act between scope, time, and cost is a really good first step in making sure your project ends up running well.

I wanted to leave you with just a couple of thoughts:

  • One thing that makes the “time” aspect of project management tricky is that developers really hate giving estimates – or, more specifically, they hate giving estimates because they know they’ll be misinterpreted as hard commitments. I wrote a blog post about this a while back (The Perils of a Schedule) .
  • Every project needs a start, middle, and end. My old friend Scott Berkun writes about this beautifully in his book, Making Things Happen.
  • Cost doesn’t have to mean dollars – it’s often more effective to measure cost in hours.
  • Burndown charts really help, because they can make the cost seem real.
  • Sometimes the word “quality” makes developers a little nervous, because they start to think that improving quality just means doing endless testing. Sometimes it helps to replace a phrase like “high-quality software” with “software that we can be proud of.”