At some point during the software development process, the engineering team will suddenly decided there is no way the product is:

1. Going to be done on schedule and/or
2. Going to be an acceptable quality.

The realization is going to paralyze the team with fear, work will stop, and hands will be thrown in the air.

During my Netscape days, this group realization was tucked neatly under the statement “We’re Doomed”. The simple phrase summed up the collective despair in a neat little package that allowed us to focus on the problems at hand rather than the fact there were an infinite amount of problems.

A hypothetical example:

You: “Hey Rands, I can’t get the Mac build to compile, Reggie hasn’t a clue what to do about that memory leak, and no one has seen Zack in three days and he’s got four show stopping bugs on his list.”

Me: “We’re Doomed.”

You: “Yeah, so can you help me with the Mac build?”

The good news about “We’re Doomed” is that it pushed aside the impending falling of the sky and allowed us to continue to work, but, in the back of our minds, we knew the sky was still falling. I’m here to tell you how to first detect Doomedness in your team and then suggest one specific way to unfreeze the team from the state of despair.

DETECTION

In this scenario, you’re a manager or director . You are directly responsible for the product being shipped even though you may not be working on it on a day to day basis.

If you are a manager, you already know there are lots of false positives when it comes to “We’re Doomed”. If you’re a decent manager, folks come by to vent. Sometimes their venting needs action, sometimes it’s just the vent that needs to occur. Your call. Don’t screw it up.

There are two situations when you need to be concerned:

1. The venting is consistent in tone and content across the team and
2. It is confirmed by co-workers OUTSIDE of the team

Number one is pretty easy to detect if you have regular 1:1s with your team. You’ve heard venting before, but now the vents are peppered with qualifiers like “We’ll never…”, “We’re screwed”, or “There’s no way…” Observations of the work situation have moved from “This is tough” to “This is impossible” and that means work is not getting done because no one can see the end game.

The second part, external confirmation, is trickier, but essential. You’re looking for someone else, your boss, another manager, a product manager to walk into your office and say, “They’re screwed.” What you should hear isn’t that the team is actually screwed, but that the team convinced that person of their screwedness. The observation here is that the screwedness is spreading… like a virus… now the company is tense… people without access to the facts are concerned rather than just you and your group.

Time for action…

TREATMENT

SIDEBAR: I’m an optmisitic guy and that means I believe that for most states of screwedness, there is a course of action that will help. It’s entirely possible that your team is saying “We’re Doomed” and they are and nothing you can do is going to change that. Bummer.

The key to getting past the “We’re Doomed” state is to get the team stop thinking about the fact the task appears impossible and get them moving forward. What has likely happened, especially in software development, is that the details become overwhelming. The thousands of small pieces of work that need to get done are mind boggling. There’s user interface to finish , thousands of bugs to triage, oh yeah that feature isn’t even done, and WHAT DO YOU MEAN MARKETING WANTS TO BETA THIS CRAP?

What you really need to do is get your team breathing again. How I do that is pretty simple.

Once I’m certain the team has qualified for Doomedness, I sit down with each one, dry erase marker in hand, and give them opportunity to tell me, in specific terms, what they are stressing about. To give this vent some structure, I tell them we can only list five specific concerns on the white board. No more.

Now, more often than not, co-workers see this another vent opportunity. They start spilling over with vagueries like, “Too much work” and “Not enough time”. Stop right there. What your looking for are five specific concerns. Too much work? Where is that work? What feature? Too many bugs? How many? Are they all yours? What else?

You’ll find once you get one or two specific bullets on the white board, the rest are easy. Your inclination as a manager will be to problem solve, but don’t. There’ll be plenty of time after you’ve assessed what the hell is going on with the team. Thank your co-worker and move onto the next.

What you’ll find about halfway through your team is that a course of action will become obvious. Two or three specific themes will arise from chaos and these are things you need to fix. Great. You know what to do, but that’s not the key benefit of this approach. You also got the team to quantify their concerns… more often than not, the action to resolve the issue will come from them.

Told you it was pretty simple. Here’s the hard part:

• Timing is key to this process. If you do it too early, you’ll get a set of work, but it won’t be the right work since there’s another four months of work to do and the real issues haven’t arose yet. If you do it too late, you won’t have the time to actually change anything.
• You can only do this process once per project cycle.
• Congratulations, you timed your intervention perfectly. You’ve got a specific set of actions and the team is temporarily happy because they know what’s stressing them out. Don’t ever take their temporary sense of calmness as a sign of victory because in 72 hours they’ll have made some progress and if they perceive you sitting there in status quo mode, you’re doomed. Credibility down. Chaos up. Back to square one.

Each time I end up in this type of intervention, it’s never pleasant. Co-workers are not happy… they’re pissed… they not feeling empowered… and they can’t see the light at the end of the tunnel. You can argue that it’s poor management which got the team in this spot in the first place. Yeah, maybe. The problem is that every software project I’ve been a part of (either as an individual or a manager) has a Doomed inflection point late in the product cycle. I don’t think it’s avoidable.

Personally, my favorite part of the software development cycle is the time between We’re Doomed and We’re Done. Not only is it the time when the most team bonding occurs (ie: no one ever leaves the building), but it’s also the time when the product moves from paper to screen. Every hour is filled with tests for the original design in the form of questions, “How is THIS going to work in our model?” These tests will show whether what you’ve designed actually works or whether you are truly Doomed.