Core Leadership Principle #1
The Problem
You're in a technical meeting. Someone asks why you chose MongoDB over PostgreSQL for the new feature. You freeze. The truth? You picked it because a tutorial you followed used it. Or because it seemed "more modern." Or because you didn't want to deal with schema migrations.
But you can't say that. So you mumble something about "scalability" and "flexibility" and hope no one asks follow-up questions.
We've all been there. And it's killing our ability to build great software.
What is Intellectual Honesty?
Intellectual honesty means you always have a defensible theory for why you're building something a certain way. Not a guess. Not a vibe. A theory you can defend with data, reasoning, or experience.
It means three things:
- You know why you made a decision - not just what you decided
- You're willing to change your mind - when evidence shows you're wrong
- You admit what you don't know - instead of pretending
The gap between "I don't know" and "I don't know and didn't try to find out" is the difference between an honest engineer and a dangerous one.
Why This Matters
Bad Decisions Compound
That MongoDB choice? It seemed small at the time. But six months later, you're fighting with transactions, your team is debugging race conditions, and migration to PostgreSQL would take weeks. All because you picked a tool without understanding the tradeoffs.
One intellectually dishonest decision leads to another. You can't admit the database choice was wrong (because you never had a real reason for it), so you build workarounds. Then you build workarounds for the workarounds. Technical debt piles up.
Teams Can't Learn
When you pretend to have reasons you don't have, your team can't learn from your decisions. They can't evaluate the tradeoffs. They can't apply the reasoning to future problems.
Worse, you create a culture where everyone pretends. Junior developers copy your behavior. Soon, nobody knows why anything works the way it does. You're cargo culting your own codebase.
You Stop Growing
If you never admit you don't know something, you never learn it. If you never acknowledge mistakes, you never improve. Intellectual honesty is the foundation of growth.
What This Looks Like in Practice
The Good: Defendable Decisions
"I'm building this with Redis instead of our current in-memory cache because we're having latency problems under load. I've tested both approaches with 10k concurrent requests and Redis reduced our p95 latency from 800ms to 120ms. Here's my benchmark data. I want to validate this works in our actual environment before we commit."
Notice what's here:
- Clear problem statement (latency under load)
- Specific comparison (tested both)
- Actual data (10k requests, p95 from 800ms to 120ms)
- Next step (validate in real environment)
- Humility (want to confirm before committing)
This engineer did the work. They have a theory. They tested it. They're ready to be wrong.
"I initially thought GraphQL was the right choice, but after prototyping, the complexity doesn't justify the benefits for our use case. Here's why I'm switching to REST endpoints."
This is intellectual honesty in action: changing your mind when reality doesn't match your theory. No ego. No doubling down. Just adaptation.
The Bad: Intellectual Dishonesty
"I just think this way is better."
Better how? For what? Compared to what? This is a non-answer masquerading as a decision.
"That's how we've always done it."
This is worse than "I don't know" because it pretends to be a reason. Tradition isn't reasoning. It's the absence of reasoning.
"The AI told me to do it this way."
Outsourcing your thinking to AI is outsourcing your judgment. If you can't explain why the AI's suggestion solves your problem better than alternatives, you don't understand what you're building.
How to Practice Intellectual Honesty
1. Write RFCs (Request for Comments)
Before building anything significant, write 1-2 pages explaining:
- What problem you're solving
- What alternatives you considered
- Why you chose this approach
- What the tradeoffs are
This forces you to think. You can't hide behind jargon in writing. If your reasoning is weak, it'll be obvious.
2. Build POCs (Proof of Concepts)
Don't just theorize. Test your assumptions. Build a small version. Measure real results.
"I think X will be faster" → Build both X and Y, benchmark them, show data.
3. Show Your Work
When you make a decision, document it. Not for bureaucracy. For clarity. Future you will forget why you chose this path. Your teammate needs to understand the reasoning to maintain it.
This means:
- PRDs that explain the problem and why it matters
- Test plans that show what you're validating and why
- Benchmarks with real numbers, not hunches
- Implementation plans that break work into reviewable pieces
4. Practice Saying "I Don't Know"
Make it a habit. When you don't know something, say it out loud. Then immediately follow with: "Let me find out."
This does two things:
- It keeps you honest
- It models good behavior for your team
The best engineers I know say "I don't know" constantly. The worst engineers never do.
5. Embrace Being Wrong
When evidence contradicts your theory, update your theory. Don't defend it. Don't rationalize. Don't save face.
Say: "I was wrong about X. Here's what I learned. Here's what I'm doing differently."
This is a superpower. Teams that can admit mistakes fix them fast. Teams that can't admit mistakes hide them until they explode.
The Test
Before your next technical decision, ask yourself:
"If someone asks me why I chose this approach, can I give them a clear, data-backed answer? Or will I bullshit?"
If the answer is bullshit, you're not ready to build yet. Go do the work. Test your assumptions. Build the POC. Get the data.
Then decide.
Strong Opinions, Loosely Held
This phrase gets thrown around a lot, but here's what it actually means:
Strong opinions: You have a clear point of view based on reasoning and evidence. You're not wishy-washy. You can articulate why you think X is better than Y.
Loosely held: You're ready to change your mind when new evidence emerges. You're not attached to being right. You're attached to finding the truth.
The combination is powerful: You move fast with conviction, but you adapt quickly when you're wrong.
The opposite is deadly: Weak opinions, strongly held. You don't really know why you believe something, but you'll fight to defend it anyway.
The Culture Shift
When you practice intellectual honesty, you change the culture around you.
Junior developers learn they can say "I don't know" without being judged. They learn to show their work. They learn to change their minds.
Senior developers stop pretending to know everything. They start testing their assumptions. They start asking "why" instead of just "what."
Code reviews become about ideas, not egos. The best argument wins, not the loudest voice or the highest rank.
This is how you build a team that ships great software. Not by pretending to have all the answers. By doing the work to find them.
Start Today
Pick one decision you're about to make. Before you make it:
- Write down why you're considering this approach
- List at least two alternatives
- Explain the tradeoffs
- Test your top choice if possible
- Be ready to change your mind
That's it. That's intellectual honesty.
Do this consistently, and you'll build better software, grow faster, and earn the respect of everyone around you.
Not because you're always right. Because you're always honest.
This is part of a series on Core Leadership Principles for engineering teams. Next up: Ownership & Accountability - You own your code from concept to production.
Follow me on Twitter
If you like and want to support my work check my patreon
See more in https://linktr.ee/daniloab.
Photo by Brett Jordan on Unsplash
Top comments (1)
That's a great text. It's important to have this concern at higher levels.