3 Developer Habits That Make Teams Fragile

Updated 14 November 2026 · Standard formula, shown below

This guide explains how three common developer habits—single-owner code, unreviewed shortcuts, and silent knowledge hoarding—can quietly make a team fragile, and what you can do to reverse each one. You’ll get concrete, actionable steps to build resilience without slowing down delivery. No special tools are required, just a willingness to change how you and your teammates work.

What You’ll Need

A shared code repository (Git, Mercurial, etc.)
A code review tool (pull requests, Gerrit, etc.)
A team chat or meeting slot for discussions
Commit access for all team members (or a plan to grant it)

Step-by-Step

Identify the fragile habits in your team. Look for signs: only one person understands a critical module, code is merged without review, or knowledge is passed only through private chats. Write down specific examples—like “the payment service is only edited by Alice” or “Bob’s hotfix went straight to main.”
Break single-owner code. For each critical area, assign a “primary” and a “secondary” owner. The secondary must review every change and be able to explain the code. Rotate ownership every 3–6 months. Start with the most fragile module—the one that breaks often or that only one person can fix.
Make code review mandatory for all changes. Set a rule: no pull request, no merge. Even for “small” fixes. Use a lightweight checklist (does it compile, are tests added, does it follow the style guide). If your team is small, use a rotating reviewer so no one becomes a bottleneck.
Document decisions and rationale. When you make a non-obvious choice, write it down in the code comment or a short ADR (Architecture Decision Record). Include the trade-offs you considered. This prevents future “why is this like this?” questions and reduces the bus factor.
Hold regular knowledge-sharing sessions. Once a week, have one person explain a piece of code they wrote or that they’ve learned about. Keep it to 15–20 minutes. This forces the “expert” to articulate their mental model, and it gives others a safe place to ask questions.
Encourage pairing on hard tasks. For the most complex bugs or features, have two people work together, even if it’s just for the initial investigation. This transfers context in real time and prevents one person from becoming the sole problem-solver.
Track and reduce “hero” moments. If someone is constantly fixing production issues alone at odd hours, that’s a red flag. Use a shared incident log. After each incident, ask: “What would we have done if this person were unavailable?” Then automate or document that step.
Review your progress monthly. Check if the fragile habits are reappearing. For example, are there still files that only one person has ever touched? Are review times getting too long? Adjust your process—maybe you need more pair programming or better documentation.

Common Mistakes

Forcing review on everything without exception. This can slow down urgent fixes. Instead, allow a “fast track” for hotfixes, but require a post-hoc review within 24 hours.
Rotating ownership too quickly. If you change owners every month, no one gains deep knowledge. Keep the rotation long enough (3–6 months) to truly learn the code.
Treating documentation as a chore. If you write long, exhaustive docs, no one will read them. Keep it short—a few bullet points on why a decision was made is enough.
Ignoring the social dynamic. Some developers feel threatened by sharing knowledge. Frame it as “we’re all learning” rather than “you must prove you’re not indispensable.”
Not following through. It’s easy to say “we’ll start reviewing” but if you don’t enforce it, the habit fades. Use a tool that blocks merges without approval, or make it a team rule with visible consequences.

Tips

Start small. Pick one fragile area and apply these steps there first. Once you see improvement, expand to other parts of the codebase.
Use automation. Set up a CI check that requires at least one approval. This takes the human judgment out of “should I review this?” and makes it automatic.
Make knowledge sharing fun. Turn it into a game—who can explain a module in under 5 minutes? Or have a “teach me something” lunch.
Celebrate when someone asks a good question. That shows curiosity, which is the opposite of fragility.
Be patient. Changing habits takes weeks. Don’t expect immediate results; focus on consistent practice.

Troubleshooting

What if a developer resists sharing knowledge? Have a one-on-one conversation. Explain that the goal is to reduce risk for the team and for them personally—if they’re the only one who knows something, they can’t take a vacation without worrying. Offer to start with a low-stakes area.
What if code review becomes a bottleneck? If reviews are taking too long, reduce the scope of each review—ask for a quick check on correctness, not style. Or use a “review buddy” system where each pair reviews each other’s changes.
What if documentation is still not written? Try a different format. Instead of a wiki, use a README in the code directory. Or record a 2-minute video explaining the decision. The key is to capture the “why,” not the “how.”
What if the team is too busy to add these practices? Start with the most critical module only. Even 15 minutes a day for pairing or review can make a difference. Explain that investing time now saves time later in debugging and onboarding.
What if the fragile habit is already causing issues? If a key person is out and no one can fix a bug, do a post-mortem. Identify what knowledge was missing and write it down immediately. Then schedule a pairing session to fill the gap.

Frequently Asked Questions

How long does it take to see improvement?

Usually within a few weeks you’ll notice fewer “only one person knows” situations. Full resilience takes a few months, depending on the size of the codebase.

Can these habits work for a remote team?

Yes. Pairing can be done via screen sharing, reviews are already digital, and documentation is even more important when you’re not in the same room.

What if my team is just two people?

Even with two, you can review each other’s changes and share ownership. The principles scale down.

Is it ever okay to have a single owner?

For very small, experimental projects, it might be fine. But for anything that runs in production, you want at least two people who understand it.

How do I convince my manager to allow time for this?

Frame it as risk reduction. Show that a single point of failure could cause downtime or missed deadlines. A small investment in review and pairing prevents bigger costs later.

What if the “expert” is the one who resists change?

Try to understand their concern. They might fear losing control or being slowed down. Reassure them that they’ll still be the primary decision-maker, but now with a safety net.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.