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.

Not too long ago, I was doing our Beautiful Teams talk at a brown bag lunch for a big financial company here in New York. At the end of the talk, I got a really good question:

What do you do when you’re on a team with people who don’t get along?

We don’t get to choose our teams, and while I’ve been on plenty of teams that gelled really well, I’ve definitely had to work with people who just rubbed me the wrong way or, worse, where the feeling was mutual. It’s a tough problem, but one that should be really familiar to anyone who’s been working with teams for a long time.

I have to admit that while I’ve had success working on teams with people who didn’t get along, there have definitely been a few times when I didn’t handle that situation as well as I could have. Luckily, those are the situations where we learn the most.

That’s actually one of the main reasons Jenny and I wanted to talk to Andy Lester when we were talking to contributors for Beautiful Teams. Andy runs a great website called The Working Geek, where he talks about working life for programmers, sysadmins and other geek types. And he had some really interesting things to say about how people interact with each other — especially geeky types (like me), since we seem to be especially prone to interpersonal problems. (Imagine that!)

I really liked this quote from Andy, because I think it cuts to the heart of the matter:

I was on a team once where I said, “At the very least, can we just have minimal respect for everyone here?” And I was asked quite seriously by someone else, “Well, what if not everybody on this team is worthy of respect?” And that’s baffling to me as a human, but it’s also not uncommon. And that minimal amount of respect is something that many just don’t get.

— Andy Lester, Beautiful Teams (chapter 5)

He’s right. When I look back over my own career, I find that many of my own conflicts with people on my team stemmed from a basic lack of respect. Since I was the top programmer on the team, I thought I knew better than everyone else about everything. Once someone got something wrong technically, I’d write that person off entirely because they didn’t have my respect.

Andy offers some really good personal advice for getting past those problems, both in his Beautiful Teams chapter and on his blog.

But I wanted to go a little further than that, because sometimes interpersonal problems aren’t going to be repaired. The person who asked me the question was in this situation: when I asked him about it, it sounded like some of his teammates were simply never going to get along with each other. So what do you do about that?

As it turns out, the answer I gave him comes from another part of Beautiful Teams. When Jenny and I were putting it together, we put a lot of thought into how to divide it into sections. And so many people talked explicitly about setting goals for projects that we ended up including an entire section called Goals.

So my answer to anyone who’s got insurmountable (at least, in the short run) conflicts between team members is to make sure that you’ve established what many of our contributors referred to as an “elevating goal.”

One of those contributors was Steve McConnell, who also happens to be one of my favorite authors. We asked another one of our favorite authors (and an old friend of mine), Scott Berkun, to interview him for the book, and out of that interview came this great quote:

If you’re out digging ditches, that’s not very elevating or inspiring. But if you’re digging ditches to protect your town that’s about to be attacked by an enemy, well, that’s more inspiring, even though it’s the same activity. And so the leader’s job, really, is to try to determine or frame the activity in such a way that people can understand what the value is.

— Steve McConnell, Beautiful Teams (chapter 16)

I think that really cuts to the heart of what it means to establish an elevating vision, and it should help show why that can help get past serious team problems. I have to admit that before working on this book, I hadn’t really given that much thought to establishing a vision. Yes, establishing a goal for a project is important, but I always thought about it in terms of the work that had to be done. I’d generally dismiss anything like an “elevating vision or goal” as a business-speak buzzword. A really valuable lesson for me was just how important it is to get everyone on the team on board with that one singular vision — and I mean actually understanding and embracing the vision for the project, and not just agreeing to some sort of lame mission statement.

What’s especially useful about getting everyone on the team to see the same vision is that you don’t need to be a manager or team lead to do it. All you need to do, minimally, is talk to people on your team. I’ve been brought onto projects where people on the team thought that there were serious architecture or requirements or quality problems. But once I started I talking to people, it turned out that everyone had a completely different idea of what they were building and why they were building it. I’ve found over and over again that just writing down what we’re building and who we’re building it for (using a Vision and Scope Document, for example) is enough to help the situation. It’s uncanny how often I’ve heard people say something like, “Wait, we’re building what? I thought we were doing something completely different!”

Anyone on the team can do that, and it’s a really valuable tool to help with serious teammate problems. The clearer everyone sees the real goal of the project, the easier it is to get past the disagreements and arguments and get on with the work. It’s something I’ve seen in real life many times, and it really does work: people are much more willing to settle disagreements and just get down to business if they can see that there’s a real end that they’re working towards.

