When Your 10x Developer Becomes a 10x Liability

The term "10x developer" is not a myth.  Research consistently shows that top-tier engineers can be an order of magnitude more productive than the average.  When this works, they are extraordinary assets.  They solve the "unsolvable," accelerate entire teams and see shortcuts through technical debt that others miss.

However, a subtle transformation can turn these force multipliers into gravitational centres that everything orbits around.

This article is about recognising that moment when a 10x asset becomes a 10x liability.

The 10x Asset (The Multiplier)	The 10x Liability (The Sovereign)
Simplifies complexity so others can work with it	Embraces complexity as proof of expertise
Builds systems that empower the team	Bypasses process to ensure they move fast
Sees documentation as part of "done"	Sees documentation as a distraction
Mentors others to make themselves replaceable	Reminds leadership they are "indispensable"

Understanding Technical Sovereignty

Throughout this article, I refer to the 10x liability as 'The Sovereign' - a developer who has moved from force multiplier to ruler of their technical domain.

The term is deliberate. Sovereigns operate by their own rules rather than organisational standards. They have established independence from normal constraints: standard tooling, documentation requirements, code review scrutiny and knowledge-sharing expectations.

Like political sovereignty, technical sovereignty is about autonomous control. The Sovereign decides what gets built, how it gets built, who can touch it and when others are "allowed" to contribute. They have transformed technical expertise into territorial authority.

A 10x asset makes the organisation faster. A Sovereign makes the organisation dependent.

The Quick Diagnostic

To determine if a high-performer has become an organisational liability, move past technical opinions and observe the functional impact of their work.  If the team’s velocity is tied to one person’s pulse, you do not have a star; you have a single point of failure.

Use the following checks to categorise the developer's impact on the organisation:

The Check	The 10x Asset (The Multiplier)	The 10x Liability (The Sovereign)
Code Review	Peers regularly suggest improvements or catch edge cases in their PRs	Peers rubber-stamp their PRs - challenging the approach feels futile or risky
Absence Impact	Projects continue; the team feels slightly slower but stays on track.	Projects stall; the team enters a "holding pattern" until the developer returns.
Onboarding	New hires ship their first meaningful feature by the end of week 2.	New hires are still "shadowing" and asking for permission in month 3.
Tooling	Standard security/AI tools integrate seamlessly with the codebase.	The Sovereign claims standard tools "don't work with our unique complexity."
Verification	Any developer can verify a fix works using automated tests.	The Sovereign is the only person who can "verify" if a solution is correct.

The Four Patterns of Sovereignty

Leadership must recognise the behavioural patterns that signal a shift toward Sovereignty.

The Control Paradox ("I need control to perform")

They move fast today by leaving a "clean-up bill" for the team tomorrow.  If a fix requires three follow-up meetings to explain, the time has not been saved, it has just been moved from the "coding" bucket to the "meeting" bucket.

The Quality Guardian Turned Gatekeeper

They use "quality" as a moat.  By making code so idiosyncratic that no one else can touch it safely, they ensure they are the only person who can ship.

The Technical Lens Blindspot (The "Ceiling" Effect)

They treat all technical problems as equally important, often perfecting technology implementations while being unaware of solving more critical business outcomes.  They lack the "Commercial Filter" to distinguish between technical excellence and business ROI.

The Flight-Risk Posture ("I can work anywhere")

A power play used to shut down accountability.  They create a system that requires them - a form of job security that "standard" companies do not offer.

What Technical Sovereignty Looks Like in Practice

The following three scenarios are examples to describe the 10x liability impact.

The Security Conversation and Compliance Risk

The Setup: Your CISO needs to implement automated security scanning as part of SOC 2 compliance. Every development team adopts the tools within a sprint. Except one.

The Pattern:

Week 1: "The scanners generate too many false positives.  I'll add it to the backlog after we ship the current features."

Week 4: "These tools don't understand our architecture.  They flag perfectly safe code. It'll take weeks to configure them properly."

Week 8: "I've been manually reviewing for security issues.  That's actually more thorough than automated tools.  We should document that as our approved alternative process."

