Metaproblem: Terror

Introduction

This post is the twelfth part of a ramble-rant about the software business. The current posts in this series are:

This post is about the metaproblem: terror.

Metaproblems Revisited

As stated in Metaproblems: Drama: 

• A metaproblem is a problem with a problem.
• Metaproblems are manufactured by people.

A Scenario

Your project is operating with the assumption that everything will go right. There are rules, and the rules clearly state that every task is assigned a primary resource. A backup resource is also assigned that can perform the job function as efficiently and effectively as the primary resource.

Something unexpected and bad happens in the middle of the night. The primary resource is unavailable. The backup resouce is working the issue but not having much success – the problem apppears to be a new feature added in the past week, and the backup resource has little knowledge of how the new code works.

The project management team realizes they stand at a roadblock. What do they do next?

False Assumptions 

There are two false assumptions in this scenario:

Every primary resource has a backup resource.
This expectation is a way to prevent single-threading and single points-of-failure. Is this realistic? Yes – provided you calculate the number of people (Note: people are not resources; people are the ugly bags of mostly water that use resources, but I digress) and then promptly double that number. If you practice pair programming, then and only then does everyone have a backup as competent as the primary. Oh, and code quality improves too (50% less errors… read the link).

If your project demands a backup for each primary without practicing pair programming, this can be achieved by building time for code review and documentation and the like into the project deliverable schedule. Software projects rarely do this. Why? It’s a communications issue. When a project manager asks a developer “How long will it take to develop feature xyz?” the developer hears “How long will it take to develop feature xyz?” I know. Crazy. What the project manager is often asking is “How long will it take to dissect the customer deliverable expectations; provide feedback to the business analysts until you and they agree on the deliverables; develop the software; perform unit, integration, functional, and performance tests; package the software for deployment; and complete the documentation for feature xyz?” It’s all in how we define the word “develop”.

The unexpected isn’t supposed to happen.
The expectation is everything that can happen during a project cycle can be accounted for ahead of time, and that nothing outside the defined expectations can occur. What happens if, for example, six feet of snow falls in two weeks where one foot of snow is the norm? “You want us to account for the weather in projects now, Andy?” Only if you think you can account for everything up front. Otherwise, I want you to leave time in the project deliverables schedule for the unexpected.

Even the best laid schemes of mice and men go often askew. I apply the matrix below to all plans. The idea is to remind me Stuff Happens: sometimes good stuff and sometimes bad, but it happens nonetheless.

The upper left quadrant represents the driver for the plan. The upper right quadrant is also part of the plan – it represents the stuff you expect to sacrifice to achieve the planned goal.

The lower left quadrant is awesome, and usually indicative of either a miracle, good karma, lucky break, or a well-designed process. The lower right quadrant can sink your project, cause untold misery, or even kill you.

When Terror Sets In 

All too often, terror seizes the roots of the decision tree. The project is staring at a roadblock on one hand and a non-responsive single point-of-failure on the other. This is less than accurate. The “project” isn’t doing anything. People make up the project team – they’re staring and starting the terror cycle.

The frantic project manager begins the escalation ritual. A call in the middle of the night, a voice mail message, followed by an email message, followed by subsequent calls. A manager is called. If that manager cannot be reached, their manager is called. An oddly interesting thing happens as this cycle progresses: At some point in the escalation the project manager is faced with calling a peer or a manager to whom they also report. Here, the heretofore middle-of-the-night escalation can rest until more normal business hours.

Excuses and Justification

Opportunity lies in these times that try project managers souls. There was that talk and those emails about work-life balance, after all. How does that come into play now? Does it matter that the lowly single-threaded-current-roadblock developer put in 118 hours last week? Naa – that can be excused as poor time management, right? Not the project manager’s problem really. How about the fact that we need to call her now in the middle of the night? Again, not the PM’s problem: the developer should write code that Just Works and should have spent time sharing the latest code changes their backup. Again, not the project manager’s problem.

The Moment of Truth 

Allow me to be clear and cogent for one moment: The integrity of a company’s policies, an eloquent mission statement (and the time spent crafting it), and lofty commitments and elegant email compositions about work-life balance are all on trial in this moment. It comes to this: Which path is chosen?

Terror Makes More Work

Terror really isn’t worth the trouble. Common sense dictates the number of phone calls, nasty voice mails, or threatening emails does nothing to move the problem toward resolution. In fact, punching the developer in the brain slows down progress because the developer now has more stuff in her head than solving the software issue (more in the linked post).

Some More Irony

When the roadblock is overcome, the people manufacturing the drama will secretly congratulate themselves for their “contribution” – believing the additional workload and stress they added to the hearts and minds of those actually solving the Problem (punching them in the brain) helped in some way.

Nothing could be farther from the truth.

Overcoming Terror 

How do you deal with terror when faced with it? The best solution I’ve found is to show up and solve the problem, ignoring the emails and deleting the voice mails. Be professional. Be polite. Rise above the terror. Do what you know is the right thing to do, and do not do anything you know is the wrong thing to do.

People are creatures of habit. Terror is a habit. It can be broken if you demonstrate it simply doesn’t work on you. If you calmly go about your job doing the very best job you can – and not giving into the temptation of terror – a funny thing happens: people start respecting you and treating you better.

Will you always have the answer that calms the waves and silences the storm? Will you always be the hero? Will you always show up with the silver bullet? Probably not. But if you refuse to react to the chaos some will hurl your way, you communicate more with your actions and your words. And your actions say “That doesn’t work on me.”

Conclusion

In a crisis, you have little control over the hand you’re dealt. But every single time, you have 100% control over how you play your hand.

:{> Andy