🧯 Never the expert: breaking knowledge silos and bottlenecks in technical teams
In software development teams, one of the most dangerous yet overlooked risks is knowledge concentration. When a single person becomes “the only one who understands X,” they don’t just become indispensable - they become a bottleneck and a liability.
To counter this, there’s a powerful cultural and technical practice worth adopting: never the expert.
🧠 What is “never the expert”?
“Never the expert” is a principle that actively promotes knowledge sharing and distribution of responsibilities within a team. The core idea is simple:
No one should remain the sole expert on a critical system area for an extended period of time.
It’s not about rejecting expertise - it’s about refusing to build fragile teams where only one person holds the keys to a domain.
🚍 The Bus Factor connection
The concept of the Bus Factor highlights how many people would need to disappear before a project becomes unmanageable. A Bus Factor of 1 means that if a single team member is unavailable, the entire system is blocked. That’s not just fragile, it's a single point of failure.
By promoting knowledge sharing, pairing, and rotation of responsibilities, “never the expert” directly addresses this issue. It increases the team’s ability to move forward even if someone leaves, becomes ill, or simply goes on vacation.
If your Bus Factor is 1, your project is critically fragile.
A higher Bus Factor indicates a healthy spread of knowledge and responsibility.
A low Bus Factor is not just a theoretical risk, it's a real organizational weak point. “Never the expert” directly tackles this by increasing redundancy and reducing dependency.
🔄 Low Bus Factor as a human bottleneck
A low Bus Factor often manifests as a bottleneck in delivery. Work is delayed because it always depends on the same person — the one who understands a specific module, who reviews the same kind of changes, who fixes the same recurring bugs. If they’re not available, nothing moves. If they are available, they’re overloaded.
This isn’t just inefficient, it’s risky. The team’s ability to ship features and respond to incidents becomes completely dependent on one person’s schedule and cognitive load.
Let’s go one step further. A Bus Factor of 1 also creates a knowledge bottleneck.
Here’s how they’re connected:
A low Bus Factor isn’t just a risk, it’s a bottleneck with a name.
⚠️ The hidden cost of expertise
Relying too heavily on a single person introduces hidden costs. First, there’s delay: when others depend on the availability of one individual, delivery slows down. Then there’s burnout: being the go-to person for everything drains energy and motivation. Finally, there’s the massive risk of absence, if that person leaves, your team faces technical amnesia.
From the perspective of software economics, this is a terrible investment. You’re concentrating knowledge in an illiquid asset; a single human being, which means that when change is needed, you can’t react. This increases operational risk and reduces return on investment.
When teams rely on a single expert, they often encounter:
Slowdowns: Work waits on one person’s availability.
Burnout: The expert is constantly overwhelmed.
Fragile systems: No one dares change parts of the codebase.
Blocked growth: Junior devs stay junior, because context never reaches them.
Risk exposure: One resignation or sick day can paralyze the team.
📅 Knowledge bottlenecks as financial liabilities
In software economics, we can view teams and systems through the lens of risk and asset management. A person who becomes the single point of knowledge is like technical debt embodied in a human. The “interest” on that debt is paid in slow decision-making, rework, firefighting, and team-wide inertia.
Every sprint that passes with knowledge locked in one person carries a cost, not always visible in the short term, but absolutely devastating over time. From cost of delay to blocked onboarding, it quietly eats away at your ability to deliver.
📈 “Never the expert” as risk mitigation
Treating shared knowledge as a risk mitigation strategy changes the conversation. Just as we invest in automated testing to reduce the risk of regressions, or observability to reduce the risk of undetected failures, we invest in spreading knowledge to reduce the risk of individual dependency.
Applying this means building habits: rotating ownership of systems, doing more pair and mob programming, encouraging cross-review, and documenting together. These practices create cognitive redundancy, multiple people being able to step into a role when needed.
🌐 Software economics: a matter of liquidity and value
Luis Artola’s principles in software economics make it clear: liquidity, flexibility, and resilience are central to delivering value. A team where any engineer can contribute to any relevant part of the system has high liquidity. It’s like having a diversified portfolio, you reduce the impact of local disruptions.
The cost of delay drops when teams aren’t blocked waiting on one person. The return on investment increases because delivery speed improves. And overall risk, technical, operational, and organizational, goes down.
When we fail to build shared knowledge, we’re not just being inefficient — we’re gambling. As Artola says, “If you don’t invest in reducing risk, you’re betting everything on stability — which is just another form of gambling.”
💪 Culture is infrastructure
All of this relies on a conscious cultural choice. You must reject the myth of the hero programmer. You must create space for learning, mentoring, rotation, and time to transfer context. Shared code ownership isn’t just a nice-to-have, it’s a design decision that supports resilience and scalability.
Prioritizing collective learning over individual heroism.
Valuing collaboration over control.
Seeing knowledge sharing as a leadership trait, not a threat.
🛠️ How to apply “Never the expert”
Here are concrete practices to embed this principle in your workflow:
👤 Shadow
Shadowing is about intentional observation. The person with the context leads (navigates), while the learner drives. Over time, this shifts to more active participation.
🔁 Rotate responsibilities
Intentionally rotate team members across different parts of the system. Don’t let someone “own” the same area forever.
👥 Pair programming or mob programming
This spreads context through collaboration. Code isn’t the only thing shared, so is the why behind design decisions.
👁️ Cross-team code reviews
Encourage reviews from people outside the immediate domain. This forces understanding and surfaces knowledge gaps.
🪶 Lightweight, collaborative documentation (if need it)
Focus on key decisions, entry points, and system architecture. Docs should live with the code and be easy to update.
🗺️ Knowledge mapping
Make it explicit who knows what. Identify critical areas with only one person listed and plan how to spread that knowledge.
🛠️ Real-life examples
🧱 Example A: Legacy system recovery
A team inherits a legacy monolith. One developer understands its architecture. Over three months, they pair on small tickets with teammates. Knowledge spreads, onboarding improves, and more people confidently ship features.
💸 Example B: Payment microservice
One dev built and maintained a critical payment service. They start running mob programming sessions and internal walkthroughs. Documentation is updated. Within some time, three other engineers can ship changes without relying on that person.
✅ Tangible benefits
Increased resilience to team changes
Faster delivery through reduced bottlenecks
Better decisions through more diverse perspectives
More confident developers, able to work across the system
Reduced burnout for experienced engineers
🔼 Final thoughts
“Never the expert” is not a slogan, it’s a pragmatic approach to building teams that are resilient, flexible, and able to deliver continuously. It breaks silos, increases the Bus Factor, and turns bottlenecks into bridges.
“Never the expert” isn’t about eliminating specialists, it’s about eliminating dependency on specialists. It’s how you scale teams, reduce risk, and make software development sustainable.
In healthy teams, knowledge is shared.
In fragile teams, knowledge is hoarded - and that’s a risk you can’t afford.
🙏 Thanks
Thanks to my college and friend Ángel Siendones for introduccing the concept to me, and also to my friends Ricardo Guzmán and Iván Moreno.
References
Williams, Laurie, Kessler, Robert. Pair Programming Illuminated
Beck, Kent. Extreme Programming Explained: Embrace Change
Bolboacă, Adrian. Practical Remote Pair Programming
Hunt, Andrew, Thomas, David. The Pragmatic Programmer: Your Journey to Mastery
Artola, Luis. Software Economics