What Everyone Knows (But Nobody Says):

• Other teams configured the same scanners in days, not weeks.

• "Too many false positives" means "I don't want oversight".

• Manual review without audit trail isn't a control – it is an exception that creates compliance risk.

The Business Impact:

• Your SOC 2 audit report has an exception for one team.

• Auditors question whether you have consistent security controls.

• Material weakness in ICFR because one person's judgment is not independently validated.

• If this person leaves suddenly, you have no audit trail for security decisions in their systems

The Failed Team Expansion

The Setup: Your CTO decides to expand the team by three senior developers to accelerate a strategic initiative.  One of those developers will work in the 10x developer's domain.

The Pattern:

Month 1: The new developer spends most of their time in meetings where the 10x developer explains "how things work here."

Month 2: The new developer starts contributing but every PR gets extensive "feedback" about not understanding "the full context."

Month 3: The new developer's velocity is still 20% of the rest of the team.  They confide to the CTO, "I don't think I'm technical enough for this role."

Month 4: The new developer leaves.  Exit interview reveals, "I was a tech lead at my previous company.  Here I felt like a junior constantly asking permission."

What Everyone Knows (But Nobody Says):

• The 10x developer is threatened by competition.

• "Context" is being weaponised to prevent contribution.

• The organisation just lost 3 months of productivity and a good engineer's reputation.

The Business Impact:

• Thousands of dollars on recruitment cost wasted.

• 3 months of loaded (FTE) salary with minimal output.

• Damage to your recruitment brand - good engineers talk.

• Your team expansion plan failed because one person held it hostage.

  
  

When AI Adoption Reveals the Sovereignty Gap

The Setup: The business wants the entire engineering team to adopt AI-augmented development.  This requires standardised code structure, comprehensive testing and clear documentation so AI can assist with implementation across all systems.

The Pattern:

Week 1: The 10x developer is enthusiastic, "I've been using Claude/Cursor for months. It's incredibly powerful for my work."

Week 4: Other developers try to use AI tools on the 10x developer's systems.  They report: "The AI can't generate useful suggestions because there's no documentation. It hallucinates solutions that break core assumptions."

Week 6: The CTO asks, "Can we refactor your systems to work with AI tooling?" Response, "That would require months of work and slow down current delivery.  The systems work fine - I use AI for my own workflow."

Week 8: Leadership realises: The 10x developer is using AI effectively - but only they can, because only they have the contextual knowledge.  AI amplifies their productivity but makes the knowledge gap worse, not better.

What Everyone Knows (But Nobody Says):

• The 10x developer's personal AI-augmented productivity is extraordinary.

• Their systems are structured so only they can leverage AI effectively.

• AI is making them significantly faster while making everyone else even more dependent on them.

• The organisation cannot scale AI adoption because one person's architecture prevents it.

The AI Amplification Paradox:

• Before AI, this developer was significantly more productive than the team.  Knowledge concentration was a problem, but manageable.

• With AI, their personal productivity amplifies substantially.  However, the team still cannot use AI on their systems because there is no documentation, no modular structure, no way for AI to understand the context. The productivity gap widens.

The competitive math changes:

• Before AI, one brilliant developer vs average team members (significant individual advantage).

• With AI, one AI-augmented brilliant developer vs twenty AI-augmented team members working in parallel (overwhelming team advantage).

Competitors with modular, documented systems give AI tools to entire teams.  Every developer's productivity improves.  Your one AI-augmented superstar, no matter how brilliant, cannot compete with their twenty AI-augmented developers.

AI does not solve your sovereignty problem - it exposes it.  The person whose productivity AI amplified most becomes the person preventing your organisation from scaling AI adoption.

The Hidden Risks of Factions and Escalation

A Sovereign builds a "trusted circle" who learn their way and no other.  If you address the Sovereign, you risk an exit cascade.  Identify who is loyal to the company versus the individual before you act.  Watch for a subset of the team that always defers to the Sovereign, uses their terminology exclusively and becomes defensive when asked to work with others outside the circle.

The Escalation Ladder and Identifying Technical Shock and Awe

