Inside and outside perspectives
In my experience, all problems have an inside perspective and an outside perspective1.
The inside perspective addresses the problem on its own terms. It accepts the way the problem is framed, and tries to solve it logically.
I am not criticising this way of doing things. I find this is our human default - and most of the time it’s perfectly sensible. Lots of projects do need you to get stuck in and do some hard work, and to do that you have to accept the way the project is framed. Solving inside problems can be creative and satisfying work.
But....
The problem with the inside perspective is that it can be too compelling.
We are creatures that love to make sense of things, always on the hunt for patterns. This can trip us up sometimes, and lead us to get carried away by the internal logic of a problem or project. We’re so busy filling in the blanks, following from one step to the next, that we lose sight of whether the task is actually worth doing. We lose sight of purpose.2 This is where moving to the outside perspective can be helpful.
The outside perspective is where we ask:
Wait, do I really need to do this?
What is it for?
Can I just make this problem go away?
Is what I’ve done already good enough to move on?
Here are some real life examples of where the moment of switching to the outside perspective could help:
Another operations leader told me that their tech team had just uncovered a fault with their mail servers, that had suddenly dumped 3,000 historical unread messages into their inbox. He said “I’m not sure how I’m going to get through them all.” I said: “Why don’t you just delete them?”
Yes there might be something important in there, but if there is, the person will probably email you again - and if they didn’t email you again, and those emails are old, then it’s probably too late.
Rather than try and find a way to sort through the message creatively (eg building an AI agent to screen or categorise it) - just dispose of the problem.
A CEO had received an invoice from a supplier they disputed. The supplier’s contract said they would do 5 - 10 days per month, at a set day rate. Eventually the client gave the required notice to end the contract. In the final month it seemed like the supplier hadn’t really put much effort in, but they still billed for 5 days of work. The client refused to pay. The supplier responded by suing them. The client said “we’ll see you in court!”
From the internal perspective, they might be totally justified. Why should we pay for work that hasn’t been done? The contract sets up a bargain, and the supplier hasn’t kept their side of it. So we shouldn’t have to keep up ours.
But the external perspective says: what is it going to cost us - financially and in terms of time and energy - to deal with this issue? Would it make sense to just pay for this issue to go away3? Regardless of who is right or wrong, is this something worth spending any time on?
There are many times that I have got caught up in the inside perspective - going further in a project than was needed, having already put so much time into it that it seems impossible not to just tidy up that final bit. It happens all the time!
We need the inside perspective. I would suggest that we cannot get into a ‘flow’ state unless we surrender to it. You can’t get all the benefits of having exercised, unless you accept the framing of “going for a run”. If you’re forever questioning “do I really need to be running right now?” it becomes very easy to stop!
My proposal is not to lose the inside perspective - but to be aware of this framing, of inside and outside - and to build the habit of occasionally asking ourselves some “outside perspective”.
I find the ‘inside vs outside’ terminology useful - but it also goes by a more established name: single and double loop learning.
This is a more general case of the “Karate Kid” problem I describe in the context of using frameworks.
I like David McIver’s question: “Is it a problem, or an expense?”