Good Decisions, Fast.

Software product development is a series of difficult and vital decisions: build product A or B, enhance feature C or D, use technology E or F, refactor or rebuild, improve or deploy? I would even suggest that running any business is similarly “just” a series of value decisions — decisions that seem to be much more difficult to make in the knowledge industry given its abstract nature.

The common and fashionable business mantra is make good decisions, fast. Implying that a merely good decision on time is better than a perfect decision made too late. But also, in my opinion, implicitly stating the need to make bad decisions fast, in order to learn from those mistakes and quickly pivot towards good decisions.

Good Decisions, Fast is not about the individual manager, leader, or CEO’s ability to make those decisions. Neither is it about one software or product superstar’s performance. It’s about the organization as a whole, as manifested by its product development teams, to make those decisions, fast. And unlike the founding CEO, who has grown this ability over years tending her start-up, the organization has to learn this skill through repeated trial-and-error based on a safe-to-fail culture built around trust and strong teams.

Make a lot of bad decisions, quickly, and cheaply — and ensure continuous organizational learning from those. Along the way, we will end up making a number of good decisions, and will capitalize on those that end up having the most leverage.

Make Good Decisions, Fast. We are trying to maximize good decisions that lead to increased engagement and revenue. But we’re not only trying to maximize the absolute number of decisions themselves, but the rate at which those decisions are made. Further, good decisions are only good if they are implemented, delivered to production, tested, proven to be good, and ultimately lead to increased engagement and revenue.

I am convinced that fast feedback loops are at the core of this connection, and that as leaders we should be concerned with making those fast feedback loops happen as efficiently and with as much follow-through as possible.

Fast feedback loops cannot be achieved with top-down control. The traditional software development life-cycle model (mostly “Waterfall”) eschews short feedback loops for the hope to make perfect decisions once and execute on a strictly scheduled plan for maximum predictability. Mistakes, common cause or special, are seen as negative and abhorred. Feedback from those mistakes is rarely used to adjust planning, and ultimately many projects are doomed to failure both in terms of execution and in terms of eventual business success. Now, nothing is ever as black and white as I would like it to be, and these methods still exist for a reason. For one, because in my opinion they give a sense of control to a discipline that is intrinsically abstract, extremely complex, and difficult to manage. But also because for some type of very deterministic projects, these methods are sufficient and the predictability is desired. Think shooting a rocket to the moon, a well understood problem with little variation and lots of intrinsic predictability (the moon’s distance, orbital mechanics, propulsion, etc.).

In my next post I will go into more detail about how existing Agile best practices enable fast feedback loops. I will attempt to describe, in detail, how company vision and strategic planning (Hoshin Kanri) methods can help shorten feedback loops, coming full circle with my term paper post.

Like what you read? Give Bernardo Fanti a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.