As 10x developers move at high velocity, their pushback is a wildfire.  When a Sovereign feels their control slipping, they use pace as a weapon.

Rung 1: The Intellectual Smokescreen.  Using jargon to make your requirements feel "dangerous" to the platform.  "Implementing that scanner will break our custom event-sourcing pattern.  We'll need to refactor the entire aggregate root structure."  Translation: "I don't want to comply."

Rung 2: The Public Reply-All.  Sending aggressive "warnings" to stakeholders to induce leadership whiplash.  The Friday afternoon email to the entire leadership team about "architectural risks" you are supposedly creating.  They are manufacturing a crisis to make you back down.

Rung 3: The "Convenient" Crisis.  A "critical database spike" occurs exactly when the knowledge-transfer meeting was scheduled. Systems that have run fine for months suddenly require their immediate attention when you try to reduce dependency.

Rung 4: The Midnight Ultimatum An aggressive email sent the night before a Board meeting or product launch.  "I need to be clear about the risks we're taking with these process changes.  I can't be responsible for what happens to the platform if we proceed."

Recognise this as emotional escalation, not technical analysis.  Pace is their strength.  Process is yours.  Stay "Warm but Bored" (more on this below).  When the 10x Developer exits, the ‘inner circle’ will be looking for a new source of truth.  Ensure your senior ‘shadow’ developers are prepared not just to take over the code, but to step into the social vacuum and offer the loyalists a Path A (partnership outlined below) of their own.

The silence around this pattern is not ignorance.  It is a rational risk calculation by individuals that creates collective paralysis.

The developer's direct manager benefits from their output.  Their VP does not want to disrupt delivery. The CEO does not want to believe their "star performer" is a systemic risk.  Sales fears losing the person who can answer technical questions.  Product needs them to deliver committed roadmap items.

Each person makes a locally rational decision to avoid confrontation.  These individual calculations add up to organisational dysfunction.  Everyone knows.  Nobody says it.

The Heroics Trap and The Illusion of Managed Risk

Leadership often believes they have technical sovereignty "under control." They recognise the dependency but they justify it through a cycle of crisis and rescue. When a product launch is failing or a competitive threat arrives, the 10x developer performs. The heroics work. The crisis is averted. This creates a dangerous illusion, "We're managing the risk. We can call on them when we need them. This is a choice we're making on our terms." What leadership misses:

• Reinforcement, not Control. Each heroic rescue is not evidence of management, it is evidence of deepening dependency.

• The Leverage Compound. Every crisis that requires a "sole saviour" increases that individual's leverage. ("Remember when I saved the funding round?")

• The "Quiet Period" Myth. Leaders promise to address the silo "after the launch" or "after earnings." However, in high-growth companies, there is always another critical moment. The "temporary" tolerance becomes a permanent architecture of fragility.

The uncomfortable reality is that leadership thinks they are tolerating sovereignty on their own terms. The 10x'er knows they have made themselves essential during the moments that matter most. In the Heroics Trap, the organisation is not managing the risk, the risk is managing the organisation.

The Hidden Complicity and the Role of the Manager Factor

A 10x liability is often enabled by a manager who benefits from short-term delivery at the expense of long-term resilience.

Identify if this manager's success is built on unsustainable foundations. Look for a pattern where a manager delivers "great results," gets promoted and the team they left behind collapses within six months.

Resolve by making "Knowledge Distribution" a condition of that manager's next promotion.  Reward resilient teams, not just fast ones.

“War Room” Preparation and Building Your Resilience Audit

You have recognised the pattern.  You have run the diagnostics.  The Sovereign is creating systemic risk. Now what?

The natural instinct is to have a direct conversation, "We need to distribute knowledge.  Systems can't depend on one person."  ... do not have that conversation yet!

The moment you have that conversation - the one where you address their sovereignty directly - you have triggered a countdown. Not to transformation, but to crisis.

The reality:

• Day 1: You have the conversation

• Day 2: Subtle sabotage begins (commits get more opaque, Slack responses become terse)

• Week 1: They start talking to recruiters (visible on LinkedIn, suddenly "open to work")

