Decide or Wait

Lean believes that late decisions are often better than rushed ones. However, waiting too long can lead to missed opportunities. As time passes, you will be more equipped about what is best, and it is always easier to refactor later (if the cost is not too high).

Decisions are a process, they should not be written in stone. Deciding something is a process, it allows us to move on. However, we should be challenging our past decisions, that is why time to reflect and think is important. Architects need to protect their time to have time to think. Engineering teams must have retrospectives to reflect on past decisions.

Sometimes it is too soon to decide, you might not have data or not be sure. You must balance the cost of waiting versus the cost of deciding now. Lean has a tool to deal with this called cost of delay. If the cost of delay is low, you can wait more. If it is high, you must decide now.

Experimentation is a good way to make temporary decisions, and then figure out what sticks and what does not stick. You can try A/B testing, feature flags, or prototypes to gather data and make informed decisions later. Deciding and waiting are not mutually exclusive, they require balance.

Why you need to know this?

Because such dilemma happens almost everyday if not everyday. Knowing when to decide and when to wait is a key skill for architects and engineers. It allows you to make better decisions, avoid mistakes, and deliver value faster. For instance if it’s a catastrophic decision better way. If the cost of waiting is high, better move.

That’s why it’s important to reflect about decisions, usually in retrospectives. Nobody does this but I believe in something I call Blameless Feature Reviews which could help us to learn 100x more from our decisions. Such reviews usually happens but only with high executives, and IMHO we must use a proper DevOps blameless mindset and be with the whole team.

Otherwise who is learning? Only the people who don’t build the software?