Setting up the long excuse

If you’ve watched shows like Burn Notice, Leverage, or dozens of older movies and television, you should be familiar with the “Long Con.” A series of small and subtle steps that lead to a bigger end game. Strangely, a new practice has shown up in a lot of people that comes across as “The Long Excuse.”

It’s a small series of self-induced hurdles, excuses and roadblocks, so that when a project or task doesn’t complete as expected, the excuses are already at hand. The seeds of doubt have already been sown, ready to be reaped if needed.

It starts with a series of comments being laid down on why a project or task didn’t go as expected. Instead of leaning into the problem, understanding it and coming up with a new solution or approach, the following phrases are presented during meetings and stand-ups.

• This is a lot harder than I originally thought
• I “had” to attend this meeting
• I “had to step in” and work on X
• This other project was handed to me and needs my attention
• This person wasn’t in the office so I lost a day
• “The tool” wasn’t working so I lost a day
• I didn’t hear back from X so I lost a day
• I got derailed by situation X
• “This” wasn’t ready so I couldn’t continue my portion

In every case, it’s a small, but plausible excuse as to why something didn’t get done, took longer than expected or didn’t work out as originally forecast. On the surface, they seem legitimate and reasonable. These things can happen on any project.

However, if you look back over the time and take them together, it’s a clear pattern of creating a scapegoat that can be brought whenever the task fails, a deadline is missed, the requirements don’t contain the correct information, or isn’t what the group expected. It’s basically a pre-emptive way to shift blame.

In the past couple of years I’ve seen this done with Developers, QA engineers and even Product Managers. In every case, they were ready with their reasoning on why a project failed. Their tale of woe was ready to recite, and in so doing, dropped the blame at the foot of someone else.

At first glance it’s hard to see because nothing seems out of the ordinary. Issues arise, roadblocks come up, schedules conflict.

In many cases, the person offering the excuses is good at covering their tracks and shifting blame. It’s subtle so no one questions.

Over time though, a pattern emerges. Questions need to be asked.

• “Was that person really not available?”
• “Was the tool really broken?”
• “Did you really “have” to be in that meeting?”
• “Does it really make sense that this one day loss has resulted in this outcome?”
• “How many one day losses can you actually have?”

Not all excuses are created equal. Running into an impediment doesn’t always tell the whole story. One small bump in the road isn’t an issue, but what about dozens?

In looking back, I can cite at least 6 people I’ve worked with that took this route. What’s obvious is that it takes more work to lay the foundation of excuses than doing the actual work.