The OK Show Me Loop

Introducing impactful changes in an existing organization or product is often an uphill battle because you are typically working through real challenges in terms of technical debt, organizational structure, skillset gaps, and even personality. I use something I call the “OK, show me” loop to ask for big changes and yet still arrive at them in an incremental fashion.

The OK Show Me Loop

As one may be able to gather from my last post, I don’t like to be restricted in regards to where I can add value to an organization. This type of mindset is not only at times exhausting for me, but I am sure it can be frustrating for those I work with because it means having an opinion about nearly everything.

I do my best to make sure that those opinions are formed objectively, and thus my suggestions are intended to reach an equally objective outcome. That is to say, if we as a team implement the change I am after, then we should be able to look back and measure our success.

Delivery of suggestions is a key element to seeing them through to their successful implementation. Over the years I’ve spent a lot of time reflecting on my own delivery of these kinds of suggestions and figuring out which ones went well and which ones did not.

I eventually came to a repeatable pattern I could extract and train other people to use. I call it the “OK, show me” loop and I’ve presented it below as a simple flowchart:

Ask for big change

Even though it is best to arrive at an outcome incrementally it is still important to ask for big changes. My friend and former colleague Alberto Silveira talks about this in his book as seeking your North Star.

Asking for a big change, whether it is in the software of a product, the process used to construct it, or the skillset of the team delivering it, isn’t to be taken lightly but it also isn’t to be feared so much that it’s never done.

Yes, it will by its nature be disruptive in some way. However, there is great value in making big changes early in your involvement with a product or organization because you can help steer those changes during the maturation process and ultimately work in a better environment for longer.

Further, if you only ask for incremental changes it can be difficult for the team to really see where they are going and make meaningful alterations along the way. People start extrapolating their own conclusions and taking side steps that detract from rather than enhance the journey. This is effectively what people mean when they say things like “Can’t see the forrest for the trees”.

When asking for a big change the way you deliver it is key to your success. You need to make sure that you are presenting the change along with why it’s going to be valuable. What’s the outcome you aim to achieve, and why do you believe so strongly that you’ll be able to achieve it?

Is this a common pattern or way of working from the industry that’s shown success? Delivery your ask in a way that shows the team that.

You also need to explain why the change is necessary in the first place. What is it that you have measured and can show that isn’t working well or could be better? This should be done in a way that isn’t taken as casting blame or passing judgement. The organization and team are already successful, otherwise they wouldn’t have been able to afford hiring you, right? So make that clear in your delivery.

These things apply equally regardless of whether you are talking to a team about making changes to their software, coaching a direct report on new skills, or even making suggestions to other areas of the company such as Customer Success, Product Managment, or even Sales.

We already do that

The most consistent response I’ve encountered when asking for a big change has been “We already do that.” It’s typically well meant, but often inaccurate.

The degree to which you get push back of this nature is going to be a function of how well you delivered your request for big change. If the change has been a long time coming and people are generally excited about it, then you may not even hit this at all.

Chances are though, that you will eventually ask them to change something they already feel that they are doing well enough or that they feel they don’t need to do at all.

Your natural inclincation may be to argue or to continue to justify the change you are asking for. I’ve found it’s better to first seek a deeper understanding by accepting them at their word, but verify by asking them to show you how exactly they are already “doing that”.

You might wonder, as I have, why “we already do that” is such a common push back. I don’t have a data oriented way of proving it, but I think that much of the “we already do that” mentality is an offshoot of Conway’s Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

– Melvin E. Conway

It is less about the design particulars of the system, which can include things other than software products, and more about the fact that people tend to be more defensive about themselves and their team. My hypothesis is that over time people begin to include the product itself in their internailization of what their team is, and therefore can be more defensive of it. You can’t easily separate the thing itself from the people and culture that created it, and so who wouldn’t get a little defensive if someone showed up to say that the thing they created had some improvements to make?

This is all just a warning based on anecdotal evidence that you should ensure the tone of how you ask for a big change and the way you carry yourself while going through verification of whether they already do it or not needs to be appropriate and judgement free.

OK, show me

This is the critical step as it is where you are going to either get convinced that you are wrong or everyone else will come to agree with your realization and start making plans on how to get there. Where asking for a big change is a bit of a leap of faith and takes some bravery and confidence because the fear of being wrong can be overwhelming, asking someone to show you how something works is pretty natural and there’s really never a bad outcome. You can have them give you a demo of an area of the software, walk you through some code or design documents, let you sit in on a sales call, or just show you how to track trends in KPIs.

However you go about this, make sure that the team is providing you with objective data. It’s only fair that they operate with the same level of objectivity as the person making the request for change afterall. If they can’t provide objective data then it doesn’t mean that they are wrong, but it does mean you’ve found at least one incremental change they can make: provding objective data.

The good news is that there are only two ways that this can work out:

1. They really already do what you’re asking them to change. This is actually what you should prefer because it means you can not only move on to the next challenge, but also that you learned something.
2. They don’t really do that. This is far more common in practice, but generally is not a zero sum game.

In the case where a team/product doesn’t “already do that” you’re atleast going to understand why they thought they did and how far off the mark they are. From that deeper understanding you can coach them through what incremental changes they would need to make in order to get to a point where it is worth going back through the “OK, show me” loop again. Just keep going through the loop and iterating until everyone is comfortable about saying, “Yes, we already do that.”

Another way to think about this is that you’re simply repairing the gap between their understanding of what you are asking them to change, and you’re understanding of what they are already doing. You should have already looked into all of what they are showing you before making your request for a big change, but it’s always possible that the conclusions you drew from your research faulty or that the breadth of it wasn’t as wide as you’d thought. Likeywise, they probably should have understood the change you presented better before claiming it wasn’t necessary, but it’s possible that they focused on the wrong elements of it or that your delivery wasn’t as flawless as you’d hoped.

Incremental change

As noted at the start, incremental change is the best way to arrive at your destination. It prevents big changes from becoming a binary outcome and keeps the team motivated by seeing improvement along the way. You don’t really need to measure against the “OK, show me” loop after each increment. Going through it once should give you enough information about what “good” looks like and help you set objective measures to know you’ve reached that point.

I recommend you focus on ensuring that the team has a solid retrospective process and are able to self-evaluate on a regular basis. They are professionals and you should trust them to operate on their own once you’re sure they understand where they are headed and have a way to measure their own success.

You need to keep a pulse of what’s going on, but micromanaging a team is only going to result in them doing exactly what you tell them. That means you are going to lose out on any adaptations they could have made that are better than your own.

We win

I hope that a key takeaway about the “OK, show me” loop is that there is only one terminal state: “We win!”

It doesn’t matter if you are wrong at the start and they really already do what you’re asking for because you are only concerned about realizing the outcome and not how it’s arrived at, right?

Likewise, if the team shows you what they are doing and it turns out that they are off the mark, you’ve all just spent time gaining a better understanding of where you want to be and how to get there.