THE OPERATING CODE | 012

KNOW WHERE THE DECISION BELONGS

If you want people to grow, you have to let them make decisions. If you require them to call you every time something doesn't go exactly according to plan, eventually you will get exactly what you trained them to become: people who call you every time something doesn't go according to plan.

That isn't leadership. That's dependence.

But the opposite is just as dangerous. Giving somebody responsibility doesn't mean giving them unlimited authority. Good judgment is knowing which decisions belong to you, which decisions belong somewhere else, and when you need to stop before doing something you cannot undo.

When somebody encounters a field problem, I want them thinking about the solution. But that doesn't always mean I want them waiting until they have the solution before they tell me there's a problem.

Those are two different things.

NOTIFY EARLY. KEEP THINKING.

The severity of the problem determines how quickly I need to know about it.

If it's a routine field condition that a competent foreman can work through within his authority, work through it.

But if the problem could affect scope, schedule, engineering, material, cost, an outage, customer requirements or require an irreversible decision, I want to know early.

That call can be simple:

"We ran into an issue. I just sent you a couple pictures. Let me work through some scenarios and I'll get back with you."

That's enough.

The foreman hasn't handed me the problem. He still owns it. He's still thinking through possible solutions.

But now we're working in parallel.

While he's looking at the physical condition and developing options in the field, I can review the pictures. I can pull up the construction drawings. I can check the scope of work, specifications or whatever other artifacts we have available. I can determine whether this is something we have authority to decide ourselves or whether the customer or EOR may need to be involved.

If it looks like outside approval might be necessary, I can start preparing that process while the foreman continues working through the field condition.

Maybe he calls me back with two solutions.

By then, I may have a third.

Now we're having a productive conversation instead of starting the investigation from zero.

What I don't want is a call four hours later saying:

"We ran into a problem four hours ago. We've been trying to figure it out, and we think we have two solutions."

Now I have to stop whatever I'm doing, pull up the drawings, review the photographs, understand the condition and determine whether somebody else needs to approve it. If customer or engineering approval is required, that process is only now beginning.

We didn't save four hours by waiting to notify somebody.

We lost four hours of parallel work.

Early notification does not mean premature escalation. It means giving everyone who may eventually be involved enough time to do their part while the problem is still being worked.

Notify early.

Keep thinking.

BRING OPTIONS, NOT JUST PROBLEMS

Once the condition is understood, I still expect the person closest to the work to think.

Don't simply tell me, "We have a problem," and wait for me to solve it.

Tell me what you're seeing and what you think we can do about it.

Maybe there are two options. Good. Now we have something to work with.

Which one is faster? Which one carries more risk? Does either one affect quality? If the first solution doesn't work, can we return to where we started? Are we about to cut, remove, relocate or permanently modify something? Do we have pictures of the existing condition? Have we seen this problem before? What did we do the last time?

The purpose of those questions isn't to make somebody guess what answer I want.

It's to teach them how to evaluate a decision.

Eventually, I want them asking those questions before they ever call me.

START WITH SCOPE

The first boundary is scope.

Is what you're proposing part of the work we're responsible for?

If it isn't, stop.

An unforeseen condition may look like a simple field problem and still create additional labor, material, equipment, outage time or cost. At that point, it may no longer be a means-and-methods decision. It may be additional work that requires authorization.

Being capable of performing the work doesn't mean you have the authority to commit the company to performing it.

The same applies when a solution requires material. Don't just tell me you need a part.

What part?

Where can we get it?

Where does it need to be delivered?

How quickly can we get it?

And while we're waiting for it, what else can we accomplish?

One blocked activity does not automatically mean the entire job is blocked.

KNOW THE RED LINES

There are certain conditions where my expectation is simple:

Stop.

If the proposed solution deviates from the stamped EOR drawings, stop.

If you're going to cut something, stop.

If you're about to make a permanent modification, stop.

If you cannot return the installation to the condition it was in before your decision, stop.

