Morgan is handling it
I’ve stopped telling people their systems are on fire.
I used to explain root causes. Map timelines. Build neat little visuals to show just how thoroughly everything was broken.
Now I just say:
“I’ve got it.”
That’s what they want to hear. Not how bad. Not how broken. No details. Plausible deniability.
“Don’t worry. I spoke to Morgan - he’s handling it.”
And I am.
Who cares if:
- there’s no requirements,
- no product to speak of,
- a hostile client who resents you even existing,
- a team that won’t speak to each other,
- decision makers whose AI strategy is built entirely from LinkedIn carousels?
I’ve got it.
The Curse of Competence
It always starts the same way.
A broken script.
A non-responsive server.
I fix it.
People notice.
Then comes the moniker: “Fixer.”
Nothing official, of course.
No promotion. No budget. No fanfare.
Just a new kind of fame. A reputation.
Suddenly, I’m being invited to more meetings.
At first, they’re just background noise.
Then I’m the one asking questions.
Then they’re waiting for my opinion.
People swing by my desk with:
“Can you take a quick look?”
(It’s never quick.)
Eventually, I stop getting assigned projects.
I start getting assigned problems.
Not features.
Not deliverables.
Not even a roadmap.
Problems.
A client is about to walk. A team is about to quit. A mission-critical system needs to move - but no one knows what it does.
The documentation is gone. The author, long since vanished, or worse - promoted. All that remains is a single requirement:
“Just fix it”
Nobody knows what “it” is exactly. Only that if it breaks, someone very senior will notice. Eventually.
Then come the projects where nothing makes sense.
Teams of only managers.
Products without versions.
Environments with no deployment.
Ticket descriptions like:
“Make it work.”
No one knows how it got this far.
But now it’s my problem.
I start digging through the remains.
READMEs for code that never existed.
Half-written configs.
Abandoned branches.
Wikis filled with traces of people long forgotten - Who are you, mysterious “Deactivated user”? What did you see?
Trying to piece together what it does - or what it was supposed to.
Every time I pull off the impossible, I’m not rewarded.
I’m recalibrated.
Each time swearing to myself: never again.
Eventually one of these will be impossible
The problem with being a miracle worker is that people start expecting miracles.
At first, I worried I’d be wrong. Like Cassandra - sounding the alarm, preparing for the end, only for the sun to rise the next day.
Now I worry about the one that breaks me.
The one that’s actually impossible.
The one where I’m right - and no one listens.
But no one listens.
Because I’ve done it before.
Because I always find a way.
Because I’m the guy who walks into the fire and walks out with a working pipeline and a neatly labelled diagram.
If I say it’s bad - I’m being negative.
If I say it can’t be done - I’m not a team player.
If I say anything at all - I’m told:
“That sounds like a delivery problem.”
So now, I don’t say anything.
I nod.
I smile.
What’s one more late night?
One more Saturday?
I take the harpoon.
Because this one might be the white whale.
And when it drags me under, they’ll still ask why I didn’t swim harder.
Hopelessness is the onboarding process
I don’t get frustrated anymore when I join something new and everything is already broken.
I expect it.
Onboarding begins with a new email address you can’t access, permission requests that never resolve, and calendar invites that land in the wrong inbox.
Three minutes into trying to do some actual work, you get the inevitable ping:
“You not joining?”
I used to read wikis.
Now I don’t even bother.
Folders. Sections. Pages.
An exquisite castle made of sand, at low tide.
README files lie.
Diagrams never updated - if they were ever even real.
But that’s not the problem anymore.
The real issue is the team.
The engineer who’s stopped speaking in meetings.
The PM who doesn’t know what the last release contained.
The data scientist who quietly rebuilt the pipeline on their laptop - because it was faster than getting access.
That’s the real onboarding:
Uncovering who’s holding it together through sheer force of will.
And who’s already given up.
I recognise it all, for what it is:
An essential part of the process.
Hopelessness needs to be embraced.
Rock bottom must be found - rock is the only reliable foundation.
If Parkinson’s Law says work expands to fill the time available, then its inverse must also be true:
Impossible situations force clarity.
There’s no room for fluff when the whole thing is on fire.
It’s not really a project until an executive bursts in demanding:
“Why is this so hard?”
While the technical team quietly mutters,
“I don’t think it’s even possible…”
And then, inevitably:
“So, what exactly have we promised the client?”
A 16-week proof of concept.
No scope.
No team.
No data.
And technically… the contract started twelve weeks ago.
Excuse me while I go scream in the janitor’s closet.
“Morgan’s got it”
The real trick isn’t fixing broken systems. It’s learning when not to say anything.
You could tell them how bad it was. You could explain what it took to fix. Or how brittle it still is.
But you won’t.
Success doesn’t bring relief. It brings scrutiny. When things start working, people get nervous.
You remind them, the thing they said couldn’t be done… was.
And that makes you inconvenient.
The doubters reappear - asking questions they already know the answers to. Requesting documents no one will read. Scheduling interrogations disguised as reviews.
Quietly rewriting history.
They won’t thank you. But they will remember you. And they’ll be sure to let everyone know, they did the real work.
If you’re smart, you stop trying to be the hero. No medals. No applause. Just the quiet nod from the person you dragged from the wreckage.
Nothing exploded. This time.
Status quietly turns green, accompanied by a Teams message no one will see 06:34 on a Saturday:
“All set. Let me know if anything else comes up.”
Spoilers - it will
By
