Yes, I think this is an anti-pattern is similar to the one I often see, basically getting the order wrong like this:

1. Define the problem.

2. Gather information about the problem.

This seems reasonable. "We need to know what we're trying to solve, not boil the ocean."

But it is really common that the information tells us that the problem definition is slightly or really wrong. Hence the importance of gather information, then define the problem... and iterate.

"First define the problem" also feels reasonable because picking the right problem requires a lot of context and experience. Some would add "taste." So in group discussions, people often suggest bad problem definitions. Others then want to get focus and traction. That impatience often results in committing too early to the problem definition.

Go To Market/Project Management?

> Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.

My last company did this. It usually devolved into a design-by-committee full of compromises to make various stakeholders happy and often yielded a worse artifact.

It became more effective once people got burnt out on the process and most stakeholders stopped caring and started rubber stamping, allowing the one or two people willing to put in the energy to come up with something coherent.

I worked for AWS for several years, eventually leaving during the big "return" to office push because my geographically distributed team working on a product that didn't exist back before the remote period was told we had a month to either move to one of three cities where our team was allowed to work out of our transfer to a team in our area. My wife had an autoimmune condition that would put her at risk if I commuted, so I asked my manager what processes there were for exemptions, but he literally hadn't been told anything by the higher-ups and that as far as he was aware, there were no processes defined at all and we'd have to just try to talk with HR and upper management to try to figure something out. I didn't think that the company expecting me to rush to figure it out when they were the ones who put an artificially constrained timeline on us to either abandon what we had been working on it uproot our lives, so I ended to just giving my notice a couple of days later instead.

My point here is that companies that love to have extremely formal processes around for to handle technical things are not necessarily less likely to have extremely arbitrary decisions without any process for recourse defined when it comes to how employees get treated. If someone describes a technical process that they say they use for everything that a literal reading seems pretty dubious in regards to things like burnout or micromanagement, I don't think it's that crazy to recognize that the reality is probably at least as bad as the obvious implication. Sure, they're not directly saying "I overwork my employees by imposing short deadlines on everything and I nitpick their processes if they different from my own", but there are enough managers who do act this way that it's kind of hard to think someone who cared about being perceived as saying that wouldn't go out of their way to clarify where the nuance is if it truly exists.

I think how important this step is something you realize once you consider the alternative, which is trying to fix a problem, without knowing, what the problem is. It is going to result in weird workarounds instead of addressing the actual issue.

Define, identify, name

Just another instance of him being wrong, i guess. (Which he absolutely, most definitively loves!)

“let Claude figure out what’s going on before doing something”

“then ask Claude to do it fast with no mistakes”

(edited for accuracy)