Shoshin, a concept in Zen Buddhism, translates to ‘beginner’s mind’.  It is the idea that we approach a concept with an open mind, eagerness, and a lack of preconceptions even after years of study in an area, just as a newbie would. 

”If your mind is empty, it is ready for anything. In the beginner’s mind there are many possibilities, in the expert’s mind there are few.” - Zen Master Shunryu Suzuki

After several years working in large enterprises, It’s a regular feeling to arrive at a new project and see the perceived constraints that people are operating under.

“Oh, we could do that, but it will take months to get …”

It’s common in most workplaces to see people block new ideas because it’s the way it has always been done. Instead of asking ‘How can we make this happen?’, the focus falls into default thinking, conditioned by years of red tape and guarding against failure.

What if the rules we've implemented to keep us all safe were a knee-jerk reaction to a once off event? What if we've over streamlined our processes to try and replicate the success of the past, at the cost of better ways of working?

The Fallacy of Success

In Ed Catmull’s book Creativity Inc., he writes about the randomness that can occur within the creative process and our highly tuned ability to process this randomness as a linear event, storing it away for future reference.

'Yes! I've worked it out' we proclaim. 'Because we did this… X occurred', meanwhile forgetting the many random events along the way that contributed to the success or failure of the situation. 

It is then vital to ensure that we recognise these events, but not read too much into the how’s and why’s of a success or failure. Rather, accepting the complexity of what we don’t know, we don’t know, and that things will always occur that we cannot predict or control. 

Maintaining an open mind and treating each situation as a new experience is essential to future success.

Beware the Curse of Knowledge

On top of restrictive thinking is the cognitive bias that often accompanies it. The curse of knowledge is an idea developed in the 1970’s, that infers after years of experience in an area, we start to assume that others have the required background knowledge to understand, oblivious to the fact that novices are starting to form their own mental models to fill the gaps. 

This is especially common in software development. After years working with a product, teams often start to make assumptions on behalf of the user, forgetting the simple things and adding complexity at the detriment of a great user experience.

How then, can we start to break down these existing ways of working???

Always Question Why?

When encountering an issue, it is our natural inclination to rely on surface facts to make decisions about the right cause of action. But relying on surface facts can result in only fixing the symptoms of a much deeper underlying problem.

Seeking to improve its manufacturing process, Toyota launched an investigation into its processes in the 1970’s. As a result, the worldwide lean movement was born, and lead the way to the “Japanese Industrial Revolution”. Critical to its success were the techniques developed by Sakichi Toyoda.

The '5 Why’s' is one of those techniques and interrogates surface facts to discover the true underlying root cause.  By asking the question ‘Why?’ 5 times, we can strip back problems associated with teams who have slipped into default thinking. 

Keeping with the automotive theme is the oft-cited example illustrating the 5 Why’s (Wikipedia to the rescue!).

The vehicle won’t start. (The Problem)

1. Why? - The battery is dead.

2. Why? - The alternator is not functioning.

3. Why? - The alternator belt has broken.

4. Why? - The alternator belt was well beyond its useful service life and was not replaced.

5. Why? - The vehicle had not been maintained according to its schedule.

In this case, the resulting answer points to a potential process issue which could be further investigated. Was the customer at fault or is the process itself faulty? How might we make it easier for customers to stick to their maintenance schedule? 

In other situations, the questioning could result with ‘Why is this even a process at all?’

Software Development teams have been using a process of reflection for years through regular retrospective sessions. The sessions deep dive into the things that went well, and not so well in the previous period, creating discussion on ways to continuously improve the development process.

How often do you take time out from your work to check what went well or could be improved? Could you introduce a retrospective into your own workflow to improve your processes?

Side Note: Having recently joined a new team, I’ve experienced another opportunity for teams to re-evaluate. By encouraging new team members to speak out on anything that causes them to think ‘Why are we doing it this way?’ you give yourself an opportunity to re-think the team culture and process. 

I’ll leave you with a relevant proverb about the beginner's mind that a fellow Soccer coach once told me over a cup of tea after training one night - I'm kind of paraphrasing as it was a few years back, but you’ll get the idea. 

“A young mind is like a sapling, it’s flexible, can bend in the wind and mould into many different outcomes. As a mind ages, it becomes rigid, develops deep roots after weathering many storms, but it holds firm until finally one day it breaks.”*

As our work moves away from repetitive tasks towards more creative and unpredictable, it will be more important that we are able to maintain a beginner's mind. Deep rooted, but flexible and curious enough to adjust to whatever is thrown our way. Likewise, as leaders, we will also need to find new and creative ways to motivate people and build work environments that allow people to do their best work.

*He might have said something completely different, but that’s what I took away from it.