The power and value of the the term “yet” is underrated. The power of continuous improvement is only attainable if you continue to challenge the status quo, even in small ways. Often the first step towards this is in our thinking – if we can start to see new possibilities then we can start to move in that direction. Being closed to possibilities might be hurting your ability to continuously improve.

Change and improvements can sometimes stall – there can be many reasons to this, including:

  • Not focusing on core problems
  • Too much change creating “change fatigue”
  • “This is how we’ve always done it”
  • Thinking that making a change is too big

With many of those things, sometimes it’s best to just introduce a small change in language to help push people’s thinking away from the “now” and into the “possible future”. Use the word “yet”. It can be a very simple and useful lead in to a provocation that allows you to start to move towards something better.

Instead ofTry…and then ask….
We don’t know how to do that.We don’t know how to do that, yet.What would it take to know that?
We haven’t achieved that goal.We haven’t achieved that goal, yet.What is the next simple thing we can do to move towards that goal?
We don’t know how the customers will react to that.We don’t know how the customers will react to that, yet.How can we find out?
The team’s morale hasn’t improvedThe team’s morale hasn’t improved, yet. What is impacting their morale?
What can I do to help?
We don’t know how to validate that.We don’t know how to validate that, yet. Is there a safe to fail experiment we can run to find out?

As you can see from the above, we take a statement that sounds quite negative or closed and turn it into the chance of something possible. It also encourages the follow up questions to explore the possible.

Using the word “yet” is a small change in language, but it can light the way to your next steps. It costs nothing to try it and it may open you to possibilities you haven’t considered yet. Try it out and see if you can move towards a new possibility.


Focusing on the problem is something that I continually come back to and remind myself of. There are so many instances that I hear people where they understand a solution and are determined to bend the world to their view of the solution rather than focusing on the problem. Staying in the problem space for a little longer and really exploring and understanding the problem(s) is really valuable, rather than prematurely converging on solutions.

One of the most common things I’m hearing nowadays in technology is around the use of large frameworks. For example, I’ve often heard things like “just install SAFe, SAFe has this feature so you just need to apply it”. Thanks, but I don’t think that’s very good advice. I don’t want to install a large framework to solve my immediate problem. Even if you’ve already bitten the bullet and installed SAFe, do you really think your context always requires the “just follow this recipe” approach? Do you think the framers of SAFe understood your customers and your business when they came up with the framework? Should you really use a “one size fits all” approach? No, this is a solution – let’s spend some more time in the problem space.

Another space I think about this is in sales. I’ve come to learn over the years that sales is about listening to customers and really understanding their problem and their context. Staying in the problem space, listening and asking probing questions only when required is really important. Your customer will tell you about their key problems if you let them and help them with a little bit of guidance. My sales coach has a wonderful article about this entitled “Shut up! Let your customers speak and win more sales“.

Something that I really like in the agile space is the work done by Neil Killick – particularly around slicing. Again, he encourages folks not to converge into the solution space too early. In his article “The essence of story slicing in an agile environment” Neil asks the question of “What are some options for delivering value to a customer as soon as possible”. I like that for a number of reasons – one is that he’s talking about options – again not yet converging, but exploring the problem space. I’ve talked about options thinking in a number of my blog posts as well. He also uses simple techniques for doing this – you just need a basic understanding of English (or whatever language your customer uses!) and you can start to explore the problem space. His focus on customers and timeliness is also another great aspect. He stays in the problem space for some time, finally choosing an option on which to focus, then, and only then, starting to think about solutions.

I also like Kanban’s approach to this. One of the early steps in STATIK (Systems Thinking Approach to Introducing Kanban) is to understand points of dissatisfaction. Both from a team perspective as well as a customer perspective. This is about understanding the core problems before installing a solution. Stay in this space for a little while – explore it, listen and ask those poignant questions. What’s even more powerful is that this is not the end of the process. Once you’ve implemented the solution to those problems, new problems will surface. Iterating through the process regularly will ensure you’re continually focusing on key problems. If you want to learn more about this, come along to my Kanban System Design course and learn all about it.

The consequence of not doing this can be quite grave. You could tank on that sales call, even lose the potential customer. You could waste your time installing a solution but realise that you haven’t solved your problem. Time is the one thing you can’t buy more of, so you need to use it wisely as there are opportunity costs of focusing on the wrong thing. There are not only customer impacts, but there are potentially team impacts. Wasting your team members time can be frustrating – usually the best folks will tend to leave and find somewhere else where they can align better to their customer’s purpose and see the fruits of the labour valuably impacting peoples lives.

So please, don’t prematurely converge on solutions. It can be hard, but stay in the problem space for a little longer. Listen, question, understand. Focus on the core problems and win!


The origin of this statement for me goes back nearly 20 years ago when I attended a technical leadership training event whilst I was working at Hewlett-Packard. At the time I remember thinking that I learned more worthwhile lessons in a week of that course than in entire subjects at university. The title of this post is one of the key lessons that I took away and am still using today.

So, a little explanation is in order as the statement sounds a bit crazy taken out of context. During this training session, we were taken through a series of simulations – with a explanation and discussion of relevant points after each simulation.

The simulation behind this statement was a simple problem solving situation. The idea was that there was multiple rounds and each round there was a “minimum” score that you had to get (I think it was around 20 points). After each round, you presented your solution to the facilitator who would then calculate your score based on the answer you gave. Highest scoring team wins. There was a fairly simple and repeatable way to get 25 points which was over the minimum – it didn’t take a lot of brainpower to figure out. Now, you could try different combinations and there is a distinct possibility that you could fail and get zero points.

Different teams tried different strategies and I remember our team after getting the simple answer started to get bored. So, we decided to experiment. We failed a few times, but it gave us insight to try new things. After a few rounds our scored had dramatically increased (I can’t remember exactly how much, but I think it was in the order of 100-200 points). Within a couple of rounds we had made up any lost scores of the experimentation and we were the winning team.

During the debrief I remember the facilitator saying that he’s seen all sorts of permutations for this exercise. One that he remembers most was a sales team who repeatedly answered with the basic scenario getting 25 points a round. He said at the end he asked them why they did that, to which they replied “We made quota”. This in contrast to our teams approach was very different – we got bored as there was no growth / interest in maintaining the status quo so we experimented.

During our debrief the facilitator was going through how to solve problems – in particular with people working in technical domains. Obviously, when one of our experiments failed, we would try something else. It makes me think of the quote / cliche “Insanity is doing the same thing over and over and expecting a different results” (to which I would add, unless, as cynefin has shown me, you’re in the complex domain and you may well get different results). Anyway, continually repeating a failing practice tends not to be a good idea. Which brought us to the first part of his statement “If something’s not working do something different”.

The next part, relates to how we felt during the simulation. We figured out the basics and were getting bored. This is often the case with technical teams, and I’d also say knowledge workers more generally. They like to solve problems – a solved problem repeated over and over will not keep their interest for long. It also means that you plateau in terms of capability. You need to look for new ways of doing things, for example the evolution of land transport from horse to railroad to car. There’s a ceiling to breeding horses, they can only go as fast as their able – but different means may allow something superior to emerge. Getting around on horse is still viable for basic transport, but we may want something better. This relates to the second part of the statement – “If something is working, do something different”.

Therein lies one of the key lessons I’ve learned in my professional career: “If something’s not working, do something different. If something is working, do something different”.