In medieval times, lords ruled their fiefdoms with an iron fist. They had absolute authority over their territories, decided who could enter, what could be built, and who could leave. Fast forward to the modern software engineering era, and you might find something eerily similar lurking in your codebase—except instead of castles and moats, we have pull requests, code reviews, and firmly guarded repositories. Code ownership is supposed to be a good thing. The idea is simple: someone (or a team) takes responsibility for a piece of code, understands it deeply, maintains it, and ensures its quality. Yet somewhere along the way, this well-intentioned practice mutates. Ownership becomes gatekeeping. Responsibility becomes control. And before you know it, you’ve got developers who treat their code modules like personal kingdoms, making life miserable for everyone else trying to get anything done. The question isn’t really about whether you should have code ownership. You should. But it’s about how you implement it and when it becomes counterproductive. That’s where things get spicy.

The Three Flavors of Code Ownership

Let’s start with the frameworks. Martin Fowler, a software architecture luminary, identified three distinct models of code ownership, and understanding them is crucial before you can diagnose what’s wrong with yours.

Strong Code Ownership: The Totalitarian State

Strong code ownership assigns each module, file, or function to exactly one developer or team. Only that owner can make changes. Everyone else? They’re locked out. Want to modify something? You submit a patch or pull request and hope the owner is feeling generous that day. The appeal is obvious: crystal-clear accountability. When something breaks, you know exactly who to blame—or credit. The owner becomes deeply invested in their domain, enforces consistent quality standards, and makes design decisions that pay dividends down the line. They’re the guardian of their piece of the product, and everything that goes in has to meet their personal standards. But here’s where the crown starts to get uncomfortable: this model creates bottlenecks. That one person becomes a single point of failure. When they’re on vacation (or heaven forbid, leave the company), their entire kingdom becomes frozen in time. Other developers tiptoe around these protected territories, duplicating code or creating workarounds because going through the owner is too painful. This is where strong code ownership often devolves into fiefdom territory.

Weak Code Ownership: Democracy With Oversight

Weak code ownership keeps the owners in place but loosens the chains. Modules still have designated owners, but other developers can modify them without explicit permission. The catch? Owners review these changes, oversee them, and maintain the right to push back. Think of it as constitutional monarchy—there’s a ruler, but the peasants can actually get things done. Changes move faster, collaboration improves, and bottlenecks dissolve. The owner remains responsible for code quality but doesn’t have to personally write every line. They’re more like an editor than a dictator. This model hits a sweet spot for many organizations. It balances accountability with flexibility, maintaining quality control without grinding productivity to a halt.

Collective Code Ownership: The Commune

Collective code ownership is the wild west: everyone is responsible for everything. Any developer can modify any part of the codebase, regardless of who wrote it. The theory is beautiful—maximum flexibility, maximum collaboration, shared responsibility. The practice? It’s… complicated. Without clear boundaries, things get chaotic. Who’s responsible for fixing that bug? Who’s maintaining consistency? What happens when two developers make conflicting changes? Collective ownership often sounds egalitarian until someone needs to find who caused a production outage at 3 AM. That said, collective ownership isn’t inherently bad. Many successful teams use it, especially smaller organizations or tight-knit groups where communication flows naturally.

The Fiefdom Condition: Symptoms and Diagnosis

Here’s where things get real. You can recognize a fiefdom by its unmistakable stench.

The Classic Fiefdom Symptoms