When I look back at the times where I was able to successfully navigate serious team problems that were caused by people who didn’t like each other, I can see how this is exactly what I did. Even when people didn’t get along, I found that if I was able to get each person to see the bigger picture and work towards something he or she believed in, then most of the time they were able to put their problems on the back burner, at least long enough to get through, say, a meeting or a code review. And that was enough to save the project.

Forbes picked up our Beautiful Teams interview with Tim O’Reilly and published it as an article called The Secrets of Great Teamwork.When Jenny and I talked to Tim, he had some intriguing things to say about what makes people work together. There’s plenty of good stuff in the interview, but one bit that really sticks in my mind is this excerpt:

Andrew: Do you think it’s possible to have a great team that doesn’t have a great leader? That has more of a collective leadership?

Tim: Yes, it is possible. But here’s the thing. Take Apache, because I think Apache is a great example of that. Tim Berners-Lee laid down the blueprint. He said, “I’ve created this idea for this hypertext server, this hypertext client.” And the genius of Apache was in embracing the constraints. I still remember back in the mid-’90s, this moment where Netscape had added this, Microsoft had added that, and everyone was saying, “Apache seems to be standing still. They aren’t adding all these features. They aren’t keeping up!” And the guys at Apache said, “Yup. What we do is a hypertext server, and we have this nice extension mechanism where people who want to do something else can add it on.”

And that goes back to that architecture of participation. They didn’t build this big, conglomerate, complex application. They kept to a pure vision. The vision did actually come from a visionary leader; it just wasn’t part of Apache. Apache came from a group of people who were abandoned by the NCSA server team when they all went to found Netscape. And there were a bunch of customers, so they said, “We have to maintain this, and keep it going.” What was wonderful about that kind of team was that they accepted the constraints that were laid down by the design of the system. They didn’t try to show off their ego or their creativity.

I think a lot of the work done by the IETF (the Internet Engineering Task Force) in the early years did the same thing. There were some wonderful principles laid down, and people really honored them. If you read some of John Postel’s stuff in the TCP RFC about the robustness principle, it sounds like something out of the Bible, for Christ’s sake! “Be conservative in what you do; be liberal in what you accept from others.” Literally, that’s what it says.

The point is that if you have the system architected right, you have a better chance of success for teams. You don’t want teams that are dependent on a single vision or leader, because if you loseWeight Exercise your leader, the whole team goes “pop.”

Something that came up over and over again throughout our many interviews and stories is the connection between teamwork and architecture.  I think Tim hit on exactly the right example with Apache, but there are a lot of other examples throughout the book. Peter Glück had some really interesting things about how the architecture restrictions of NASA projects affected the teams (and especially the practices they used). And Auke Jilderda talked about the “use-use-reuse” model for designing reusable code, and how it impacts teams. I have to be honest: before working on Beautiful Teams, I definitely didn’t make such a close connection between how great (or lousy) teamwork affects architecture.

You can read the entire interview — which, incidentally, is one of my favorites in the book! — on O’Reilly FYI.

Jenny and I have been thinking a lot about teams lately. Working on Beautiful Teams really focused us on teamwork: what makes teams gel, what causes them to run into trouble, and what you can do to them. So when I got this question recently, it was really timely:

I’ve been working on bringing more of a teamwork feel to our projects for 2 years.  It has proven to be a non-trivial task. Any advice?

Now, just so we’re clear here, I know this guy pretty well. He’s a very good manager, and he runs a software development group with some of the smartest people I’ve met professionally.  They’re definitely a functioning group: they’ve been building software for years, and that software is used in production in critical applications at his company. By many accounts, his group is successful.

But when I took a closer look at how that particular team works day-to-day – and this should seem very familiar to a lot of developers – I definitely saw what he meant about it being a non-trivial task. There’s definitely a lack of a teamwork feel on the various projects his team works on. Everyone is really good at carving out his or her own piece of work, and is able to work on that piece independently. But even when multiple people would work on a single release of the same piece of software, they’d work independently of each other, not really talking amongst themselves. Don’t get me wrong – they definitely get their jobs done. But they’re working on individual tasks, not team projects. And even when those tasks add up to projects, it just feels like loosely connected tasks to the people working on them.