The harder a decision is to undo, the more certain you need to be before you make it.

That doesn't mean every field adjustment needs management, customer or engineering approval. Construction drawings cannot anticipate every physical condition that will be encountered in the field.

Maybe the planned route shows something bending left, but the actual site condition requires going underneath first and then turning left. If both approaches meet the same requirement, maintain the applicable standard and produce the required end result, there may be nothing wrong with either solution.

That's a field decision.

If I'm not there and can't understand the condition from the description, send me a picture. Send me a video.

Make the condition visible before we make a decision based on an incomplete explanation.

There is a difference between changing the method and changing the requirement.

Know which one you're doing.

USE THE EXPERIENCE YOU ALREADY HAVE

Sometimes a competent foreman calls me with a problem and my response is:

"What happens if you don't do it?"

"Are we done for the day?"

"What did we do at the other site when we had this problem?"

Those aren't trick questions.

I'm trying to get them to use experience they already possess.

If you've solved essentially the same problem three times before, I shouldn't have to solve it for you the fourth time. The conditions may not be identical, but experience has value only when you learn to recognize where it applies.

Sometimes the answer is also standing ten feet away from you.

Ask the crew.

That doesn't mean every field decision becomes a vote. Chain of command still matters, and somebody still owns the final decision. But the person doing the work may have noticed something you didn't.

Collective experience is a resource.

Use it.

ESCALATE THE DECISION, NOT THE THINKING

As people develop, I expect their escalations to change.

Early on, someone may call and say, "We have a problem."

Later, I want to hear, "We have a problem, and here are the options I see."

Eventually, I want to hear, "Here's the problem. Here's what we think we should do. I need your approval before we proceed."

At that point, they may not need me to solve anything.

They may simply understand that the decision exceeds their authority.

Sometimes my answer is, "I'm good with it."

Other times it is, "Don't touch it yet. Let me get this in front of the customer or the EOR."

Then the crew stays productive on whatever isn't affected while we wait for the answer.

That's what good escalation looks like.

Escalation shouldn't transfer the thinking upward just because the decision has to move upward.

AUTHORITY HAS TO BE TAUGHT

I learned this lesson the hard way over the years.

One of the easiest mistakes management can make is assuming employees understand where their authority ends simply because management understands it.

They don't automatically know.

A policy sitting in an employee handbook doesn't guarantee that somebody understands how it applies when they're standing on a job site facing something they've never encountered before.

The operating environment changes. Customers change. Regions change. Regulations change. The conditions employees encounter change.

Training has to change with them.

When somebody makes a bad field decision, accountability still matters. The person making the decision owns their part of it.

But management needs to ask another question:

Did we actually prepare that person to recognize that this decision wasn't theirs to make?

Sometimes the answer will be yes, and the employee ignored what they were taught.

Sometimes the answer won't be as comfortable.

Maybe the procedure wasn't clear. Maybe the chain of command existed on paper but wasn't reinforced. Maybe the company entered a different region and encountered conditions its existing training never addressed.

You don't improve an organization by stopping the investigation at the person who made the mistake.

You find out why the decision made sense to them at the time, and then you close that gap.

THE STANDARD

I don't want people calling me for permission to do their jobs.

I do want them notifying me early when a significant problem could eventually require action at my level.

Those aren't contradictory expectations.

A foreman can notify me without handing me the problem. He can keep working through his options while I work through mine.

That's how you create efficiency without creating dependence.

I don't want people waiting four hours to tell me about a significant problem because they thought they needed to have the answer first.

And I don't want them calling me every ten minutes because something didn't go exactly according to plan.

I want them to understand the difference.

Too much escalation creates dependence.

Too little escalation creates uncontrolled risk.

Late notification wastes time that could have been used in parallel.

Judgment is knowing where those lines are.

A strong leader doesn't make every decision.

A strong leader develops people who know which decisions they can make themselves, which problems require early notification, and when the decision belongs somewhere else.