The path to energy transformation must be walked with flexible, adaptive strides.

While most people intuitively know that iteration and experimentation is necessary for innovation, when it comes time to actually iterate and experiment, people tend to either embrace or reject the idea. Let’s not be hasty to label either mindset as right or wrong, good or bad; as both can be valuable when viewed properly.

Balancing Innovation and Risk Mitigation

The goal of iterating and experimenting is to figure out what works. It’s born from the idea that there are only two buckets for fact-finding in the discovery process: things we think we know, and things we don’t know. Certainty, though fleeting, can only come after iteration and experimentation have taken place.

To the uninitiated, an iterative process can seem risky. Wouldn’t we be better off if we planned everything meticulously up-front and then executed on that plan?

Only in if you lived in a world where at least a few of these things are true:

• Change is minimal
• Your solution is standard
• You’re confident that all of the information is available to you
• The time it takes to implement your solution is very short
• Cost of iteration is high

The reality is that if you’re embarking on a very predictable process that has a high cost of iteration, then yes, you should have a strong plan out of the gate. For example, you’re constructing a building. You don’t want to just iterate into a building, you need to have an incredibly detailed plan and a lot of information upfront.

But as anyone who works in that industry will tell you, iteration still occurs. Plans change, substitutions are made, and information turns out to be wrong. You have to iterate and adapt, but coming in with a detailed plan ensures that the iteration is minimal.

Software Is Perfect for Iteration and Experimentation

But most software projects aren’t like that at all. Software projects are typically:

• Lots of change – the business is changing all the time
• Solutions are novel – you might be solving a known class of problem, but the context is almost always unique
• Information is difficult to uncover – information is almost always institutional or collective, very little is documented. You have to talk to lots and lots of people to understand what a solution looks like.
• Implementation is often long – often software builds can take years, and you’re dealing with change the entire time.
• Cost of iteration is low – relative to many fields, the cost of iteration in software is exceedingly low.

Software is the perfect arena for iteration and experimentation. You need a strong plan going into a software project, but the returns are quickly diminishing for how deep into the details you go with that plan. In software projects, consistent discovery through iteration and experimentation will counterintuitively almost always lead to better outcomes than big up-front plans.

If you’re in the energy industry, you might be squirming in your seat a little bit. It probably sounds like we are flying a little fast and loose. But that isn’t the case, we are just acknowledging the reality of the situation. If we try to get too detailed, the details will end up being wrong, and will cause a false sense of security.

Humans are really bad at:

• Knowing what they want
• Digesting really big documents and telling you what is missing
• Forecasting the future

When we put together huge detailed specification documents, this is exactly what we are asking people to do. So instead we get to the 100 foot level, and then we leave some of the details until the last responsible moment.

But believe me, I’m not just advocating for willy-nilly unrestrained experimentation. Risk is inherent to experimentation, but that is why constraining it is so important. We have to mitigate risks when conducting experiments, which can be done with thoughtful planning. Here are a few questions to serve as a safety net for experiments and iterations:

• How small is it? If it is small enough, just go!
• What are we trying to learn? If it is bigger, then what are we setting out to learn?
• Are we comfortable innovating here? Maybe the accounting system isn’t the place?
• Can we break this down into smaller experiments? If the experiment feels too risky, can you break it down and get to success/failure faster?
• How much are we willing to invest in this? Is this worth a week? A month? A year?
• How much do we stand to gain if this is a success? If success would pay off enormously, then it is probably worth a bigger risk.
• What is the worst possible outcome? What do we stand to lose? Just the time we put in? Political capital? Are we risking the timeline of the project?
• How likely do we think this is to fail? If we think there is a huge chance of failure, maybe we move on.
• How will we know if we have succeeded? Defining what success looks like is incredibly important, sometimes there will be disagreement on what will need to be proven for the experiment to be considered successful.
• How will we know if we have failed? Conversely, when should we stop?

The Psychology of “Failure”

It’s logical to view iteration and experimentation as risky, but in reality, in many contexts it is the most effective way to move forward. If you wait for ideas to be fully fleshed out and baked before you ever start working on them, you’ll struggle to ever innovate.

Fortunately, experimenting works best when you have multiple viewpoints contributing to your success. And so next month we’ll take a look at why co-creation is crucial for energy transformation. This post marks the third chapter in our journey through energy transformation. If you haven’t already, we encourage you to explore the first and second parts of the series to gain a comprehensive understanding of our discussion.