Field Note
A couple of years ago, I volunteered to coach my daughter's 8-year-old soccer team.
I didn't know it at the time, but that season ended up teaching me one of the most useful lessons I've learned about building systems:
Good systems make complicated things simple. Great systems also know what to do when the simple version breaks.
And somehow, I learned that from a team of kids nobody expected to win.
Our team came together at the end of registration.
Most of the kids had never played in the league before. Nobody had volunteered to coach them.
Meanwhile, many of the teams we were playing had been together since the kids were four or five. They had experienced coaches, routines, and players who already understood the game.
We had none of that.
So I volunteered.
I wasn't a soccer coach either.
It really was our own little Bad News Bears situation.
At our first practices, every game turned into the same thing.
The ball moved.
Every kid chased it.
One giant swarm.
Trying to explain positions, passing lanes, formations, or strategy wasn't going to work.
So I stopped trying to teach them the whole game.
Instead, I divided the field into small sections.
Each kid got one.
And I made it feel important.
This is your space. You own it.
Nothing happens here without you knowing about it.
I hyped them up about it, and they took it incredibly seriously.
That little piece of grass became theirs.
Then I gave each kid a few simple rules for their area.
If the ball enters your space, move it this direction.
If the other team comes through, take the ball away.
If your teammate has it, get ready for the pass.
That was basically it.
They didn't need to understand the entire formation.
They needed to understand:
This is mine. This is my responsibility. This is what I do when something happens here.
And they would not leave their spaces.
You could watch other teams chasing the ball in packs while our kids stood there guarding their little section of the field like it was private property.
From the sidelines, we looked incredibly organized.
We weren't.
We were a bunch of first-time soccer players protecting ten little pieces of grass.
But together, those pieces became a system.
Something started happening.
The kids naturally spread across the field.
The ball moved from one section to another.
Someone was usually where they needed to be.
Defense happened without me screaming instructions.
No individual kid understood the entire system.
They didn't need to.
Each person understood their part.
And because everyone understood their part, the whole thing worked.
We eventually made it all the way to the league championship.
We lost.
And that might be the most important part of the story.
The other coach was more experienced.
He had systems too.
But his systems had been tested longer.
He had adjustments.
Contingencies.
Redundancies.
When something stopped working, he already had another answer.
We had built a really good version one.
He had version ten.
I've thought about that season a lot since then.
Especially when building systems in ecommerce, operations, product data, compliance, and AI.
There is always a temptation to design the perfect system from the beginning.
Every edge case.
Every exception.
Every fallback.
Every possible scenario.
But that's usually how you end up with something nobody understands well enough to use.
The better approach is often:
Start simple.
Make ownership clear.
Give people a few rules they can actually remember.
Run the system.
See where reality breaks it.
Then add the redundancy.
That's how systems become sophisticated without becoming impossible to operate.
Organizations often try to create coordination with more meetings, more documentation, more approvals, and more instructions.
Sometimes the better answer is much simpler.
Give someone a clearly defined piece of the field.
Make it theirs.
Give them the authority and rules they need to operate inside it.
Then make sure the pieces connect.
Not everyone needs to understand the entire machine.
They need to understand what they own, what they're responsible for, and what to do when the ball enters their space.
Then, once the system starts getting tested by the real world, you build the next layer.
The exceptions.
The fallbacks.
The redundancy.
The sophistication comes later.
Clarity comes first.