When is the Right Time to Change Your Mind?

Reflecting

You have many opportunities in life and business to change your mind. Each of us has many opportunities, but we don’t always take those opportunities. We may be conforming to social constraints and expectations or don’t want to risk appearing inconsistent by changing too often. Let’s look at a non-serious example and extract nuggets we can apply in a business context.

1) The Background

I’m in a situation right now where I’m having to re-evaluate my aims. Fortunately it’s not a serious situation and there are a few parallels to my professional life. I play guitar and I own a few guitar amplifiers. Each guitar and amp has its own tonal identity and quirks. I pick the right tools for the job; playing in a 60s Motown/soul band requires different guitars and amplifiers than playing in an 80s hair metal cover band.

At a gig at the beginning of Summer this year, I played using a very nice amplifier and it sounded awesome with the band. I really enjoyed how it sounded and I probably played better because I was comfortable that it did the right job.

2) The Hypothesis

I thought that I could use the same amplifier with a few changes in my set-up (i.e. a different effects pedal or two) and I would again have an awesome sounding rig, but this one would be suited to the 80s hair metal cover band I’m currently playing in.

Two things to learn from this:

1. Review the Evidence. For an analogy, let’s call the choice of guitar, pedals, amp and speaker a product. More accurately, it’d be a bundle, but it’ll suit the article better if I refer to it as a product as some of the related terms are more commonly known. This product was partly proven for a different genre. The parallel would be the product was been proven in a different market or industry sector. But the exact same options had not been proven by me to work for this particular requirement. I had checked online on forums and knew it may work (from my own experience, I knew it had a chance of being a workable solution), but that’s not the same as a significant market position. I guess from the perspective of the guitarist, we see famous people playing equipment all the time often as endorsees. If they can make it work, then we should all be able to make it work. And many products become popular through this adoption based on social proof (read Cialdini’s Influence). This is the first point that I could have changed my mind. If I’d have found contradictory evidence (i.e. that the product has been tried in that market and does not work), then I’d have to have changed my position or faced a struggle to get it to work for this genre.

2. Understand the rationale behind decisions: I had chosen a product that didn’t have great product-market fit, but was proven in a lot of different markets. I’d chosen it because I didn’t want to invest in another product (i.e. yet another guitar + amp set-up). Many of our clients have similar situations where they already have legacy applications or even those that are very current that they are committed to but don’t consider legacy. Introducing new products creates overhead, in terms of maintenance, storage, inventory, etc. These wastes are well-documented through Taichi Ohno’s work. It’s not just about physical products either, additional processes add additional effort, although this may not be visible initially. Similar to physical products, new products will require additional effort to maintain, to govern, to monitor, to improve, etc.

3) The First Test

This was the easy part and consisted of me trying the various combinations at home and deciding which one worked for me. Two things to learn from this:

• What’s the quickest test you can do? This is the rough and ready test. It’s a mock-up or equivalent to a run-through of the process. It doesn’t prove it’s ready, but can prove it’s not ready. In my case, the tone and playability were very good at home and easily acceptable for my requirements.
• Fine-Tune the product. It allows for some fine-tuning (no pun intended) of the product. In my case, I swapped an effects pedal for one more suited to the genre. This allowed for a more tailored product to go through to the following stage. If it had failed here, then I’d have repeated this step, swapping out components as necessary or, when out of options, I’d have proven the hypothesis false and chosen a different starting position.

4) The Road Test

Mic and Light

As good as the test at home may have been, it doesn’t take into other factors. These other factors, e.g. the tone and volume of the other instruments in the band, the rehearsal room, etc, will have an effect on the product when being used. Usually when designing and implementing changes, we have to consider the end user. This would involve training courses and materials, feedback loops, user engagement, etc. In my case I was lucky that I was the only person who would be actively using this product, but not the only person experiencing the product.

A rehearsal would be equivalent to a model office. There are no paying customers involved, the other team members are aware there’s a test and we can fail comfortably, aware that we are there to learn and to prove that what we’re trying to do can work. But the conditions are artificial.

Test with similar constraints

In the band, the first thing that I found out was that I was too loud. That’s surprising as I’m an experienced guitarist, it’s very common to ask young guitarists to turn down. I usually just set the volume levels to roughly equal the drum volume. On that day, the drummer played quietly. Easily solved, I turned the volume down. Now guitar set-ups can be fickle. What sounds good at one volume, may sound weak at another volume. Similarly, with processes and systems, we design them to run within certain constraints. Too much traffic and the process becomes saturated and queues develop or customers go elsewhere. Too few traffic and staff become complacent, forget how to perform the activities since they don’t do them often enough.

Take into account the human affects

The sound difference between a louder volume and a quieter volume could be the quality of the amplifier, etc or it could be a reflection of the Fletcher-Munson curves (that were indirectly responsible for the Loudness buttons on hi-fis if you’re old enough to remember them). Similarly, people behave differently and we have to be aware of the issues that this can create. For instance, bear in mind the Hawthorne effect (the corollary of which implies that people will behave differently when you’re not there) and the Dunning-Kruger effect which we have to counter in the early stages when team members act over-confident with new changes.

