One thing I have reservations here is the suggestion that the elusive quick, recoverable decision is better than the one that follows a process.

I get that in this article it is in service of explaining other concepts. That assumption, however, is very flawed. Here's why:

- assuming that decisions are reversible or easily recoverable: this is far away from showing agility and adaptability. This is used to justify decisions that lack an understanding or appreciation of consequence to everyone involved. It is taken on the basis of "I know best", the trademark of the one-trick pony; "I know enough", disregarding a sense of listening in a complex environment; "no need to consult", attempting to operate in isolation; "that we'll fix later", showing a lack of responsibility with the implications of the decision; "it's easier that way", which is a bias for convenience.

- assuming that even if they are reversible, a quick decision is better by default because it is action afterall. These are the people that believe that any reflection in business is a sign of analysis-paralysis. That speed to market and competitiveness demands anxiety and prompt responses

- one that this article is implicitly making: take the quick decision because models fail us in usefulness and delays afterall.

It doesn't mean that using gut instincts and heuristics are not helpful. They are massively important and liberating, reducing tension and managing stress. However, they are not to be used for every decision.

Suggestions that help us balance decisions:

- recognize complexity? Reflect first. Engage others. Communicate with clarity. Understand implications, and plan accordingly.

- in the universe of simple and complicated decisions, isolated and gut-driven decisions trumps consideration and engagement because they are faster. Recognize though that the problems we're paid to solve are not trivial, and this is not a path for solution

- empathize. Feel yourself in the shoes of the customer, the partner, the team that needs to rework things in the system because you've quickly decided is best. Consider what that does to the relationship. You'll see that your decisions are reversible to you, but they drive implications to others that may not be reversible.

- learn to match problem with the right model. Don't take shortcuts. Reflection early in your career will give you a clear sense of which tool to use later. It's a slow process.

- embrace failure, which requires not only reflection, but willingness to do thing differently. That will lead to better positioning yourself in the landscape of future decisions.

I realize I just wrote an article lol. Gotta publish this somewhere.

Expand full comment

I like this visualization of how we use models. By pointing to the fact we may not be using the same models (or over-constraining to a model) is really great. I think this is why techniques like six hats work the way they do.

However, there is no way I will ever interpret ICP as anything other than Insane Clown Posse.

Expand full comment

The motivations and reasons for not having one catch-all-model seems similar til the motivations for having multiple bounded contexts in a domain-driven design context. I love when something sems applicable in different contexts, and i think it speaks of a deeper truth. I love the perspective on it having tradeoffs and that it's a matter of balance. Overall great read.

Expand full comment

Excellent, this is an approach that has worked very well for me in the past.

Expand full comment