• Week 2: First explicit threat during a 1-on-1,  "I have offers.  If this is the direction we're going..."

• Week 3: You call their bluff or do not meet demands

• Week 4: They resign (immediate effect in some jurisdictions, or 2-week notice at best)

  
  

You must prepare for immediate departure or active sabotage BEFORE you speak.

Week -2 to -1 The Shadow Documentation Sprint

Don't announce it. Just do it.

Assign senior developers to shadow critical systems under the pretence of "Business Continuity Planning" or "cross-training for on-call rotation."

Focus on:

• Critical paths: what breaks and how to fix it.

• Deployment processes: who can push to production and how.

• Integration points: where systems connect and what assumptions exist.

• "Tribal knowledge": undocumented decisions that only the 10x'er knows.

  
  

Document everything in a private repository.  Accept that it will be incomplete - you need something when they walk out.

If they resist even this innocuous "cross-training," you have confirmation you are dealing with a sovereignty hoarder.

Week -1 and Securing The Ejection Seat

Before the conversation, ensure:

• Access: At least two other people have admin access to all resources and systems the 10x developer does.

• Deployment: Pipelines can be triggered by others, not just them.

• Credentials: Any "personal" accounts flagged for immediate rotation if they leave.

• Backups: Source code backed up outside the 10x'ers control.

• Documentation: Architecture decisions (even incomplete) captured.

The 10x developer has accumulated "special" access over time.  Sudden departure becomes a security nightmare without this preparation.

Week -1 and Aligning Executive and Board Air Cover

Get explicit agreement from CEO/Board.

"We're addressing critical knowledge concentration risk. There is a real possibility this person leaves immediately when confronted.  Here is what we are prepared to do.  Here are the short-term costs.  Are we aligned this risk must be addressed?"

Set realistic recovery expectations:

• 6 weeks minimum for critical systems stabilisation.

• 3-6 months for full velocity recovery.

• Speed to market will be 30-50% slower during this period, but you will emerge with systems the entire team understands and can evolve.

You need this air cover because:

• You might lose the 10x'er (immediately or within 2 weeks).

• Short-term delivery will suffer materially.

• Stakeholders will be upset.

• You need support to weather 2-3 months of slower velocity.

If the CEO is not prepared for immediate departure, DO NOT have the conversation yet.

Mastering the ‘Warm but Bored’ Strategy

Your tone should be "Warm but Bored."  Pace is their strength.  Process is yours.  You are not matching their emotional velocity - you are offering a simple business requirement.

The Opening ...

"I need to discuss how we're managing technical knowledge and risk.  We have a business requirement to ensure no single person is a critical dependency.  This is about building organisational resilience."

"I'm going to be direct.  I need your help transitioning to a model where knowledge is distributed and systems are maintainable by the team.  I'd prefer to do this with your partnership over the next 60-90 days."

"But I also need to be clear,  if your preference is to move on rather than participate in this transition, I understand.  This is a significant change to how you've been working.  If you'd rather pursue opportunities elsewhere, we can discuss an exit plan that works for both of us."

Why this framing works:

• Acknowledges this is a big change for them.

• Gives them the "out" of leaving with dignity.

• Removes the leverage of threatening to leave.

• If they threaten, you have already offered the door.

The Non-Negotiables:

• Verifiability: All systems must be structured so a peer can verify a solution works within an hour.

• Standardisation: Use industry-standard protocols, even if "custom" is 5% faster.

• Governance: Security and audit tools are a business requirement, not a technical preference.

  
  

The Binary Choice of Partnership or Departure

The Threat: "I have three offers.  If this is the direction you're going, maybe it's time for me to move on."

