The funny thing about building systems is that you usually don’t notice when you’ve stopped working on the original problem.
You set out to do the work.
Then you realize you could make the work more effective.
Then you realize you could build something that makes the work more effective.
Then you realize you could build something that builds the thing that makes the work more effective.
Somewhere along the way, you look up and realize you’ve wandered into an entirely different profession.
I’ve started thinking about this in three levels.
Level 1: Do the work.
This is the obvious one.
Write the email.
Make the sale.
Build the website.
Answer the customer.
Ship the product.
Most people live here, and there’s nothing wrong with that. Reality eventually keeps you honest because the work either gets done or it doesn’t.
Level 2: Build the thing that does the work.
This is where it gets interesting.
Instead of writing the same email a hundred times, you build the template.
Instead of solving the same problem every week, you build the playbook.
Instead of remembering everything yourself, you build the system that remembers.
This is engineering.
Governance.
Architecture.
Doctrine.
Automation.
The work shifts from doing to building the machine that does.
Done well, this is where leverage comes from.
Done poorly, it’s where you disappear into architecture for architecture’s sake.
Because architecture has a dangerous property.
It always feels productive.
You can spend weeks designing the perfect system without moving the original mission forward an inch.
That’s when architecture starts to outrun evidence and execution.
I’ve learned you have to intentionally build guardrails around yourself.
Not because building systems is bad.
Because it’s incredibly easy to get lost in the building.
Level 3: Build for transfer.
This one surprised me.
At some point I stopped asking:
“How do I solve this problem?”
Then I stopped asking:
“How do I build a system that solves this problem?”
Instead I started asking:
“What is the underlying pattern here, and could this solve ten completely different problems I haven’t even thought of yet?”
Now you’re architecting simultaneously in two directions.
One eye stays fixed on the immediate use case.
The other is scanning for something industry-agnostic.
Something reusable.
Something fundamental.
That’s a completely different mode of thinking.
It’s cognitively expensive.
Honestly, it’s exhausting.
It reminds me of graduate school, except there are no semesters and nobody hands you a syllabus.
For the last six months I’ve been living in that mode almost continuously.
You get used to it.
But it absolutely changes the way you see the world.
Costco and the Human API
The other day I was at Costco.
They’ve changed the self-checkout process.
An employee scans your cart while you’re waiting in line so that when you reach the kiosk, all you have to do is pay.
I was multitasking on my phone.
The machine politely instructed me to scan my items.
So I did.
Again.
By the time I looked up, my total was almost double what it should have been.
The system had done exactly what it was designed to do.
So had I.
Unfortunately, we were operating from different assumptions.
A wonderful Costco employee came over and fixed everything in about thirty seconds.
Standing there, watching her resolve a problem the software couldn’t, I started laughing.
She wasn’t just helping customers.
She was the Human API.
The automation looked autonomous.
It wasn’t.
It still depended on a person quietly stitching together all the edge cases the software couldn’t handle.
Once you start building systems, you begin seeing Human APIs everywhere.
The Oscillation
The rhythm I’ve settled into looks something like this:
Do the work.
Notice the pattern.
Build the tool.
Return to the work.
Notice a deeper pattern.
Build a better tool.
Return again.
It’s a constant oscillation between classroom and real world.
Theory.
Practice.
Engineering.
Reality.
The danger is forgetting to return.
Because every system eventually has to earn its existence by making reality better.
Not by becoming more elaborate.
Build Scaffolding, Not Ego
The entire reason I started down this road wasn’t because I wanted more software.
It was because I wanted fewer blind spots.
Every one of us has places where we’re extraordinary.
Every one of us has places where we consistently fail.
The goal isn’t to eliminate your weaknesses.
The goal is to build scaffolding around them so you can spend more time operating from your strengths.
My blind spots aren’t your blind spots.
Your strengths aren’t mine.
The principle is universal anyway.
Be intellectually honest enough to identify your kryptonite.
Then build systems that quietly compensate for it.
Not because technology is the answer.
Because self-awareness is.
The technology just gives self-awareness somewhere to live.
That’s the difference.
And that’s also why it’s so easy to get lost in the building.
The building was never the mission.
The mission was becoming more effective at living.
Continue reading: The Human API