Episode 037 – The Work That Always Loses Is the Work Nobody Is Waiting On

Summary

Under load you shed work in a preset order, the same way a grid sheds load to protect itself, and that order runs on external forcing function rather than importance. Anything with a person waiting on it survives. Anything self imposed goes first, no matter how much it matters. Chris never made one decision to drop a client turnover package. He made a series of defensible decisions to defer it, until the client’s equipment went down and the training and documentation they needed had never arrived. The episode gives three places to read your own order on an ordinary week: what you drop first, what you take back, and what you skip while telling yourself you sped it up.

Takeaways

  • Load does not create your default. It reveals the order you already run, which means you can read it at thirty percent load instead of waiting for a crisis.
  • Your shed order runs on external forcing function, not importance. Anything with a person waiting on it survives. Anything self imposed sheds first.
  • You never make one decision to drop the work. You make a series of defensible decisions to defer it, and the answer comes back the same every time because the inputs never change.
  • What you drop first is consistent, not random. That consistency is what makes your order readable before the load arrives.
  • Pulling a task back onto your own plate under load is shedding that looks like helping, which is what makes it the hardest tell to catch.
  • Speeding work up is calibration. Skipping it is shedding. Engineers routinely call the second one the first.
  • A protected list needs two or three items. Ten is a wish, and if you do not choose what gives, the event chooses for you.
  • Deferring work does not reduce it. It reprices it.

Transcript

This transcript was produced by robots and left as-is. Accuracy and elegance are not guaranteed.

Client emailed me. Equipment was down and it was holding up the whole line. They needed it running, but they couldn’t get it there because the in-house knowledge and documentation wasn’t in place yet. The training and as built I owed them from Project Closeout, they hadn’t been delivered.

I never decided not to deliver that package.

Last episode, I said that pressure amplifies your existing default. It doesn’t create a new one. That leaves an obvious question wide open. How do you figure out what your default is before the pressure shows up? That’s today.

So here’s the comparison. Under frequency load shedding. When a generating unit trips offline, the grid frequency drops. The system sheds loads to protect itself.

And it sheds in a preset priority order.

That order gets configured in advance, in a room on a normal day by people who are not under any pressure or stress at all.

And that’s deliberate. Nobody makes a good call about priority during an event. Frequency is falling, you have seconds or less. And that is not a moment to be weighing which feeder matters more.

Here’s the part that matters for you.

If nobody configures it, the grid still sheds. It just sheds whatever trips first. And that might be the thing you needed most at that time.

You already have a shed order.

You just probably didn’t design it.

Now load doesn’t create your order. It reveals it, which means you don’t need a crisis to read it. It’s visible at 30% load on an ordinary busy week, if you know where to look.

The obvious assumption is that your shed order runs on importance. It doesn’t. It runs on external forcing function. Anything with a person waiting on it survives. Anything self-imposed sheds first, no matter how much it matters. If you’ve seen the urgent and important grid, this is the box it labels.

And doesn’t explain. Important and not urgent isn’t a category people fail to recognize. It’s the category with nobody standing behind it.

Closeout documentation fits that to a T. No hard deadline, nobody chasing it. Nothing trips this week if it doesn’t go out. And there’s always something new arriving with a name attached and a date on it. Nobody’s screaming for the documentation until something trips. And then they are.

I never made one decision to drop that documentation. I made a series of defensible decisions to defer it over and over. And the answer came back the same every time because the inputs never changed.

That’s close to episode 30, so let me separate them. 30 was about which commitments you take on. This is about which one loses when two of them collide, and why it’s the same one every time.

Your list probably looks like mine. The delegation conversation you’ve been meaning to have. That process fix everyone agrees is needed, that nobody has time for. Because there’s always a workaround. The career conversation with your boss. Your own skill development.

All of it important. All of it shed first. Because nothing external trips when it doesn’t happen.

So how do you read your order on a normal week instead of during an event? There’s three places to look. One, what do you drop first?

The 1 on 1 that gets moved. The check-in call that becomes an email and then a text. Whatever goes first is tier one on your shed list. And it goes first every time. That consistency is what makes it readable. It isn’t random. You’ve run this order before. Two, what you take back.

Under load, which task do you reclaim from someone else? Which thing do you quietly pull back into onto your own plate because it’ll be faster? That’s your default identity showing up right on schedule.

This one is the hardest to catch because it never looks like shedding. It looks like helping.

Three, what you speed up versus what you skip.

Speeding something up is calibration. Skipping it is shedding. Engineers routinely call the second one the first one.

Here’s another one of mine. Outreach for my coaching business. There’s no deadline. There’s nobody waiting if they don’t even know I exist. Nothing trips out if it doesn’t happen this week. So it sheds. And the website tweak or that message honing, those things survive because they produce a visible output.

Fear might be in there somewhere, but it isn’t required to explain it. The absence of a forcing function does the job on its own.

So build the list before your next loaded week, not during it. And it has two halves. First, what goes? Named in advance so that shedding it is a decision instead of an accident. Second, what’s protected all the way down? There’s got to be two or three items max.

If your protected list has 10 things on it, it isn’t a scheme. It’s a wish. You cannot protect 10 things without giving something up. And if you don’t choose what, the event chooses for you. It’s the same as the grid. Configured on a normal day when everything’s running fine. Executes automatically during the event.

So back to that email. The forcing function did arrive on that documentation. It just arrived weeks late from someone who assumed the work was already done. On a day their equipment was down and the people who knew the details had moved on to another project.

An afternoon at closeout became a line down and a client who couldn’t help themselves. Deferring it didn’t reduce the work. It repriced it.

So here’s a question to take away. What’s on your shed list right now that nobody is asking about yet?

No Comments

Sorry, the comment form is closed at this time.