Your Response (because you're prepared):

"I appreciate you being direct.  If you've decided this isn't the right environment for you anymore, let's discuss transition timing.  We can work out a notice period and knowledge transfer plan that's fair to both of us."

"What I won't do is continue operating with critical systems dependent on one person - that's not negotiable.  So if you're staying, we're implementing these requirements starting today.  If you're leaving, we'll plan accordingly."

The key: You are not begging them to stay.  You are not negotiating the requirements.  You are offering a binary choice.

Maintain "Warm but Bored": When they escalate to Shock and Awe tactics (The Escalation Ladder above), your energy stays level.  "I understand you're concerned. Let's document those concerns and address them methodically.  What I won't do is delay implementing these business requirements."

The 2-Week Lead Reviewer Assignment

To move from suspicion to proof, shift the developer from "Doing" to "Enabling."

The Mandate: "For the next two weeks, your only job is to enable and support others to implement features in your domain."

This test forces the developer's true intent to the surface:

• The Multiplier uses the time to document runbooks and empower the team.

• The Sovereign uses the time to find flaws in every peer implementation, "proving" the team cannot survive without them.

The Behaviour	The Verdict	The Path
Enthusiastic Mentorship: Documents runbooks and empowers others.	The Multiplier (Accidental Hero)	Path A: Partnership
Systemic Obstruction:  Uses "Shock and Awe" to prove others cannot do the work.	The Sovereign (Hoarder)	Path B: Managed Departure
Passive Resistance:  Stays but undermines; fails the test but will not leave.	The Saboteur	Path C: Managed Exit

The Three Action Paths

Path A: Partnership Transformation (90-Day Evolution)

• Month 1: Documentation. Capture architectural decisions.

  Success: A new dev can understand the system from  code handover and docs review.

• Month 2: Mentorship. Shift to "Review Only."

  Success: Peers push code with the 10x'er only reviewing.

• Month 3: Validation. Other developers make changes independently.

  Success: Team velocity is stable without the 10x'er as a gatekeeper.

Path B: Managed Departure (6 Weeks to 3 Months Recovery)

• Phase 1: Extraction. 4 hours/day of recorded knowledge transfer.  Focus on "What breaks" and "How to fix it." Document everything, even if incomplete.

• Phase 2: Recovery. Senior developers on high alert.  Accept 30-50% slower velocity during this period - slower, not stopped. Speed returns as team gains confidence and refactors the most opaque systems. Communicate transparently to stakeholders: "We're addressing technical risk. Delivery will be slower for 2-3 months, then we'll have the resilience we need."

Path C: Active Sabotage (The Managed Exit)

• Immediate Exit Option: If sabotage is active, evidence is clear or executive air cover is strong, exit same day or same week under NDA with generous severance. This is often cleaner and faster than a formal PIP process. Remember, generous severance is cheaper than a month of technical sabotage.

• Formal PIP route (if immediate exit is not viable):

  • Week 1-2: Clinical documentation of every blocked process.  Direct confrontation, "I will not accept passive resistance."

  • Week 3-4: Formal PIP and managed exit with documented cause.

What Happens Next?

You have recognised the pattern. You understand the risks. You have the playbook. The question is no longer, "Do we have a problem?" It is, "When are we going to act?"

Many reading this article may already know they have a sovereignty problem. The recognition is not new, the decision to act is.

• For CEOs: If you have been deferring this because of timing (earnings, product launch, funding round, etc.), understand what you are choosing. Every delay compounds the Sovereign's leverage. If you are ready to act, clear the path for your CTO: "I know we have a dependency problem with [name]. I am prepared for 3-6 months of reduced velocity to address it. What do you need from me to start?" That explicit backing is what unlocks action.

• For CTOs: Whether you are discovering this pattern for the first time or your CEO has just given you air cover, start with the private work. Run the Quick Diagnostic. Begin the Shadow Documentation Sprint. Secure the technical ejection seat. Build the cost model with your CFO - three scenarios: immediate exit, partnership transition and continued sovereignty. If you do not yet have CEO backing, take this data-driven case to them. If you do, proceed to the developer conversation using the "Warm but Bored" strategy and the 2-week diagnostic test.

• For CFOs: When this conversation reaches you, treat it as a board-level risk. Model the scenarios. The numbers make the case for resilience over heroics.

The choice is not between keeping a star and losing them. The choice is between a controlled transition on your timeline or an uncontrolled crisis at the worst possible moment.

What pattern are you recognising in your organisation right now?