Managing Technical Emergency Teams

A technical emergency (as distinguished from a crisis) is an emergency situation that arises from one or more technical failures, technical problems, or unanticipated situations with high technological content. Technical emergencies are distinguished from climatological emergencies, political emergencies, or financial emergencies by their fundamentally technological flavor. Examples are Apollo XIII, Three-Mile Island, Chernobyl, and the predicted massive system failures arising from the Y2K bug. Sometimes technical emergencies are coupled with community emergencies, as happened in the nuclear reactor accidents at Three-Mile Island and Chernobyl. And sometimes they may remain mostly technical emergencies, as did the "millennium bug."

Contingency plans for technical emergencies typically include elements that can be addressed only by technical teams. The effectiveness of a Technical Emergency Team depends on four fundamental ideas:

• The members of a Technical Emergency Team must be trained specifically for emergency operations.
• The team must be managed differently from the way you normally manage technical project teams.
• The team itself must learn to function in emergency mode.
• In a technical emergency, the team will need extraordinary support from the rest of the organization.

Whether or not a technical emergency is coupled to a community emergency, the technical teams that are formed to address the technical components of the emergency must work under intense pressure, in circumstances that differ dramatically from those in which most technical work is done.

They could be exposed to demands and conditions that most technologists rarely face:

• Seemingly infinite pools of resources, but little time to use them, or even to learn what's available.
• Incessant questioning by public officials, public relations staff, and the media about progress and status.
• Temporary displacement from their homes, either by the emergency itself, or as a result of a management decision to supply housing near the work site, even when the site is near home.
• Killing hours, even beyond what would normally be considered "max."
• Life-threatening conditions, including potentially lethal chemical, biological, or radiological exposure.
• Demands to adhere to conventional procedures that are often too slow to be practical even in normal circumstances, with few approved alternatives suitable for emergencies.

While companies everywhere were preparing contingency plans for the Y2K event, few had enough understanding of the technical emergency environment to anticipate some of the problems that could have arisen. To have the best chance of success in a technical emergency, a Technical Emergency Team and its management must plan (and practice!) its response to these issues:

• Temporary housing arrangements
• Length of working hours
• Policies about workplace amenities
• Conflicting personal commitments
• Occupational safety
• Conflict and stress
• Ineffective organizational structure
• Ineffective decision-making procedures
• What do we mean by "success?"
• How do we keep a real-time record?
• Who speaks for the technical team?
• Information security
• Mental health
• Compensation and recognition

Temporary housing arrangements

If your contingency plans callThese inset quotations are from Texas Bix Bender's book of cowboy wisdom 'Don't Squat With Yer Spurs On!'for technical team members to be housed near the work site during the peak of the emergency, you might have to consider some relatively surprising constraints.

Housing

For general emergencies that affect a large number of organizations in the immediate geographical area, you'll be contending with many other organizations for scarce temporary housing. Make arrangements beforehand if the event is at all predictable.

Infrastructure issues: food, water, clothing, laundry, electricity, communications, transportation

Once you've required staff to temporarily locate near the work site, you might have assumed legal, or at least moral, responsibility for their infrastructure needs. Be certain that you can provide for them. If you can't be certain of adequate supplies, be aware of your legal responsibilities in advance.

Personal issues: home and family

It's possible that the very same emergency that affects your organization, and which requires the on-site presence of the Technical Emergency Team, also affects the team members' homes and families. Or there could be other pressing personal needs — aged parents, child-care responsibilities, conflicting commitments of all kinds.

Entertainment and recreation

If the team is away from home for more than a few days, they'll need personal time for entertainment and recreation. Provide it — and pay for it. The returns to the organization in morale, productivity, and reduced management difficulties far exceed the costs.

Length of working hours

In emergencies, we sometimes demand long hours from technical team members, probably in the belief that this practice speeds up resolution of the technical emergency. While there's some evidence that mild stress does improve performance, few of us know enough about the life of any other person to make judgments about how much additional stress is needed to optimize performance. In practice, this "Performance Optimization Theory of Stress" is little more than a belief without a factual foundation. Let it go.

Instead, trust your people to do the best they can. Realize that the people on the Technical Emergency Team are the best you could find — maybe even the best there are. They're professionals who understand the full impact of the emergency, perhaps better than you do. They're dedicated to resolving it, not only for the good name of the organization, but for something even more important: personal professional pride. No pressure you can add, no demand for longer hours, will be more effective than that strong, internal drive. Give them what they need, remove bureaucratic obstacles, get yourself out of the way, and they will get it done — if anyone can.

Policies about workplace amenities

Normally, outside of an emergency, your organization may have constraints that are designed to preserve values not absolutely critical to organizational survival. A dress code, limits on where food can be eaten, constraints prohibiting the provision of food, entertainment, or first-class accommodations at company expense…the possibilities are innumerable. Except in circumstances where safety is threatened, suspend them.

You gain productivity in two ways. First, the team feels special — and they are. You have communicated to them in a clear, concrete way that what they're doing is more important than are the suspended rules and norms. And of course, it is. Second, by removing the strain of adhering to rules that really aren't mission-critical, you enable them to focus more of their energies on the emergency.

