Yesterday, I received a last-minute task.
I had prepared as much as I could, but the final confirmation came extremely late. There was uncertainty, multiple moving parts and very little time.
This morning wasn’t any easier.
I had kept a branch open to complete one pending task. I had to finish an e-learning requirement for one of my seniors. And then there was this last-minute assignment with several building blocks that had to come together quickly.
My first instinct was familiar.
Run.
Go from place to place. Collect things. Arrange the car. Pick up what was required. Coordinate everything personally.
I felt tired merely thinking about it.
Then I stopped.
What if I looked at this as an orchestration problem?
I called one of the team member and asked him to arrange the bouquets.
I asked another person to arrange a car. A car wasn’t available.
Normally, this would have meant another problem for me to solve personally. Instead, I called our vendor and asked whether he could collect everything. He was away on vacation.
So I called another vendor.
This vendor had been requesting business from us for quite some time, but because we already had a regular vendor, I had never really given him an opportunity.
Today he got one.
And his response taught me something.
He was so enthusiastic that even before receiving the precise location, he had already asked his person to start moving towards the destination.
Soon, he wasn’t merely following my instructions.
He was connecting the building blocks himself.
My role changed completely.
Instead of running around physically, I remained on the phone. When security wouldn’t allow his person inside, I made the necessary call and removed the obstacle. When coordination was required, I coordinated. When something needed clarification, I clarified it.
I wasn’t doing everything.
But I still owned everything.
Owning More While Personally Executing Less
This is the distinction I am beginning to understand.
There are two ways to approach responsibility.
The first is:
I am responsible, therefore I must do it.
The second is:
I am responsible, therefore I must make sure it gets done.
Those are completely different philosophies.
The first makes my personal capacity the limit of the system. If five things need to happen simultaneously, I cannot personally be in five places.
The second forces me to think differently.
What exactly are the building blocks?
Who can produce each one fastest?
Who has the motivation to solve the problem?
What is stopping them?
Where does my authority, communication or intervention actually add value?
My work then becomes surprisingly simple:
Decompose. Deploy. Unblock. Verify.
That doesn’t mean refusing to execute anything myself. Sometimes personal execution will still be the fastest way to secure the outcome.
But personal execution should no longer be the default.
I should personally execute when my execution is the best way to produce the outcome, not merely because the outcome belongs to me.
Today I even received an offer of additional support from the branch. I purposefully declined it because another person wasn’t necessary. Orchestration doesn’t mean involving as many people as possible.
It means creating the minimum sufficient coordination required to produce the outcome.
That is the lesson I am carrying forward.
I own the outcome, not every piece of work required to produce it.
My capacity, therefore, is no longer limited by how much work I can personally perform.
It is increasingly determined by something much more powerful:
How much coordinated activity can I cause to happen?