Shoshin: The Power of Beginner's Mind in Technical Leadership
Shoshin: The Power of Beginner’s Mind in Technical Leadership
The Expert’s Curse
You’ve spent years mastering distributed systems. You can debug race conditions in your sleep. Your architecture decisions have saved companies millions. You’re the expert everyone comes to for answers.
And that expertise might be your biggest obstacle.
When a junior engineer proposes using a new database you’ve never heard of, your first instinct is dismissal: “We’ve always used PostgreSQL. It’s battle-tested. Why complicate things?”
When a team suggests rewriting a component in a language you don’t know well, you resist: “Our team knows Python. Introducing Go adds training overhead.”
Expertise breeds certainty. Certainty breeds rigidity. Rigidity breeds obsolescence.
What Is Shoshin?
Shoshin (初心) - Japanese for “beginner’s mind” - is a concept from Zen Buddhism describing an attitude of openness, eagerness, and lack of preconceptions when approaching a subject, even at an advanced level.
Zen teacher Shunryu Suzuki wrote: “In the beginner’s mind there are many possibilities, but in the expert’s mind there are few.”
Beginner’s mind isn’t about pretending you don’t know things. It’s about approaching familiar situations with fresh eyes, questioning assumptions, and remaining curious despite (or because of) your expertise.
The Expert Trap in Engineering
Pattern matching gone wrong: After solving dozens of scaling problems, you recognize patterns instantly. But sometimes the pattern you see isn’t actually there, and you apply yesterday’s solution to today’s different problem.
Confirmation bias: You unconsciously seek evidence supporting what you already believe while discounting contradictory information. Your PostgreSQL bias makes you notice Postgres success stories and ignore cases where specialized databases excel.
Status quo bias: The current system works. Change introduces risk. Better to optimize what exists than embrace unproven approaches. Except when the status quo slowly becomes a competitive disadvantage.
Curse of knowledge: You can’t remember what it’s like to not know what you know. This makes you impatient with “obvious” questions, dismissive of alternative perspectives, and blind to complexity you’ve internalized.
The Paradox: Expertise Enabling Beginner’s Mind
The deepest expertise enables the purest beginner’s mind. Here’s why:
True experts know the boundaries of their knowledge. The Dunning-Kruger effect shows beginners overestimate their competence, while experts recognize how much they don’t know.
Mastery creates cognitive space. When fundamentals are automatic, you can question them. A senior engineer who internalizes clean architecture principles can thoughtfully decide when to violate them.
Experience with change cultivates humility. You’ve seen “best practices” become anti-patterns (remember XML configuration files?). You know today’s cutting edge is tomorrow’s legacy.
Practicing Shoshin in Technical Leadership
1. Question Your Assumptions Explicitly
Before dismissing an idea, articulate your assumptions:
Instead of: “We can’t use microservices, they’re too complex for our team size.”
Try: “My assumption is microservices add overhead that small teams can’t afford. What if we challenged that? What’s the minimum viable microservices architecture? What complexity are we actually avoiding vs. what complexity would we trade it for?”
Practice: Keep an “assumptions register” for major decisions. Revisit quarterly to see which assumptions proved wrong.
2. Create Space for Not Knowing
Admit ignorance publicly: “I haven’t used Rust in production. Tell me more about why you think it fits here.”
This isn’t weakness - it’s modeling learning culture. Teams where leaders admit not knowing create environments where everyone can learn without shame.
Ask naive questions: “Why do we deploy on Tuesdays?” “Why does this service exist separately from that service?” Often the answer is “historical reasons that no longer apply.”
Beginner interviews: When evaluating new tech, ask someone learning it to teach you. Their fresh perspective highlights rough edges experts have learned to work around.
3. Seek Disconfirming Evidence
Steel-man opposing views: Before rejecting an approach, make the strongest possible case FOR it. “If I were arguing for NoSQL here, I’d say our query patterns are key-value lookups with rare joins, and we value write throughput…”
Pre-mortem practice: Before launching, assume the project failed spectacularly. Work backward to identify what went wrong. This surfaces assumptions you’re not questioning.
Diverse input: Deliberately seek opinions from people with different backgrounds. The backend engineer might see frontend architecture patterns you’ve missed. The junior hire brings perspective from bootcamp teaching modern practices you learned before they existed.
4. Embrace “I Don’t Know” As Starting Point
In Zen practice, beginners hold questions lightly, exploring possibilities. Experts often jump immediately to answers.
Scenario: “How should we handle authentication?”
Expert mind: “OAuth 2.0 with JWT tokens. Done.”
Beginner mind: “What are we actually trying to achieve? Who are the users? What’s the threat model? What are all the approaches - OAuth, SAML, magic links, WebAuthn? What are the trade-offs? Why did we pick OAuth last time? Is this time different?”
The beginner’s mind answer might still be OAuth - but it’s chosen consciously, not automatically.
5. Learn Something Completely New Regularly
New language: If you’re a Go expert, learn Elixir. The actor model and functional paradigms challenge OOP assumptions.
New domain: Build something in a field you don’t know - game development, embedded systems, data engineering. Feeling incompetent recalibrates your empathy for learners.
New role: Shadow a designer, PM, or sales engineer. Understanding adjacent disciplines reveals blind spots in your technical thinking.
Result: Regular exposure to being a beginner prevents expert rigidity.
Shoshin in Team Dynamics
Code reviews: Instead of “This is wrong, do it this way,” try “I usually do X because of Y. What’s your reasoning for Z?” You might learn a better approach.
Architecture discussions: Make it safe to propose “dumb ideas.” Some breakthrough innovations sounded dumb initially (containers, serverless, NoSQL).
Incident response: Don’t jump to conclusions based on past incidents. Fresh eyes might notice the subtle difference that makes the fix different this time.
Mentoring: Don’t just download knowledge. Ask: “What would you try?” Let them explore dead ends (within safe bounds). Learning happens through discovery, not instruction.
The Cost of Beginner’s Mind
It’s slower: Questioning assumptions takes time. Sometimes you need to move fast and use your expert judgment.
It’s uncomfortable: Admitting “I don’t know” feels vulnerable, especially as a senior leader.
It can look indecisive: In cultures that value strong opinions strongly held, beginner’s mind can seem wishy-washy.
It requires security: You need psychological safety to say “I might be wrong.” Toxic cultures punish this.
When to Apply Expert Mind vs. Beginner Mind
Expert mind for:
- Emergencies (production down, security incident)
- Well-defined problems matching previous experience exactly
- Mentoring on fundamentals (teaching a junior how databases work)
Beginner mind for:
- Strategic decisions with long time horizons
- Unfamiliar problem spaces
- When your initial gut reaction is very strong (might be bias, not wisdom)
- Evaluating new technologies or approaches
- Any time you notice yourself thinking “we’ve always done it this way”
The balance: Use expert knowledge to quickly generate hypotheses, then use beginner’s mind to question them.
Reflection Questions
- What technical opinion do I hold most strongly? What would change my mind?
- When was the last time I said “I don’t know” in a technical discussion?
- What assumption about my codebase/team/tech stack have I not questioned recently?
- If a beginner looked at our architecture, what would confuse them? Is that confusion pointing to actual complexity we could eliminate?
- What technology have I dismissed without actually trying? What was my reasoning? Was it sound?
Conclusion
The path from beginner to expert is well-traveled. The path from expert back to beginner - while retaining expertise - is rarer and more valuable.
Shoshin isn’t anti-expertise. It’s expertise wielded with humility. It’s knowing enough to recognize how much you don’t know. It’s having strong opinions, loosely held. It’s being certain about fundamentals while remaining curious about applications.
In a field where paradigms shift every decade and last year’s best practice is this year’s anti-pattern, beginner’s mind isn’t optional - it’s survival.
As Suzuki wrote: “The goal of practice is always to keep our beginner’s mind.”
For principal engineers, that practice never ends. And that’s exactly as it should be.