The Pattern I Keep Getting Hired For
Early in my career I thought I was getting hired to run programs. Build the plan, manage the risks, hit the dates. Useful work, and I was good at it. Several years on and numerous programs in, I noticed something that changed how I see my own role.
The programs were never really the point. The point was the mess I kept getting handed right before them.
Look closely at the situations I keep getting pulled into and you’ll see a theme. A team that isn’t delivering and nobody can say exactly why. A platform decision that’s been stuck for two years. A launch date the CEO already announced and an organization not set up to hit it. The common thread isn’t the technology or the industry. It’s the absence of structure. No clear operating model, no shared definition of done, leadership expectations and business outcomes pointing in different directions.
That’s the work. Walk into the ambiguity, reorganize the people and the process, get the right people pointed at the right problems, and put the frameworks and operating model in place that should have been there all along. Then drive the thing across the line to deliver real value.
Smokejumpers get dropped into a fire from above, but the point isn’t the jump. The point is that they land inside it and work the thing from the ground, methodically, while everyone else is fighting it from a distance. That’s closer to my job than “program manager” ever was. I’ve done it enough times now to stop thinking of it as luck. It’s a pattern. Here are three times it showed up.
When the scale is the hard part
Starbucks ran its workforce management on Kronos. Two hundred fifty thousand people across ten thousand locations depended on it for their schedules, and it was aging out. Replacing it was a $51M decision with a Tier 1 business case attached, which meant the tolerance for getting it wrong was very low and the visibility was very high.
The technology choice mattered, but it wasn’t the hard part. The hard part was that a replacement at that scale touches labor law, store operations, payroll, and the daily reality of a quarter million people. All of those groups had opinions, none of whom owned the outcome. So before we moved a single store, the work was building the operating model. Who decides what. How a change gets approved. How changes are managed. What “ready” means to ship code. And then, what “ready” means for a location before it goes live. What we do when something breaks at two in the morning in a store three time zones away.
We replaced Kronos with Blue Yonder across all of it with zero business disruption. The number people remember is the $51M. The number I remember is zero, because at that scale, zero is the whole game.
When the constraint is the hard part
At Honeywell I owned an SAP HANA migration in a regulated aerospace manufacturing environment. Different kind of hard. Here the ambiguity wasn’t political. It was technical and financial. A landscape that had grown over years with no clean path forward, a fixed budget, and the kind of compliance overhead that makes “we’ll figure it out as we go” a non-starter.
You don’t improvise or iterate your way through that. You build the structure up front or you miss the mark. We mapped the landscape, redesigned it, sequenced the migration so the dependencies actually held, and ran it through to cutover and stabilization. It came in on time and $200K under budget.
I’m a little proud of the under-budget part, but probably not for the reason you’d think. Coming in under budget in a regulated environment isn’t about being cheap. It’s evidence that the planning was honest. We knew what the work actually required because we’d done the structural thinking before we spent the money, not during.
When the people are the hard part
The third one is the one I tell when someone asks whether I can actually lead, not just deliver.
Enterprise payroll was in trouble. The reporting workstream was facing the kind of trouble where every status update is a little worse than the last and everyone’s working hard but nothing is improving. Earlier in my career my instinct would have been to grab the wheel and drive myself. Along the way I had learned that instinct is wrong, and here’s why.
The problem wasn’t effort. It wasn’t that everyone involved didn’t want to do a good job. They did. It was that the work had no shape and the right people were pointed at the wrong things. So I reorganized it, and then I did the part that actually mattered: I handed the prioritization and stakeholder work to a TPM on my team who was ready for it and hadn’t been given the room. The risk was real. Handing off the most visible part of a recovery to someone unproven was not the safe move. I could have kept it myself, and if it failed, it would have failed on my hands. That’s the safe kind of failure. Instead I staked my reputation on her ability, and my job became building the structure she needed and then getting out of her way.
She ran it. The program recovered. And the lesson stuck harder than any framework I’ve written down. The leader’s job in a mess is not to be the hero who fixes it. It’s to build the conditions where the right person can.
What the three have in common
Different companies, different decades, different technologies. Scale in one, constraint in another, people in the third. What holds across all of them is the shape of the work.
I get handed ambiguity. I reorganize the people and the process. I get the right people aimed at the right problems and give them room to own it. I put the operating model and the frameworks in place that should have been there from the start. Then I drive it across the line to value that someone can actually measure.
I used to think my job was the program or the product. Now I know it’s just the visible part. The real work is everything that has to be true before it can succeed, and building that when it doesn’t exist is the thing I keep getting hired to do.
The messy situation isn’t the obstacle. In my experience, it’s the job description.
If you’ve been the person who got handed the mess, I’d like to hear how you worked it. Find me on LinkedIn or Substack.