There’s an old military-style saying I’ve always liked:
“The effective range of an excuse is zero.”
In military terms, effective range is the distance at which a weapon or system can reliably accomplish its intended purpose.
An excuse has none.
I think the same principle applies surprisingly well to IT leadership.
The server is still down.
The project is still late.
The integration still doesn’t work.
The user still can’t do their job.
We can have perfectly legitimate reasons for every one of those situations. A vendor changed something. Funding wasn’t available. Someone made a mistake. A dependency failed. We inherited a system nobody documented. We simply didn't have enough hours in the day.
Those things matter. Understanding why something happened is how we prevent it from happening again.
But understanding the difference between an explanation and an excuse matters too.
An explanation helps us identify the root cause.
An excuse attempts to end the conversation.
As an IT leader, I don't expect my team to never make mistakes. I certainly make them myself. I don't expect every outage to be preventable or every project to go according to plan.
What I do expect is ownership.
What happened?
What can we control?
What did we learn?
What are we doing next?
And what are we changing so we're better prepared the next time?
Good IT teams don't waste energy figuring out who can produce the best reason something went wrong. They put that energy into restoring service, solving the problem, documenting what they learned, and improving the system.
Accountability isn't about finding someone to blame.
It's about refusing to let the explanation become the solution.
Because at the end of the day:
Excuses don't reach objectives. Actions do.