Don't get trapped by the elephant in the room!

I was part of a webinar with Jeff Barr where he was discussing creating your own luck. One of the elements he talked about was doing something quickly and more frequently can often be better than waiting to ensure you are doing the right thing. He talked about the OODA model which I discuss later, but it got me thinking about how often in technology we so often get caught up in the detail, or even worse, the wrong detail and we end up not doing anything.

So why the headline?

I'm not talking about the "elephant in the room" where the obvious problem is ignored, although I might touch on that later. I'm referring to the story of the blind men trying to work out what they are feeling when its an elephant. They are all touching a different part. The moral is that truth is relative, we don't always know what we are dealing with if we can not see the big picture, and we should respect the opinion of other. For me it is about why we shouldn't be over confident or arrogant in our views or that are perceptions are correct. If you've not come across the story go have a read on wikipedia.org.

But work, and especially technology, can be like this. We can get fixated on one piece of a solution, a problem, a requirement etc. As a result we end up stuck in a state of deciding what something is, or should be, and never just move on and do something.

Agile and Scrum was meant to be a way  to reduce this by developing in small increments and getting quick feedback through the use of demos at the end of every sprint. My experience however seem to be that there is now a lot of up-front work defining what is going to be built before the agile methodologies are applied. The increased focus on product lead design means a lot of up front spec documents and functional process documentation for me seems more akin to waterfall that agile.

For many in technology the, define, measure, analyze, improve and control (DMAIC) process is used, especially in LEAN and 6Sigma. However one of the challenges is that we can get stuck on many of the stages. Trying to define every possible component of a solution before knowing how it will be used. Trying to define what metrics to output when we don't know what technology will be implement.

How often for example have you heard of analysis paralysis. That is when we spend so long analyzing what we need to do we never get anything done.

The search for perfection or adversity to failure can lead us to not even start something.

I remember a story which went along the lines of: A military plane crashed during a snow storm in the mountains. No one knew where they were or the way out and had no equipment to radio for rescue. After a few hours the officer in charge decided which direction they we going and started leading the crew out. They walked for several days until they came to a "house" and could get help. In an interview after he was asked how did he know where to go and the route to take. His reply was that he didn't, but he knew that by doing nothing they would probably all die.

The message is that doing something is better that doing nothing.

As Jeff said in his talk, if you luck is compound. Even if you only have 1% improvement each time you do something the affect is added to previous luck. So after 70 attempts you have double the luck/improvement.

The hope would be over time luck be more based on skill, and in technology experience converts luck to skill and you improvement might increase. If it increased from 1% to 5% then every 15 integrations you have doubled your impact.

The point is by doing something, even if small, a lot you will end up progressing further than by doing nothing.

So what should we do?

Anything is the simple answer.

Doing nothing will get you no where.
Doing something will at least start you moving in the right direction.
But accept that to begin with you might not get the result you want.

You will have failures and accepting this and changing to a fail fast mode is one of the biggest challenges to most people. From the pressure of getting everything right, winning a race, or getting top marks in exam, we are told through life if its worth doing its worth doing right. And that is the goal. I'm not advocating not getting things right. I'm just saying that if we want to move faster we should do so in small steps, some of which might fail.

One thing about a fail fast mindset is that we need to accept failure.

FAIL = First Attempt In Learning

The big issue with failure is we often don't get, or want to get, feedback on why it failed. In order to improve and gain that compound affect we have to get, and accept feedback. Use this feedback to correct anything from the previous iteration and direct effort in the next.

So if you want to fail more often because you are trying new things make sure you also implement a feedback mechanism.

Does this just apply to projects?

No is the simple answer.

This methodology can be used for anything as the example about the plane highlights. Whether it's building a new solution, learning a new skill, or changing a business; fail fast with feedback will be more effective than constant planning and one big implementation.

The OODA loop (Observe, Orient, Decide and Act) is one way to change to this mind set. Look at what is happening, work out where you want to go, make a decision and act on that decision.

If we apply this to technology it might be to observe that a system is not working as expected. Look at what could be causing the issue and orienting on which outcome you want through understanding the components that might be causing the unexpected behavior. Then you need to decide the next action you are going to do such as enable a retry loop or increase lambda memory. Finally you need to act on that decision and return to the beginning of the loop and observe the impact it had. If positive leave in place and move on to next orientation and decision. If negative roll back and try something else.

If we apply this to something like learning we might observe what others are learning, at the moment GenAI. We then might orient towards understanding how LLMs work. We could the decide to complete a skill builder course. And we act on that by enrolling and scheduling time in our diaries. Once done we then look at (observe) what might be next. Is GenAI not right for you or your business? Did you find you want to know about the tech running LLM more than the model? Use this to re orientate and decide what to do next. And so the loop continues and you'll progress towards your goal.

This has been an interesting post for me as it is not about technology but people and process. I hope you've found it interesting and welcome any feedback on the article and if you'd like to see more like this.