Someone once told me that I needed to think outside the box.
My first thought was, where is the box? We need to find it first.
If I don't know what box I am in, what exactly am I thinking outside of?
We use "think outside the box" all the time, especially when we want someone to come up with something different.
But I think we jump to the outside part too quickly.
What is the box?
Is it the process? The technology? The way the organization works? A limitation? A regulation? Or maybe an assumption that everyone has accepted over time?
I want to understand that first.
Start with the box
Something may have been designed a certain way because of a limitation ten years ago. The limitation may no longer exist, but the process stayed. After a while, nobody even remembers why it was designed that way.
It just becomes the way things are done.
This is why problem formulation matters so much to me.
What are we actually trying to solve? Why does the problem exist? What has to happen, and what are the real constraints?
Sometimes when you break the problem down far enough, the solution starts to look very different.
Understand what the system needs
Close to 20 years ago, when I first started Sysinco, I was working on a hardware prototype that needed a specialized control interface.
The straightforward approach involved designing a custom circuit board, getting an engineer involved, building the board and testing it.
I started looking at what the system actually needed.
It needed to receive the correct input signals.
A keyboard already had a PCB that did that, so I reused the keyboard PCB and built the controls around the signals I needed.
Another part of the prototype had to store a collection of discs, allow someone to select one, retrieve it and load it into the device.
That got me thinking about a jukebox. It already solved much of that problem, so I started looking at how the mechanism could be reused.
What mattered was understanding what those things actually did. The keyboard gave me the input signals I needed, and the jukebox already solved the problem of storing, selecting and retrieving discs.
Technology makes this especially relevant today.
AI can become part of the box
AI is a good example.
Everybody wants to use AI.
So the conversation quickly becomes, where can we use AI? What can we get AI to do? How do we add AI into the process?
I would rather start further back.
What are we trying to improve, and why? Then we can look at the information we have, where the friction is, what decisions need to be made, and whether AI actually helps.
The technology itself can become part of the box if we have already decided what the solution should look like before we fully understand the problem.
There is more than one box
Organizations make this more complicated because there isn't just one box.
IT understands one part of the problem. Operations understands another. Finance sees something else. The person doing the actual work may know things that nobody else knows.
So understanding my own box may still leave a lot of the picture missing.
I also need to understand how it connects to the others. Something happening elsewhere in the organization may explain what I am seeing, or another team may already have part of what I need.
The same applies outside the organization.
Learn from other frames
Different industries and disciplines have developed their own ways of thinking about problems.
Manufacturing thinks a lot about flow and bottlenecks. Software thinks about systems, dependencies and failures. Machine learning works through training, testing, errors, refinement and generalization.
Sometimes what is useful is not the solution itself. It is the way somebody else framed the problem.
That is a big part of what thinking outside the box means to me.
Sometimes you are the outsider.
Know enough to question it
That can be useful because you are coming in without years of assumptions about how something should work. But you still need enough understanding to know what you are questioning.
For me, that means immersing myself in it. Talk to the people involved. Look at the systems. Follow the information. Understand the dependencies and the exceptions.
I don't necessarily need to become an expert in everything.
I need enough understanding to know what matters.
So when someone tells me to think outside the box, I still come back to the same question.
Where is the box?
Find it first.
Then we can decide what to do with it.