Developers on Islands

One of the most common patterns I see on struggling teams is what I’ve started calling “developers on islands.”

Each developer owns a piece of the codebase. They built it, they understand it, and nobody else really does. Work gets assigned based on who built what. When something breaks in that area, there’s only one person who can fix it. When that person is out, progress stops. When that person leaves the company, the knowledge walks out with them.

It feels like specialization. It’s actually fragility.

What It Actually Looks Like

The island pattern is rarely intentional. It usually develops gradually:

• The team is busy, so code reviews become rubber stamps or get skipped
• Pairing never quite becomes a habit because everyone’s working on different things
• The codebase grows, and it becomes easier to stay in familiar territory than to learn an unfamiliar module
• Ownership solidifies into something unspoken — Sarah handles payments, Marcus handles the API, the new guy gets the reporting module

Over time, the architecture starts to mirror the org chart. The team thinks of the codebase as a collection of individual responsibilities rather than a shared system.

Why Velocity Numbers Lie on These Teams

When I look at a team with the island pattern, the capacity math rarely adds up.

On the surface it looks like a team of eight. In practice, most stories can only be picked up by one or two people. The other six have low-friction work available, but the high-priority items are bottlenecked on whoever owns the relevant area. Half the team is either idle on the things that matter or pulled into the wrong work to stay busy.

Velocity tracks completed points, not actual throughput on the things that count. A team can hit its velocity number while consistently underdelivering on priority work — because the priority work is stuck behind the one person who knows that part of the system.

The Knowledge-Leaving Problem

The clearest way to see the cost of the island pattern is to do a thought experiment: pick any key developer and ask what happens if they’re out tomorrow.

Not on vacation — gone. New job. Which work stops? Which bugs can’t be diagnosed? Which parts of the codebase become effectively unmaintainable?

If the honest answer is “a lot,” that’s not a people problem. That’s a structural problem. The team has allowed critical knowledge to concentrate in individuals rather than distribute across the team.

This is also how teams become hostage to their own engineers. When one person is the only one who understands a critical system, the cost of them leaving becomes enormous — and they know it. Healthy teams don’t have individuals who are irreplaceable. They have individuals who are valuable.

What Good Looks Like

The antidote to developer islands isn’t micromanagement or forced rotation. It’s building the habits that naturally spread context:

Real code review. Not approval theater. Code review where someone who doesn’t own the area is genuinely expected to understand what’s being changed, ask questions about the approach, and catch things the author missed. This is the single highest-leverage habit for fighting the island pattern — it forces knowledge transfer on every merge.

Pairing on unfamiliar territory. When developers work together on code they don’t both know well, both of them come out knowing more. This doesn’t have to be every story — but it should be deliberate, especially when onboarding into a new area.

Work allocation that stretches ownership. If the same person always picks up payments work, nobody else ever learns it. Managers and leads need to occasionally assign work specifically to build bench depth — even when it’s slower in the short term.

Architecture that’s documented and owned by the team. When the only documentation of how a system works lives in someone’s head, you don’t have a team codebase. You have a collection of individually owned modules that happen to be in the same repository.

The Accountability Question

There’s often a management failure underneath the island pattern.

It’s easier in the short run to assign work to whoever already knows an area. It’s faster. It avoids the friction of ramp-up time. It feels efficient.

What it actually does is defer the cost — and compound it. Every story that gets assigned to the person who “owns” that area makes the island bigger and the team’s dependency on that individual stronger.

Engineering leaders who allow this pattern to calcify are making a trade they often don’t recognize as a trade. The short-term productivity gain comes at the cost of team resilience, predictability, and capacity over time.

Building a team that can move work fluidly — where anyone can pick up a story in any area and be productive within a reasonable ramp-up — is harder than building islands. But it’s the only way to have a team that actually scales.

The velocity number will thank you too.