THE OPERATING CODE  |  011

ESCALATION HAS A PURPOSE

Escalation doesn't always mean going to upper management. To me, it means recognizing when a problem has reached the limit of the person or group currently working on it and bringing in another level of knowledge, resources, authority, or support.

That can happen several times before an issue ever reaches senior leadership.

A crew might run into a problem and work through everything they know to try. Eventually, the foreman may decide they've reached the limit of their experience and call the superintendent. Maybe the superintendent has encountered the problem before, knows something the crew doesn't, or can recognize something they overlooked.

If the superintendent can't resolve it, that doesn't automatically mean the next call needs to be the project manager. There may be another superintendent, foreman, or technician who has dealt with that equipment, customer, or type of problem before.

I've always believed in using the knowledge already available within an organization. If I have five experienced people who might know the answer, why would I ignore four of them simply because the organizational chart says the problem belongs to somebody else?

Eventually, though, you may reach a point where the people involved have exhausted what they know. That's when the superintendent should be able to call the project manager and explain what's happening, what they've already tried, and who they've consulted.

There's a big difference between saying, "We have a problem," and saying, "Here's the problem. Here's what we've checked. I've talked with several people who have experience with this, and we're out of ideas."

The second conversation gives the next person something useful to work with.

Know Why You're Escalating

Not every problem needs to be escalated for the same reason. Sometimes you need another set of eyes or somebody with different technical experience. Other times, the problem requires additional manpower, equipment, material, or resources that aren't available to the people currently working on it.

There are also situations where the people involved understand exactly what needs to happen but don't have the authority to make the decision. That's a different kind of escalation, and it's important to recognize the difference.

Then there are problems serious enough that leadership needs to know immediately. A significant safety concern, major quality failure, contractual issue, substantial financial exposure, or situation that could seriously affect a customer shouldn't slowly work its way through every possible level while people continue trying to resolve it quietly.

Severity changes the escalation path. When something presents an immediate safety concern, the priority is to stop or secure the affected work and involve the appropriate people without delay. Other serious issues may require immediate notification even while the field team continues working toward a solution.

Good judgment means knowing when another reasonable attempt is appropriate and when waiting could make the situation worse.

Understand the Different Escalation Paths

Another thing I've learned is that escalation doesn't always follow our internal chain of command. Customers have their own procedures, and sometimes those procedures determine where a problem needs to go next.

In telecom, for example, a technician may encounter a particular alarm or condition at a cellular site that requires escalation through the customer's technical organization. That doesn't necessarily mean the problem is severe. It may simply mean the technician has reached the limit of what they're authorized or expected to troubleshoot, and the customer's procedure identifies the next point of contact.

The same principle applies to engineering, equipment manufacturers, vendors, subcontractors, safety departments, and quality personnel. Depending on the situation, several people may be working different parts of the same problem through separate channels.

The field team may be working with the customer's technical support while the superintendent is coordinating resources internally. At the same time, the project manager may be addressing a contractual or commercial concern.

Those conversations can all be necessary, but they need to support one another. People should understand who is responsible for each part of the problem, what information needs to be shared, and who has the authority to make the decisions involved.

Otherwise, you can end up with several people working on the same issue without anybody having a complete understanding of what's happening.

Don't Start the Investigation Over

When a problem eventually reaches another level of leadership, I don't want everybody starting the investigation from the beginning unless there's a legitimate reason to revisit something.

I want to understand what happened, what has already been checked, who has been involved, what they've determined, and what options remain. I also want to know how the problem is affecting the work and what the person escalating it needs from me.

If somebody tells me a subcontractor isn't performing, that's a starting point, but it doesn't explain what's actually wrong. Are they understaffed? Are they having trouble meeting the schedule? Is supervision the problem? Do they lack the experience or equipment needed for the work? Have those concerns already been discussed with them, and what was their response?

The same applies when material is late. I want to know when it was expected, when we learned it wouldn't arrive, what the revised delivery date is, and whether there's another way to keep the work moving. Maybe we can adjust the sequence, locate material somewhere else, or make a decision that reduces the impact.

With a technical problem, I want to know what has been tested, what has been ruled out, and who else has looked at it. That information can save a considerable amount of time and prevent people from repeating work that's already been done.

I don't expect somebody to have every answer before asking for help. If they did, they probably wouldn't need to escalate the problem. But I do expect them to communicate what they know and what they've already done.

The purpose is to give the next person enough information to help move the problem forward.

The Next Level Should Add Something

I believe people need the opportunity to handle problems within their own responsibilities. If a superintendent and project manager have the knowledge, resources, and authority to resolve something, I don't need to insert myself simply because I hold a higher position.

But when they've reached their limit, my involvement should provide something they don't currently have. Maybe I've encountered the problem before, know somebody with the right experience, or can help them look at the situation differently. Maybe they need additional resources, coaching, or a decision that requires authority beyond their own.

Sometimes the problem requires involvement from senior subcontractor management, engineering, or somebody on the customer's leadership team. In those situations, my responsibility isn't necessarily to come up with the technical answer myself. It's to help connect the problem with the people or resources capable of resolving it.

And if I don't have the answer or the authority either, then I need to recognize that and take the issue to somebody who does.

A higher title doesn't automatically make somebody the final answer to every problem.

I think that's an important part of leading a larger operation. As your responsibilities grow, you should become less involved in personally solving every field problem and more focused on understanding when your involvement can actually help.

Customer Relationships Matter Before Problems Happen

There are also times when a problem requires involvement from somebody higher in the customer's organization. I don't believe those relationships should begin the first time something goes wrong.

Some customers appreciate regular communication, while others prefer to be contacted only when there's something that requires their attention. Part of managing those relationships is understanding their expectations and respecting how they want information communicated.

When an issue does require executive customer involvement, I want to understand what the superintendent and project manager have already communicated and what the customer's escalation process requires.

Before contacting the customer, I want the facts. What happened, what is the actual impact, what are we doing to correct it, and what can realistically be recovered? I also want to know who's responsible for the corrective action and when the customer can expect another update.

If the failure belongs to us, we need to acknowledge it. Apologize when appropriate, explain what we're doing about it, and follow through on what we promise. The customer doesn't need to hear a long explanation about which department failed to do its part. They need to understand the situation and know that we're taking responsibility for addressing it.

The relationship you've established before the problem matters when that difficult conversation becomes necessary. Trust doesn't eliminate the problem, but it gives the conversation a better place to start.

Escalation Isn't Failure

I don't want people hiding problems because they're afraid asking for help will make them look incapable. Nobody knows everything, and even experienced people eventually encounter situations they haven't dealt with before.

At the same time, I don't want people passing problems along the moment something becomes difficult. I expect them to think, use the resources available to them, and make reasonable attempts to resolve issues within their responsibility and authority.

There has to be a balance. Asking for help too quickly can prevent people from developing their own judgment, but waiting too long can waste time, increase costs, and allow a manageable problem to become something much more serious.

I've learned that there comes a point when continuing to work on the same problem with the same people and the same ideas isn't accomplishing anything. That's when you need another perspective, additional resources, or somebody with the authority to make a decision.

The higher you move in an organization, the more important it becomes to recognize those situations without automatically taking over the work. Your experience should help you understand the problem, but your responsibility is to determine what kind of support is needed and how to provide it.

Sometimes that means bringing in technical knowledge. Sometimes it's making a decision, providing resources, or following a customer's required process. And sometimes it's simply recognizing that the people currently working on the problem have taken it as far as they reasonably can.

The purpose of escalation isn't to add another name to the conversation. It's to move the problem forward.