Thinking in First Principles
I keep seeing individuals and teams approach AI the same way: take an existing process and ask "how can AI make this better?"
Review cycles taking too long? Use AI to speed up reviews. Documentation outdated? Use AI to write and update docs. Coordination problems? Use AI to summarize meetings and track action items.
And this way of thinking isn’t new. It existed long before AI. When something breaks or someone complains, the reflex is familiar: more meetings, more rules, more people. The question isn’t whether the approach makes sense, but how fast we can optimize it.
This isn't wrong, exactly. But it's not first principles thinking either.
To be clear, this isn’t about removing every process. It’s about knowing when to step back and question the fundamentals.
The Question Nobody Asks
First principles thinking starts with a more fundamental question: does this thing need to exist at all?
Not "how do we improve it." Not "how do we automate it." Not "how do we add more process around it." But: why are we doing this in the first place? What problem does it solve? Is that problem still real?
Most processes exist because they solved a problem that existed at the time they were created. The constraints were different. The tools were different. The team was different. The business was different.
When you optimize an existing process, you're implicitly accepting that the process should exist. You're working within its assumptions. You're making a faster horse when you could be asking whether horses are the right solution at all.
The real problem isn't that optimization is ineffective. It's that it can actively prevent better solutions from ever being considered.
The Danger of Local Optimization
When you optimize locally, you often miss the bigger picture.
You speed up the approval workflow with better tooling. But you never ask why there are five layers of approval in the first place.
You automate a weekly status report. But you never ask if anyone actually reads it.
You add more meetings to improve coordination. But you never ask whether that coordination problem is real or just a symptom of something else.
You implement best practices from other companies. But you never ask whether those practices solve problems you actually have.
Local optimization feels productive. You're making measurable improvements. Teams are busy. Metrics move. But you might be perfecting something that shouldn't exist.
The most impactful changes often come from stepping back and questioning the entire framing. Not "how do we do this better" but "should we be doing this at all?"
Why We Default to Optimization?
Emotional cost.
Questioning whether something should exist is uncomfortable. It feels like an attack on the people who built it, the people who run it, the people whose jobs depend on it.
It's much safer to optimize. Optimization is additive. You're making things better, not threatening anyone. You get credit for improvements without the risk of being wrong about something fundamental.
Asking "should this exist?" puts you in a vulnerable position. If you're wrong, you look foolish. If you're right, you might make enemies. So most people don't ask. They optimize instead.
What First Principles Looks Like
First principles thinking isn’t abstract or philosophical. It’s practical and starts one layer deeper than most teams are willing to go.
So how do you actually do it? First principles thinking means starting from the actual problem, not the current solution.
Instead of "how do we speed up code reviews," ask "what are we actually trying to achieve?" Maybe it's catching bugs. Maybe it's knowledge sharing. Maybe it's maintaining code quality standards. Each of those might have a completely different solution.
Instead of "how do we triage bugs faster," ask "why are there so many bugs in the first place?" Maybe it's rushed releases. Maybe it's unclear requirements. Maybe it's insufficient testing. Each points to a different fix.
Instead of "how do we make meetings more efficient," ask "what problem is this meeting solving?" Maybe it's coordination. Maybe it's decision-making. Maybe it's relationship-building. Only one of those actually requires synchronous time in a room.
Litmus Test
Try this thought experiment. If a process disappeared tomorrow:
- What would actually break?
- How quickly would we notice?
- Who would complain first, and why?
The answers reveal a lot. If nothing breaks, the process is probably waste. If it takes weeks to notice, it's not as critical as people think. If the only people who complain are the ones running the process, that tells you something too.
Some Processes Will Survive
Now, here's a counterpoint worth considering: if you're going to innovate, you have to understand the value of what you're replacing.
This isn't about eliminating everything. Some processes exist for good reasons that remain valid. And to know which ones, you need to understand them deeply first. Why they exist, what they actually accomplish, what would break without them.
Human judgment still matters for decisions that involve values, priorities, and tradeoffs. Relationship-building still requires actual human connection.
The point isn't that everything should be eliminated or automated. The point is that everything should be questioned. Some things will survive the questioning and be stronger for it. Others will reveal themselves as artifacts of constraints that no longer apply.
The Uncomfortable Question
Next time you're about to "improve" something, whether with AI, more meetings, new processes, or additional resources, pause and ask:
If I were starting from scratch today, with all the tools and knowledge available now, would I design this at all? Would I design it this way?
If the answer is no, maybe the move isn't to optimize. Maybe it's to rethink the whole thing.
The best opportunities often aren't in making existing things faster. They're in realizing that some existing things don't need to exist anymore.
Optimization compounds efficiency. First principles compound leverage.