For example, if you have a suit-and-tie/nylons dress code, and you suspend it, you save each team member 15-45 minutes a day, remove the need for access to dry cleaning, reduce the bulk of clothing needed for the temporary relocation, and reduce laundry costs. The workplace atmosphere becomes more casual, which might be needed to offset the additional stresses of the emergency. Or you might have policies that prohibit you from providing dinner to employees working at their home base. Suspending that rule is a cost-effective way to relieve stress and lift morale.

Conflicting personal commitments

Team members might encounter personal commitments that conflict with the organizational priority. Although you might want to provide personal services to them to resolve this conflict, be careful. What might seem to you to be a perk might seem to someone else to be an invasion of privacy.

Personal commitments that can conflict with the emergency can include family illness, medical appointments, death, or other events; societal demands, such as tax audits, jury duty or military duty; or infrastructural issues such as auto or home repair, errands of many kinds, or traffic jams. Commitments might also be correlated with the emergency itself. For example, in a chemical release, the team member's home might lie in the evacuation area.

Even if your organization is willing to assume some of these responsibilities, that's only half the decision. The other half is up to the members of the Technical Emergency Team. Unless they're willing to let the organization take care of these things, respect their privacy. Contingency plans that provide for the organization to offer to assume of some of these responsibilities should also provide for the possibility that some team members might decline the offer. Formulate your plans on the assumption that some team members will be unavailable. Run some drills this way too.

Occupational safety

Be certain that the team is aware that acts of individual heroism are undesirable, because they might actually threaten the effort. Factors that threaten the lives of the Technical Emergency Team members threaten the success of the entire emergency resolution effort because team members are critical to success — they have special skills and knowledge not easily replaced. Everyone should understand that this isn't a Hollywood movie. The organization can provide a model of this attitude by taking measures to protect the safety of everyone working on emergency resolution.

Burnout is one example of a threat factor that we often overlook. Because its causes aren't immediate precursors of their effect, burnout seems to appear suddenly and without warning. Yet it can undo an emergency response team as effectively as any catastrophic event. Watch for its signs and act quickly to prevent its development.

Conflict and stress

The emergency itself is a source of stress. If any team is under great stress for a period of time, conflicts can erupt, either within the team or between it and other elements. While training in conflict response is always useful, it's essential for a Technical Emergency Team and for its management.

Training is especially valuable if it's both cognitive and experiential and if the team goes through it together. They will then share a common language for talking about conflict, and common tools for dealing with conflict. This enables the team to anticipate conflicts, to limit the energy required to deal with them, and to work with conflict using a shorthand language.

Ineffective organizational structure

Most organizations have structures that determine spans of authority, control, and responsibility. In an emergency, this structure can be disrupted by communications failures, infrastructure failures, death and injury, and (usually involuntary) absenteeism. Contingency plans cover these situations, typically, by providing for backup controls if one or more of the normal controls is inoperative. But even this approach can fail in a technical emergency:

• Choke points can develop. People can be swamped by new responsibilities, and the organization can become unresponsive.
• To function effectively, people in search of requisite approvals must know where to go to get them. In a dynamic emergency situation this information can be hard to find and can lead to delays.

In a technical emergency, give the Technical Emergency Team the authority it needs to solve the problem, within the law — especially signature authority for expenditures. It's unlikely that all of the normal controls are functioning anyway, since the technical justifications for actions the team wants to take are probably too arcane to relay to the usual authorities. Since the work of the Technical Emergency Team is likely to be in the critical path to resolution of the emergency, removing barriers here has high schedule payback. If you take this approach, be certain that the entire organization is aware of it.

Ineffective decision-making procedures

Technical decision making in emergency mode is fundamentally different from decision making in project management mode. In project mode, we often search for consensus. We allow teams to develop their own solutions, within broad constraints. We make efforts to be certain that everyone is informed about issues and impending decisions. We review all work before accepting it.

The only way to drive cattle fast is slowly.In an emergency, it might be necessary either to move more carefully (read: slowly) than we do in project work, or to move more rapidly, taking risks we would not take ordinarily. Most of us can easily imagine why we might want to take shortcuts in an emergency, accepting additional risk for the sake of speed. But why would you ever want to move even more slowly than in project work? And what are the implications for decision-making procedures?

In an emergency, some safety margins are paper thin, maybe even zero. For some decisions, there's no margin for error. None. If we make a wrong decision, the enterprise might be finished; people might die. For other decisions, even in an emergency, there is a margin for error. Knowing the difference enables the team and management to choose where to take risks, and where not to, with the goal of ending the emergency and returning to normal project work mode. Having a solid understanding of risk management is often the key to successful technical emergency management.

People forget how fast you did a job — but they remember how well you did it. — Howard W. Newton

