Yes—many teams go through this, and the outcome usually depends less on how good the lead was and more on how much of the team’s knowledge, decision-making, and relationships were concentrated in that one person.
From your description, your lead sounds like he’s filling several roles simultaneously:
Technical expert on the entire stack
Product and business domain expert
Team coordinator and decision-maker
Buffer between engineering and management
Informal mentor for other engineers
When one person occupies all of those roles, their departure often exposes dependencies that weren’t obvious while they were there.
I’ve seen a few common outcomes:
1. The team struggles initially, then adapts
This is probably the most common scenario.
After the lead leaves:
Decisions take longer.
People discover knowledge gaps.
Ownership gets redistributed.
Senior engineers step into areas they weren’t previously responsible for.
Productivity often dips for a few months, but eventually the team develops new experts and a new leadership structure emerges.
2. The team loses velocity for a long time
This happens when the lead was the primary holder of critical knowledge.
Typical signs:
Nobody understands certain systems well enough to modify them confidently.
Architectural decisions get deferred.
Management replaces the lead with someone who lacks context.
Remaining engineers spend significant time firefighting.
The team doesn’t collapse, but progress becomes noticeably slower.
3. Multiple departures follow
Sometimes a strong lead is a stabilizing force.
When they leave:
Other engineers start reconsidering their own situations.
Frustrations that were previously managed become more visible.
Confidence in leadership decreases.
The lead’s departure isn’t necessarily the cause; it’s often a symptom of broader organizational issues.
4. The team improves
This sounds counterintuitive, but it does happen.
Sometimes a highly capable lead becomes a bottleneck unintentionally because everyone relies on them. After they leave:
More engineers take ownership.
Knowledge spreads.
Decision-making becomes more distributed.
The transition is painful, but the team ends up more resilient.
What I’d pay attention to now
The key question isn’t “What happens if he leaves?”
It’s “How much of what he knows is documented, shared, and distributed?”
If you’re worried, you can start looking for signals:
Are architectural decisions documented?
Do multiple people understand the critical systems?
Could someone else reasonably lead a major incident?
Are business relationships concentrated in him?
Is there an obvious successor or leadership plan?
If the answer to most of those is “no,” then his departure would likely have a significant impact, at least in the short term.
One thing I’ve noticed repeatedly: teams often underestimate their ability to adapt. The first few months after a strong lead leaves can feel chaotic, but capable senior and mid-level engineers usually step up faster than anyone expects. The biggest risk isn’t losing a great individual—it’s discovering that the organization never built enough redundancy around that person in the first place.