The Gatekeeper Developer: There’s always one. They own three critical modules because they wrote them six years ago. Now they’re the only person who understands them, and they’re not exactly running a tutorial series. Other developers have learned it’s faster to duplicate code than negotiate with the gatekeeper. Pull requests to their domains languish for weeks. The Territorial Boundary: Cross-team work becomes a diplomatic nightmare. Team A needs to modify something in Team B’s territory. Suddenly, there are stakeholder meetings, design documents, and more meetings about the meetings. A five-minute change takes three weeks to negotiate. The Accountability Vacuum: Weirdly, strong ownership sometimes creates no accountability. Because the owner is so powerful, there’s nobody to check them. They can let code rot, ignore bugs, or make terrible design decisions, and who’s going to override them? It’s their kingdom. The Knowledge Silo: The owner knows their code intimately. Everyone else? Clueless. When the owner is the only person who understands something, you’ve created a massive organizational risk. What if they get hit by a bus? (Don’t laugh—it happens.) The Stale Ownership: Former team members remain listed as code owners even after they’ve moved to different projects or companies. Their PRs pile up because they’re no longer actively reviewing, but nobody bothered to update the ownership records. The Catch-All Bottleneck: One team owns too much disparate code, becoming a choke point for the entire organization. Every other team depends on them to merge their changes. That team is now running at 50% capacity just doing code reviews.

The Telltale Signs You’re Living in a Fiefdom

Let me give you a diagnostic checklist. If you recognize your team in three or more of these, you’ve got a fiefdom problem:

  1. Pull request cycle time exceeds one week for routine changes
  2. Developers outside a team rarely contribute to certain modules
  3. Code duplication exists because it’s faster than getting approval from the owner
  4. Onboarding new team members takes months before they can independently modify certain code
  5. Ownership decisions are based on “who wrote it” rather than “who understands it”
  6. Cross-team PRs require multiple rounds of back-and-forth
  7. Code review comments are frequently critical or dismissive rather than collaborative
  8. Key modules have a single owner with no backup

The Cost of Fiefdoms: Why This Actually Matters

Code fiefdoms aren’t just annoying—they’re expensive. In real money. Slower Feature Delivery: Bottlenecks in code review directly slow down feature velocity. If every change requires negotiating with the gatekeeper, shipping takes longer. Developer Frustration: Programmers want to ship code. They want to solve problems. When they’re blocked by territorial ownership, they get frustrated and leave. Retention suffers. Duplicated Code: Rather than wait for approval, developers create workarounds and duplicate functionality. This makes the codebase harder to maintain and creates consistency problems. Bus Factor Risk: If your code ownership maps to individuals rather than teams, you’ve created organizational vulnerability. One person leaves, and you’re in crisis mode. Innovation Atrophy: Teams that can’t easily contribute to core systems stop trying. They stop learning. Cross-functional collaboration dies.

Building Healthy Code Ownership: The Framework

Okay, so you’ve diagnosed the fiefdom problem. Now what? Here’s a practical approach to establishing ownership that promotes responsibility without creating territory.

Step 1: Define Ownership by Product Area, Not by Person

# CODEOWNERS example - align with product boundaries
# Online Store Platform
/src/checkout/          @payment-team
/src/inventory/        @fulfillment-team
/src/catalog/          @product-team
/src/auth/             @security-team
/src/shared/utils/     @platform-team

Notice: ownership is team-based, not individual. And it’s organized by product domain (checkout, inventory, catalog), not by arbitrary file structure. This matters because teams are more resilient than individuals.

Step 2: Establish Weak Code Ownership as Your Default

Don’t require explicit approval for every change. Instead, make code changes to owned modules notification-based and asynchronous review-able. Here’s what that looks like in practice:

# A developer from another team modifies something in your domain
# They don't ask permission first
# They submit a PR with a description of their change
# Your team reviews it at your convenience, not on their schedule
# If it's good, it merges
# If there are concerns, you collaborate to fix them

This is weak ownership. It’s respectful of time, maintains quality, and keeps momentum.

Step 3: Create Knowledge Overlap Systematically

Single points of knowledge are single points of failure. Make it part of your development culture that critical systems have multiple people who understand them.

# Onboarding Checklist for [Module Name]
## Phase 1: Shadowing (Week 1)
- [ ] Pair with current owner on bug fix
- [ ] Review architecture documentation
- [ ] Run the test suite
## Phase 2: Guided Changes (Week 2-3)
- [ ] Make a small improvement under guidance
- [ ] Review related modules
- [ ] Write additional test cases
## Phase 3: Independent Changes (Week 4+)
- [ ] Handle your first unsupervised PR
- [ ] Document the thing you just learned
- [ ] Help the next person learn it