Decision-making processes in an emergency are therefore risk-centered. If the issue is high risk, we must slow down. Use consensus. Inform everyone. If the issue is low risk, we can take shortcuts, understanding that there's a price that will be paid in the future — hopefully when the emergency has passed. In either case, the usual processes are probably inadequate. For high-risk decisions, standard processes are probably not careful enough. For low risk, they're too careful. Take the time now to build a risk assessment capability and to formulate decision procedures for technical emergencies. Once the emergency arrives, you'll find it hard to work on developing either the capability or the procedures, because you'll be short of two things: time and a clear mind.

What do we mean by "success?"

The earliest activities of the Technical Emergency Team should emphasize assessing what's meant by "successful emergency resolution." Work out answers to questions such as

• If we save the community, but ruin the plant, is that an acceptable solution?
• If we shut down operations for one week to rebuild the databases, is that acceptable?

Understanding the solution requirements at an early stage helps the team to avoid wasting time and resources looking at solutions that are unacceptable to the organization.

Never run from a fight. If you're gonna get hit, it's better to take it in the front than in the back — and it looks better. But management must understand that it may be necessary to take a big hit now in order to avoid an even bigger hit later. Solutions that seem unacceptable in the early stages of an emergency have a funny way of becoming more acceptable as time goes on, as the emergency deepens, and those earlier unacceptable solutions become possible no longer. Take your medicine early — you'll end up taking less.

These are difficult questions — it's best not to wrestle with them for the first time during an emergency event. Run some simulations far in advance. Simulation experiences can help streamline the process of uncovering emergency resolution requirements. This streamlining can be the difference between success and failure, and it can even save lives.

How do we keep a real-time record?

As work proceeds, the team will undoubtedly investigate blind alleys. The nature of the emergency might evolve or escalate. The team might try experiments, hoping for positive effects. These activities must all be documented. Capturing information about the event as it unfolds is useful not only for later examination and organizational learning, but for learning in real time, to help resolve the emergency.

If there's a complete record of what's said and done, the team can review it for clues that might help it understand the outcomes of attempts it makes to solve the problem. Video and audio recordings of all team activities, backed up by continuous transcription, can be most helpful. Since this can be expensive and cumbersome, reserve it for high-risk emergencies.

Who speaks for the technical team?

It's important to offer to the public, or to your internal public relations staff, a knowledgeable technologist who will be respected. This person must be well informed and technically competent. A good example of this technique in action is the role of chief accident investigator designated as spokesperson by the National Transportation Safety Board (NTSB) when an air crash has occurred.

Unlike natural disasters, technical emergencies are often invisible. Even when they're visible, the dynamics of the emergency may be poorly understood, either by the public, by the Technical Emergency Team, or both. These factors conspire to make it difficult for the media to satisfy public curiosity with visuals or concise explanations. The media then become dependent on your spokes people to provide the right words. Access to an articulate, technically competent individual, either as a knowledge resource or — even better — as a spokesperson, is a prerequisite to successful management of the public relations aspects of the emergency.

Information security

Never miss a good chance to shut up.Other members of the Technical Emergency Team may encounter pressure from the more energetic members of the media community to provide background information. Do your best to insulate team members from the media, for two reasons:

• Continual demands for status updates defocus the team from emergency resolution activities.
• Each team member has a unique view of the state of things, especially when the situation is fluid and there are many unknowns. Discrepancies in what various people say are bound to arise, and the media will seize upon these differences. Correcting or managing this situation then becomes an additional drain on your organization, and may delay resolution of the emergency.

You can best achieve insulation by providing housing, transportation, and living support services to all members of the Technical Emergency Team and their families for the duration of the event. This may not be practical, but do as much of it as you can. Educate everyone on the team with respect to the dangers of information release.

Mental health

After the event is resolved, it might be necessary to deal with mental health issues for members of the team, and possibly others, either within your organization or among the larger community. This is especially true when the event involves loss of life or serious injury. Typically, this aspect of technical emergency resolution is ignored completely. When mental health considered, services are usually provided in the post-event context. These can include a range of services from time off to psychological counseling and even residential treatment.

But preparation is far more effective than remediation. Train your team. Make them aware that the assignment they have accepted entails some psychological risk. Give them the training they need to recognize difficulty as it happens, and support them in real time during the event. If you can provide a mental health professional on site during the event, you can limit the effects of the experiences that might otherwise cause enduring difficulties.

Compensation, recognition, and celebration

Rather than make it an afterthought, plan for it and budget for it. When the emergency is resolved and the organization is spared an untimely demise, celebrate success. Memorably! And at the celebration, recognize the people who made it happen. If you ever expect your people to stretch themselves for the organization again, compensation should be substantial and memorable.     Top

Contact me

Is response to technical emergencies an open issue for your organization? Could you benefit from some expertise in managing teams under the stress of dealing with technical emergencies? Through consulting, workshops, or coaching, I can help your people learn to navigate in the strange world of technical emergencies.

Contact me to discuss your specific situation, by email at rbrenIyeJIiAfnGdKlUXrner@ChacsxirZwZlENmHUNHioCanyon.com or by telephone at (650) 787-6475, or toll-free at (866) 378-5470 in the continental US.

Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info