When the Excuse Is the Real Problem

The deadline was Wednesday, end of day. That was the plan going in: the senior associate finishes the return by Wednesday, I review it Thursday, we issue it Friday. Simple enough. Except Wednesday came and went with nothing turned in, and when I logged on Thursday morning, I could see exactly what had happened. The work had been started a few hours earlier, timed in a way that only made sense if the goal was to get something in front of me before I noticed it was late.

Once I sat with it, the timing told me something more specific than a missed deadline. Somewhere on Wednesday, this person hit a return that was more difficult than expected, and instead of working through that difficulty, the actual goal quietly changed. It stopped being about producing a correct, well organized return and became about having something, anything, in my inbox before I logged on for review. Everything downstream of that shift showed the same priority. Tax journal entries got bundled into one lump entry instead of broken out, so nobody reviewing it could follow what had actually happened. An equity rollforward didn't tie, with an account swinging from fifteen thousand dollars to negative one point four million year over year, a number that should have stopped anyone in their tracks the moment it appeared on the screen. None of that mattered to him at that point. What mattered was the timestamp.

When I asked about the errors, the explanations came fast. Documents were supposedly in a foreign language, though the invoices in question had been in English the whole time. A particular AI tool was apparently needed to finish a step that could have been solved with five minutes of searching, at a skill level well past where that excuse should have applied. On their own, each explanation sounded like a reasonable obstacle to run into during a return. Stacked together, though, they showed something else going on: more energy spent justifying the work after the fact than actually doing it well in the first place.

Here's the pattern worth naming, because I don't think it's limited to one associate or one return. People respond to hitting something difficult at work in a few different ways. Some make the loud excuse, the kind that shows up in an email or a conversation with a specific reason attached. Others go quiet, hit a wall, and just stop communicating until the deadline forces the issue, no update, no "I'm stuck on this piece," no flag that something needs attention before it turns into a bigger problem. What both versions have in common is that the work suffers, and the barrier becomes the whole story instead of a detail in it that got solved and moved past.

I don't know exactly why this shows up more often now than it used to, and I want to be careful about how much weight I put on any one explanation. My guess is that when almost every question has an answer a search or a prompt away, the muscle for sitting with something unresolved doesn't get much practice. I'd rather point at the behavior itself than build a whole theory around its cause.

What I can say clearly is what this costs, because I've watched it happen from both sides of the review process. In the short term, the cost is reputational. A manager or partner does not need to say out loud that they've stopped handing someone difficult work. They just start routing it elsewhere, and the person on the other end usually doesn't notice until they wonder why they've been stuck doing the same routine tasks for two busy seasons running. In the longer term, the cost is developmental. The people who push through the friction, who sit with a hard problem long enough to actually solve it, are building instincts that the people who stop at the first wall never get the chance to build. That gap compounds over years. Five years in, it's the difference between someone who can be handed something ambiguous and trusted to work through it, and someone who still needs every step laid out in advance.

If you take one thing from this, make it practical. The next time you hit something you don't immediately know how to do, try three things yourself before you decide you can't do it or that you need a different tool to finish. Search for it. Look at how a similar problem was solved elsewhere in the file. Sit with it for fifteen minutes before deciding it's unsolvable. If you're still stuck after that, say so, specifically. Tell your reviewer exactly where you got stuck and what you already tried before reaching out. That sentence, on its own, tells a manager more about your judgment than a finished product with three excuses buried inside it.

If this pattern shows up for you specifically around AI tools, not as a stand in for effort but as an actual workflow habit, I wrote about a related problem in The Tool Isn't the Bottleneck. You Are., which covers what happens when the tool becomes a substitute for understanding the work instead of a way to move faster through it.