Step 4: Use Commit-Based and Line-Based Ownership Strategically

Research shows there are two ways to measure code ownership, and they serve different purposes: Line-based ownership: Measures the proportion of code lines authored by a developer. Use this for accountability, intellectual property questions, and authorship attribution. Commit-based ownership: Measures frequency of changes. Use this for rapid bug-fixing and quality improvement plans.

# Example: Git command to find line-based ownership
git blame src/critical_module.py | awk '{print $2}' | sort | uniq -c | sort -rn
# Example: Git command to find commit-based ownership
git log --pretty=format:"%an" src/critical_module.py | sort | uniq -c | sort -rn

These give you different insights. Don’t conflate them.

Step 5: Regular Ownership Audits

Ownership doesn’t stay current automatically. Create a quarterly process to review and update ownership:

Ownership Audit Checklist:
- [ ] Are all CODEOWNERS entries active team members?
- [ ] Is ownership distributed reasonably (no catch-all teams)?
- [ ] Are there modules with no clear owner?
- [ ] Have ownership changes been communicated?
- [ ] Is documentation for critical modules up-to-date?
- [ ] Can the code be maintained if the owner leaves next week?

Visualizing Ownership Health

Here’s a diagram showing how different ownership models affect team dynamics over time:

graph TD A["Code Ownership Decision"] --> B{Choose Model} B -->|Strong| C["High Accountability
Low Flexibility"] B -->|Weak| D["Balanced
Accountability & Flexibility"] B -->|Collective| E["High Flexibility
Unclear Accountability"] C --> F["Risk: Bottlenecks"] C --> G["Risk: Knowledge Silos"] F --> H["Fiefdom Territory"] G --> H D --> I["Healthy
Team Dynamics"] E --> J["Risk: Chaos"] E --> K["Risk: Quality Issues"] J --> L["Unstable
Codebase"] K --> L

Anti-Patterns: What NOT to Do

Let me be brutally honest about what I’ve seen teams do wrong: The Nameplate Syndrome: Leaving a developer’s name on code they haven’t touched in three years, just because they wrote the initial version. This creates ghost owners who materialize occasionally to say “no” to changes. The Architecture as Fiefdom: Sometimes entire architectural decisions become owned by one person who wrote the RFC three years ago. Now they’re the gatekeeper for architectural evolution. This kills innovation. The Tool Misuse: Using CODEOWNERS as a weapon rather than a guide. Setting it up so that multiple approvals are required for every change. Ownership becomes control theater. The Absence of Documentation: Relying entirely on the owner’s brain. When they leave or are unavailable, the code becomes inscrutable. Knowledge hoarding, whether intentional or not, is a fiefdom enabler. The Blame Culture: Creating an environment where code ownership is about accountability in a negative sense—finding someone to blame when things break—rather than about stewardship and continuous improvement.

Practical Implementation: A Real Example

Let me walk you through how to refactor an unhealthy ownership structure:

Before: The Fiefdom

/src/payments/          @alice (untouchable, reviews slowly)
/src/analytics/         @bob (no reviews, code is degrading)
/src/reporting/         @charlie (left company, ghost owner)
/src/auth/              @alice (too much responsibility)
/src/api/               (no clear owner, chaos)

Alice is overburdened. Bob isn’t maintaining his code. Charlie doesn’t exist anymore. The API team is a free-for-all.

After: Healthy Ownership

/src/payments/          @payments-team (alice, dev-x)
/src/payments-core/     @payments-team, @platform-team (shared)
/src/analytics/         @data-team (bob is primary, dev-y is backup)
/src/reporting/         @data-team (removed charlie, added new team member)
/src/auth/              @security-team (alice now focuses here)
/src/api/               @api-team (new team, clear responsibility)

Changes:

  • Team-based instead of individual: Reduces bus factor
  • Explicit secondaries: Someone always knows the code
  • Clear removal of ghost owners: No more stalled PRs
  • Aligned with product structure: Makes sense organizationally
  • Shared ownership where needed: Payment core is critical, so two teams share it

Metrics That Actually Matter

Stop measuring code ownership by counting commits. Instead, track these: Time to Review: Average time from PR submission to review start. Healthy teams: under 24 hours. Approval Rate: Percentage of PRs approved by the original code owner. This should be high (80%+) but not 100% (which suggests all changes go through one person). Knowledge Distribution: What percentage of your critical modules can be modified by only one person? Aim for under 20%. Ownership Turnover: When was the last time someone new successfully contributed to this module? Should be recent (within a few months). Bus Factor: How many people need to be unavailable before this module becomes unmaintainable? Should be 2+.

# Simple Python script to analyze CODEOWNERS distribution
import re
from collections import Counter
def analyze_codeowners(filepath):
    owners = []
    with open(filepath, 'r') as f:
        for line in f:
            line = line.strip()
            if line and not line.startswith('#'):
                parts = line.split()
                if len(parts) > 1:
                    owners.extend(parts[1:])
    owner_count = Counter(owners)
    total_entries = len(owners)
    print(f"Total code areas: {total_entries}")
    print(f"Unique owners: {len(owner_count)}")
    print(f"\nOwnership distribution:")
    for owner, count in owner_count.most_common():
        percentage = (count / total_entries) * 100
        print(f"  {owner}: {count} ({percentage:.1f}%)")
        if percentage > 30:
            print(f"    ⚠️  Warning: {owner} owns over 30% of codebase")
analyze_codeowners('.github/CODEOWNERS')

The Conversation You Need to Have

Here’s the uncomfortable truth: fixing fiefdom problems often requires difficult conversations. You might need to tell your best developer that they can’t be the sole owner of three critical modules anymore. You might need to establish code review SLAs and enforce them. You might need to make unpopular architectural decisions to break up fiefdoms. Frame it positively: This isn’t about reducing someone’s importance. It’s about building a stronger, more resilient team where knowledge is distributed and everyone’s contribution is valued. Start small: Don’t try to restructure everything overnight. Pick one problematic area and fix it. Show success. Then repeat. Involve the team: The people who currently own the fiefdoms often have good reasons for their gatekeeping (even if they won’t admit it). Maybe they’re overwhelmed. Maybe they’ve been burned by bad changes before. Listen to them.

The Uncomfortable Truth

Here’s what I really think, and why I’m writing this article: code ownership matters, but person-based ownership is often a proxy for poor management. When you need one person to own a domain to ensure quality, it often means:

  • You don’t have enough senior developers
  • Your code is poorly documented
  • Your team doesn’t have good communication
  • Your onboarding process is weak
  • Your review culture is harsh Fix the root cause, not just the symptom. Fiefdoms form because we create conditions where they’re necessary. A well-managed team with good documentation, regular knowledge-sharing, and a collaborative culture doesn’t need fiefdoms. They need ownership models, sure, but ones that distribute knowledge and responsibility.

The Path Forward

If you’re currently living in a fiefdom situation:

  1. Name the problem: Get specific about what’s not working
  2. Audit your ownership structure: Use the checklist above
  3. Define a better model: Based on weak ownership or distributed teams, not individual control
  4. Create knowledge pathways: Systematic onboarding, mentoring, documentation
  5. Establish governance: Use CODEOWNERS files, update them regularly, make ownership decisions explicit
  6. Measure health: Track the metrics that actually matter
  7. Iterate: This isn’t a one-time fix. Ownership needs to evolve as your team and codebase grow Code ownership is a tool for building better software through clear responsibility. But like any tool, it can be misused. The difference between healthy ownership and fiefdom territory is intention and execution. The best teams I’ve seen don’t talk about “my code” or “their code.” They talk about “the code we’re building together.” That’s when ownership stops being about territory and starts being about stewardship. What does healthy code ownership look like in your organization? Are you building stewarlords or fiefdom lords? The answer might surprise you—and that’s the conversation worth having.