So what’s the harm in that, if they’re getting the work done? Well, for one, having a group of people working like that doesn’t exactly encourage innovation. There are some genuinely brilliant people on that team, and they do reasonably good work, but I would honestly expect more innovative work from this particular group of people. And I believe that having more of a “teamwork feel” would encourage more innovative work.

What’s more, I got the feeling that this particular team still runs into a lot of the same problems that many other, less talented teams run into, and I think those problems could be improved through better teamwork. They have some serious change management issues, where they often have to rework their code because it doesn’t quite meet the needs of the projects’ users. They have a few code quality problems – they’re trying to address them with better code reviews, which they’re having trouble getting off the ground. And they have an overall client relationship problem, where the people they build software for often feel like they’re somewhat disconnected, like they can’t quite the software that really meets their needs. Again, these are highly talented, very smart developers, with a manager who’s on the ball – and they’re still getting stuck on the same problems that hit everyone else.

Now, I don’t want to make the situation sound worse than it is. The manager has made some very good progress in getting the individuals working in a more team-like way. One thing he did that I really like (and I think it worked really well) was to really encourage everyone to write things down in the Wiki. And this wasn’t just a general edict (“Each person must add X wiki pages, or else!”). It was actual encouragement and support, treating documentation like it was a real and highly appreciated part of peoples’ jobs. Like a lot of new tools, there was a slow start to it, but once a few people dove in and started to embrace it, it started to really take off. And a funny thing happened: as people started sharing information with each other, they started to learn more about each others’ work, and some of them started to get that “teamwork feel” that they were looking for.

So what’s going on with this person’s group? And, more importantly, what can he do to help improve the “teamwork feel” for everyone?

Whenever I’m trying to help a group of effective but disconnected developers become a team, I like to start with this great analogy from Watts Humphrey:

There are different kinds of teams. In sports, for example, a basketball team’s positions are dynamic while baseball team members have more static roles. However, in both cases the members must all work together cooperatively. Conversely, wrestling and track teams are composed of individual competitors who do not dynamically interact, although the members support each other socially and emotionally.

In engineering, development teams often behave much like baseball or basketball teams. Even though they may have multiple specialties, all the members work toward a single objective. However, on systems maintenance and enhancement teams, the engineers often work relatively independently, much like wrestling and track teams.

A team is more than just a group of people who happen to work together. Teamwork takes practice and it involves special skills. Teams require common processes; they need agreed-upon goals; and they need effective guidance and leadership.

When I reread that quote before pasting it in here, something in that last sentence stood out to me: they need agreed-upon goals. Now, I’ve been referencing that quote for almost a decade. But it’s really interesting to me that I always overlooked that last bit. But working on Beautiful Teams really taught me the value of agreed-upon goals. It was pretty remarkable, actually: contributor after contributor brought up the idea that the people on a project all need to be aligned to the project’s goals, and to have a single, overarching vision that the team can rally around.

So if I had to give a single piece of advice to this manager, it would be this: try to find ways to give everyone a good sense of their goals. Two different Beautiful Teams contributors – Mike Cohn and Steve McConnell – talked about helping the team see an “elevating” goal. I really like how Steve put it:

First, the team leader needs to establish an elevating vision or goal, and I think that this is truly a leadership function, not just management. It goes beyond the management function. An awful lot of thought should go in on the part of the team leaders into what is the team’s goal and what is it about it that is not just trying to trick the team into thinking they have a goal that’s elevating or inspiring, but to come up with one that truly is.

A classic example is if you’re out digging ditches, that’s not very elevating or inspiring. But if you’re digging ditches to protect your town that’s about to be attacked by an enemy, well, that’s more inspiring, even though it’s the same activity. And so the leader’s job, really, is to try to determine or frame the activity in such a way that people can understand what the value is.

Now, that’s not an easy thing to do. But Jenny and I heard this message (or one similar to it) from so many of our Beautiful Teams contributors – Keoki Andrus, Neil Siegel and Mark Healey all come to mind, although other people talked about it too – that it actually changed the way I think about how teams work. In the past, I always looked at defining a project’s vision and scope as a straightforward tool for setting the top-level scope of the project and preventing changes. One thing I learned was that I wasn’t giving “vision” part of it nearly enough respect. Talking openly and often about that vision – and coming back to it when you do things like discuss project assumptions, come up with scenarios (or user stories, or use cases… however you figure out how your users will use the software) and plan out the work the team’s going to do – is the first step in really getting your team to have that “teamwork feel.”