Knowledge silos
The pull request reaches the same two reviewers as last time.
They know the service, remember the earlier discussion, and understand why the straightforward implementation would fail. One spots a missing condition. The author corrects it. The second approves, and the change reaches production before lunch.
Across the team, several other pull requests follow the same route. Three engineers review one another's work. Their conversations are quick, their explanations are short, and their decisions make sense to everyone involved.
An engineer outside the group asks why the service handles retries differently from the rest of the system. Someone replies, “There is some history there. Ask one of them before changing it.”
The review process is moving code and keeping understanding inside a circle.
This is the knowledge silo: a group repeatedly reviews its own work while having little review contact with the rest of the team. The code remains available to everyone. The reasoning needed to change it safely follows a much narrower route.
A silo can contain generous, capable colleagues. Each person may answer questions willingly and take care with every review. The boundary forms through repeated choices about who participates, which assumptions receive an explanation, and where the team expects understanding to live.
Familiarity makes those choices feel efficient.
The author already knows who will respond quickly. The reviewer remembers the customer constraint and needs little introduction. Both can discuss the change in the language they developed while building the service. Bringing someone else in would require an explanation, a slower first review, and perhaps a question the group thought it had settled months ago.
Under delivery pressure, the familiar route wins again.
The benefit is immediate and local. The cost accumulates across the team. Engineers outside the circle receive fewer opportunities to learn the area. Their next review takes longer because they still lack context. The author returns to the familiar reviewers because the alternatives are slower. Each repetition makes the original choice more reasonable.
Eventually, the team has created a boundary that reinforces itself.
This differs from the private island around one domain expert. A knowledge silo can have several strong contributors, lively debate, and dependable internal cover. Its members may share knowledge very well with one another. The difficulty appears at the edge, where the rest of the team needs access to the decisions they have learned to make together.
Specialization can support that arrangement for good reasons. Some systems require deep expertise. A security-sensitive change may need a qualified reviewer. Separate teams may own separate services deliberately. The useful question is whether the distribution of understanding supports the responsibilities people actually share.
If engineers are expected to cover one another's incidents, maintain a shared product, or move between services, their opportunities to learn need to cross the same boundaries. An ownership model that promises shared responsibility while preserving private context creates an obligation people lack the preparation to meet.
Look at review relationships over several weeks.
Who reviews whose changes? Which engineers repeatedly appear together? Who receives review from the group but rarely contributes to its discussions? Who remains outside the meaningful conversations altogether? Compare those relationships with the code areas, work assignments, and operational responsibilities involved.
Repository data can help locate a circle. Read a sample of the conversations to understand what the circle means. A recorded approval says little about whether the reviewer understood the domain, challenged an assumption, or simply checked a local implementation detail. Pairing and design discussions may also carry knowledge that the review tool never records.
The pattern becomes more convincing when repeated relationships coincide with an inability to work across them.
An engineer can follow the syntax but needs a particular colleague to explain the behavior. A support question moves through three people before reaching the group. Planning repeatedly assigns work to the same engineers because everyone else would need too much introduction. A change spanning two areas waits while each group explains its assumptions to the other.
Listen to the shorthand in those moments. “They handle that.” “We always ask them.” “Someone from that group needs to be around.” These statements can describe sensible ownership. Ask what another engineer would need to act safely, and whether the team has a practical way for them to acquire it.
The causes often sit in ordinary working arrangements.
People who share an office, a time zone, or a long project history can reach each other easily. A new colleague may receive tickets around the edges while the original contributors continue handling consequential changes. A review queue may reward whoever responds first, making a dependable pair the route through which most work passes.
Sometimes the circle offers safety. Engineers may prefer reviewers who let them ask basic questions, explain concerns clearly, or disagree without turning the exchange into a contest. A group can become closed because the wider review culture makes participation expensive. Randomly assigning new reviewers will do little until the team understands that experience.
Sometimes managers build the silo through allocation. Every urgent task goes to the people who already know the area. Every learning opportunity waits for a quieter sprint. The team keeps meeting today's need by borrowing against its future ability to move work elsewhere.
The first useful conversation should preserve what is working.
“These reviews move well between the three of you. We also keep waiting for your group whenever someone else touches this service. What would help another engineer become capable here?” acknowledges both the strength and its boundary. Ask people outside the group what makes participation difficult. Their answers may concern missing context, response times, access, confidence, or the way previous questions were received.
Choose one boundary to open and one real piece of work to carry across it.
A contained change gives a new participant something concrete to understand. Pair an experienced reviewer with an engineer from outside the circle. Explain the purpose of the service, the important constraints, and the part of the change where judgment matters. Give the newcomer a specific review responsibility and time to carry it out.
For example, the experienced engineer might explain why retrying a request can duplicate an external action. The new reviewer then traces the failure path, checks the tests, and asks how the change preserves the guarantee. Their contribution has a purpose, and the explanation connects to a decision they can make again.
Participation should develop into responsibility.
After reviewing a contained change, the engineer might implement the next one with support. Later, they can review a similar change and explain the reasoning to another colleague. The original group remains available for difficult cases while ordinary work begins to travel through more people.
Keep specialist review where the risk requires it. Broader participation can accompany that review and gradually build the capability needed for more independence. A person learning the domain should know which decisions they can make and when to seek help.
Make recurring explanations easier to find.
Record why retries work differently, which external guarantees the service depends on, and how to verify a change safely. Put the explanation near the code, tests, or operational instructions where someone will need it. A short decision record tied to a concrete failure case often helps more than a broad document describing every component.
Ask the person learning the area to help write or revise that record. They can identify the assumptions an experienced contributor skips. Then use the explanation during another change. That second use reveals whether it actually supports someone who arrives without the original conversation.
Managers need to make room for this work in the plan.
A supported first review will take longer. A task assigned for learning may finish later than the same task given to its usual owner. Account for that time explicitly and choose work whose urgency allows it. Otherwise, the team will abandon the wider route as soon as delivery pressure returns.
Share the teaching load as well. Different members of the group can support different changes. Protect their own focus time, and reduce other commitments while they help colleagues build context. Spreading knowledge becomes sustainable when it is part of the team's capacity rather than an extra obligation carried by its most knowledgeable people.
Watch what happens over the next several changes.
Can another engineer explain the constraint that used to require a private conversation? Can they complete a bounded task and recognize when they need specialist help? Do useful questions arrive from a wider set of reviewers? Does planning have more credible options for assigning work? Can the usual contributors take leave without leaving routine decisions suspended?
A broader reviewer list alone gives weak evidence. The stronger signal is someone using what they learned to make a sound decision, then helping another person understand it. Review relationships help locate the opportunity; work performed with less dependence shows whether understanding has spread.
The opening review circle already contains something valuable: people who know the system and can reason together. A healthier team gives more colleagues a way into that conversation, enough time to learn, and meaningful work through which to use what they learn.
The next pull request reaches one familiar reviewer and one colleague who now understands the retry behavior. This time, that colleague spots the missing condition and explains why it matters.