Leave time to fix it and run the tests again

We test for a reason and it may be couched in other terms such as unit test, walk-through, acceptance test, regression test, etc. But the primary purpose is to assess the fit-for-purpose of what’s being tested. If it fails, fix it, put a plaster over it (e.g. a temporary workaround while you fix it) or start again. I’ve seen so many project plans that include a testing phase because the project manager knows he has to have one, but then there’s no opportunity for running the tests a second or third time, and no time to fix the faults. In those instances, change the plan as soon as you can and set the expectations. Every project will find faults with the product; the question is how many and how severe. If there are no faults, then I’d question the thoroughness of the testing. Even in a culture of zero defects, there will be misunderstandings and wrongly-set expectations affecting how users will interact with the system. Each testing phases provides an opportunity to reflect and that’s what I use the test review for. It’s not designed to be a criticism of performance, it’s an evaluation of suitability and an assessment of whether to allow the changes to progress to the next stage. Those decisions allow us to introduce more change or direct the change to make it more suitable. In the band, I rarely introduce a new component unless there’s time to test it and swap out for something else, so I wouldn’t turn up to a live show with untried equipment.

Plan the time of the change

I’m fortunate, the other band members are patient, allowing me to work through my options. My commitment to them is that I won’t waste time in the middle of songs, wanting to stop and start. I only change the options in the short gaps between songs and stick with the sound until the end of the song. In parallel, I wouldn’t implement changes to teams until the point that they’re ready. Change should occur at the times of least stress due to the stress that adapting to the changes introduces.

Follow your head, not your heart

I wouldn’t advise this as a mantra for life, but I’m having to do it right now. I have one more test left before I call it a day for this product and start with a different set-up. I could waste a lot more time trying to get what I want out of the product I want to use, but that’s more emotion than sensible. In the end, there are other people in the band and I have a role to perform. So the sensible option is to change the product. Similarly, when changing how people work, be practical about your role and their situation. By all means, listen to their heart, but do the sensible thing, not necessarily what you want to do.

Identify what needs to be completed quickly

This isn’t in terms of quick-wins, instead I find it useful to identify the changes that need to be implemented before you can build other changes on top of them. Think of them as the foundations for change. For me with the guitar, it’s the amplifier that’s the foundation in this situation. That will drive the rest of the options. Choosing the correct amplifier will allow me to introduce other changes more slowly over a longer period of time. It sets the character for the tone in the same way that changing from a push to pull process will set the dynamics for the new process.

5) Sunk Cost Doesn’t Matter

I frequently have this issue with my clients. They’ve invested time and money in a solution and don’t want to expend more time and money on a new solution because of what they’ve already spent. Emotionally, it makes sense. Politically, it makes sense; you wouldn’t want to be the person responsible for saying that the past spend has been a waste, especially if you’d commissioned that spend. But logically, it makes no sense. Remember this regarding past costs: what’s past is past and has no bearing on the future. From the point that you are making the decision, the only costs to bear in mind (logically) are the future costs.

For me in the band, I own the amp that I’ve proposed using. I know it, I’m familiar enough with it and I’m happy taking it out of my comfort zone to see if I can use it for a different genre. There’s a sunk cost in there, in terms of the actual cost of the amp, but also the effort involved in learning a new amp. Logically, it’ll come down to what’s the cheapest (money and time) option to get the most appropriate sound for the genre. This relates to the Follow your Head section above.

6) What’s Your Strategy?

There’s a balance between swapping and changing every day without a plan and swapping frequently according to a defined plan where everyone can see what’s being tested and how it leads to a solution. Defining the strategy first allows us to create a plan to deliver against that strategy. We set the scene for how we will test our progress and that allows us to keep stakeholders (whether employees or bandmates) informed. That provides them with the opportunity to suggest improvements to the plan, offer their opinion about the potential impacts. At this point, you could change the plan, but check against the strategy first. Does the potential revision still deliver the strategic aims? My highest strategic aim is to achieve an 80s guitar tone that’s suitable for the band I’m playing in. My second aim (which is of lower priority than the first) is to do it with a simple combination of components that means I don’t require multiple amps, etc for multiple genres.

7) Conclusion

Each of the points above presents an opportunity to change the solution based on feedback (either from me or bandmates) along with the opportunity to change the solution completely (e.g. different guitar, different amp, etc). Similarly, in a business environment, we shouldn’t shy away from changing our minds. Change according to the strategy, but keep the strategy consistent so that everyone knows where they stand, what the aims are and has at least a rough idea of how progress will be achieved.

In every organisation, we encounter many situations where we receive feedback but don’t process it in a way that facilitates change. It’s ok to say that a proposed change doesn’t meet the strategic aims, it’s not necessarily acceptable to say that a change doesn’t conform to the plan. Maybe the plan is wrong.

In addition, in looking at all the above opportunities for change, it’s not about when, but why. Instead maybe the question could be better phrased as What are the Right Reasons for Changing Your Mind? That then raises the question about what the triggers are. Many of those triggers in an implementation project are listed above.