Quick Summary
- There was a phase when my co-founder and I couldn't walk across our own office without collecting problems, most of which people could have solved themselves.
- It took us some time to see that we were the cause. People route problems to the nearest competent answer, and we were standing right there.
- The model: every problem is a monkey, and when a founder says "let me think about it," the monkey jumps onto the founder's back. Your availability is a routing instruction.
There was a phase when my co-founder Harshit and I couldn't walk across our own office without collecting a few problems on the way.
A question at one desk. A quick word at the next.
Someone catching us by the door with something that, honestly, they could have resolved themselves in a couple of minutes.
Most of it was not urgent. Most of it wasn't even hard.
For a while, we thought this was what accessible founders looked like.
And I'd admit that it took us a few weeks to see that we were the cause.
Who's got the monkey?
In 1974, William Oncken and Donald Wass published a Harvard Business Review article with one of the best titles in management writing: "Management Time: Who's Got the Monkey?"
Their idea is simple. Every problem is a monkey.
When someone stops you in the corridor and says "we've got a problem," and you reply "let me think about it," the monkey has just jumped from their back onto yours.
Do that enough times and you end up working for your own team, carrying a back full of monkeys while everyone waits for you to get to them.
That was us. And it wasn't because anyone was lazy or trying to offload work. It was because we were standing there.
Your availability is a routing instruction. If you are the nearest answer, every question will find its way to you.
People route problems to the nearest competent answer. That's rational; it's exactly what I'd do.
If the founders are visible, approachable and apparently happy to help, the founders are the nearest answer to almost everything.
So everything comes to the founders, including the things that would have been far better off staying where they started.
The other kind of visit
Some of what arrived wasn't a question at all.
A share of it was about colleagues. Concerns about how someone else was working. Frustration with a peer.
Occasionally, doubts about whether someone belonged in their role at all.
At first we treated these as issues to resolve. Over time we noticed that most of them weren't really asking us to decide anything.
They were things the person needed to work through: friction, uncertainty, the ordinary discomfort of working closely with other people.
Our presence let that discomfort be handed over rather than worked out.
And handed over, it never quite got resolved. It came back the following week in a slightly different shape.
That's not a criticism of anyone. Every one of us does this when someone senior is close by to absorb it.
It's simply what happens when the easiest way to make a difficult feeling go away is to give it to the boss.
Stepping out of the line of sight
So we made a deliberate decision. On a typical day, Harshit and I would keep our distance.
Not hide. Not become unreachable.
Just stop being the most visible, most convenient answer in the room, because our being in someone's line of sight was itself a signal: here's someone you can walk up to.
But I understood something quickly. Distance on its own isn't leadership. It's abandonment.
If you remove yourself and put nothing in your place, people aren't growing; they're just stuck, and they'll find you anyway.
So before the distance could work, we needed something that could answer instead of us.
Building the thing that answers
That meant writing down how the work actually works. So based on inputs from the team, I wrote workflows for every one of our eight divisions.
It took me a few weeks to get them right, and most of that time went not into writing but into finding the places where we had always relied on someone simply knowing.
Creating master workflow decks and job cards took time but I knew that getting people to properly follow the workflows required some out-of-the-box thinking.
So, rather than asking people to read huge documents (which is cumbersome), I came up with a unique solution.
Every single one of our team mem in our team uses AI tools like Claude or ChatGPT in their daily work. So I decided to train their own AI tools on the workflows.
I organised a workshop for the whole team, and during it I helped them set up their own project with an AI assistant and the full set of workflows as the foundational project knowledge.
So rather than anyone sifting through documents, they can simply ask their AI tool how something is done and get an answer drawn from the agreed way of doing it.
And it's set up to say plainly when the workflows don't cover something, rather than invent an answer that sounds official.
And we gave everyone a short escalation ladder.
| Step | Where it goes | Why this order |
|---|---|---|
| First | Ask your AI assistant, which knows the workflows | Most questions already have an answer, and this is the fastest way to it |
| If still unresolved | A clearly worded written message to me | Writing a question down often answers it, and the rest arrive properly framed |
| Only if required | A conversation | Kept for what genuinely needs one, so it gets proper attention |
The second step does more work than it looks. A remarkable number of questions dissolve somewhere between being thought and being written down clearly.
And the ones that survive arrive as real questions, with context, rather than as something said in passing by the door.
Disagreements between people have their own route too. They go to the relevant division leads, not up to the founders and not to a piece of software.
Nobody, human or otherwise, settles a dispute in the corridor.
What happened next
Mostly, people figured things out.
Not instantly, and not without some friction. But problems that used to travel up to us started getting solved where they began.
People who'd been bringing us small questions started bringing us better ones, or none at all.
And the work improved, because the people closest to it were now the ones making decisions about it.
I've come to think that was the real point. People grow by meeting problems that are theirs and solving them.
Every time we intercepted one, however kindly, we took away a small piece of someone's growth. We weren't helping.
We were standing in the way of a trajectory that would have unfolded naturally if we'd only stepped aside.
The question before you answer
If you're a founder or a manager and this sounds familiar, the most useful habit I know is a single question, asked before you take anything on:
Whose monkey is this?
If it's genuinely yours, a decision only you can make, take it and deal with it properly.
If it isn't, the kindest thing you can do is make sure it leaves the conversation on the back it arrived on.
Point to where the answer lives. Ask what they would do. Then let them do it.
Why it compounds
Here's the part that matters for the long game.
A question a founder answers in the corridor is answered once.
Tomorrow someone else asks it, and the founder answers it again. Nothing accumulates except the founder's fatigue.
A question the system answers makes the system better.
Every gap someone runs into gets written into the workflows. Every person who solves something on their own is a little more capable the next time.
Those are two very different curves, and they separate quickly: one keeps the founders at the centre of everything indefinitely, while the other builds a company that needs them a little less every month.
Which is exactly what you want.
A company that needs its founders in every corridor isn't strong. It's just well supervised. Or worse, micromanaged.
