Team and Knowledge Problems

• 1: The Team Has No Shared Working Hours Across Time Zones
• 2: Retrospectives Produce No Real Change
• 3: The Team Has No Shared Agreements About How to Work
• 4: The Same Mistakes Happen in the Same Domain Repeatedly
• 5: Delivery Slows Every Time the Team Rotates
• 6: Team Membership Changes Constantly

1 - The Team Has No Shared Working Hours Across Time Zones

What you are seeing

A developer in London finishes a piece of work at 5 PM and creates a pull request. The reviewer in San Francisco is starting their day but has morning meetings and gets to the review at 2 PM Pacific - which is 10 PM London time, the next day. The author is offline. The reviewer leaves comments. The author responds the following morning. The review cycle takes four days for a change that would have taken 20 minutes with any overlap.

Integration conflicts sit unresolved for hours. The developer who could resolve the conflict is asleep when it is discovered. By the time they wake up, the main branch has moved further. Resolving the conflict now requires understanding changes made by multiple people across multiple time zones, none of whom are available simultaneously to sort it out.

The team has adapted with async-first practices: detailed PR descriptions, recorded demos, comprehensive written documentation. These adaptations reduce the cost of asynchrony but do not eliminate it. The team’s throughput is bounded by communication latency, and the work items that require back-and-forth are the most expensive.

Common causes

Long-lived feature branches

Long-lived branches mean that integration conflicts are larger and more complex when they finally surface. Resolving a small conflict asynchronously is tolerable. Resolving a three-day branch merge asynchronously is genuinely difficult - the changes are large, the context for each change is spread across people in different time zones, and the resolution requires understanding decisions made by people who are not available.

Frequent, small integrations to trunk reduce conflict size. A conflict that would have been 500 lines with a week-old branch is 30 lines when branches are integrated daily.

Read more: Long-lived feature branches

Monolithic work items

Large items create larger diffs, more complex reviews, and more integration conflicts. In a distributed team, the time cost of large items is amplified by communication overhead. A review that requires one round of comments takes one day in a distributed team. A review that requires three rounds takes three days. Large items that require extensive review are expensive by construction.

Small items have small diffs. Small diffs require fewer review rounds. Fewer review rounds means faster cycle time even with the communication latency of a distributed team.

Read more: Monolithic work items

Knowledge silos

When critical knowledge lives in one person and that person is in a different time zone, questions block for 12 or more hours. The developer in Singapore who needs to ask the database expert in London waits overnight for each exchange. Externalizing knowledge into documentation, tests, and code comments reduces the per-question communication overhead.

When the answer to a common question is in a runbook, a developer does not need to wait for the one person who knows. The knowledge is available regardless of time zone.

Read more: Knowledge silos

How to narrow it down

1. What is the average number of review round-trips for a pull request? Each round-trip adds approximately one day of latency in a distributed team. Reducing item size reduces review complexity. Start with Monolithic work items.
2. How often do integration conflicts require synchronous discussion to resolve? If conflicts regularly need a real-time conversation, they are large enough that asynchronous resolution is impractical. Start with Long-lived feature branches.
3. Do developers regularly wait overnight for answers to questions? If yes, the knowledge needed for daily work is not accessible without specific people. Start with Knowledge silos.

Ready to fix this? The most common cause is Long-lived feature branches. Start with its How to Fix It section for week-by-week steps.

2 - Retrospectives Produce No Real Change

What you are seeing

The same themes come up every sprint: too much interruption, unclear requirements, flaky tests, blocked items. The retrospective runs every two weeks. Action items are assigned. Two weeks later, none of them were completed because sprint work took priority. The same themes come up again. Someone adds them to the growing backlog of process improvements.

The team goes through the motions because the meeting is scheduled, not because they believe it will produce change. Participation is minimal. The facilitator works harder each time to generate engagement. The conversation stays surface-level because raising real problems feels pointless - nothing changes anyway.

The dysfunction runs deeper than meeting format. There is no capacity allocated for improvement work. Every sprint is 100% allocated to feature delivery. Action items that require real investment - automated deployment, test infrastructure, architectural cleanup - compete for time against items with committed due dates. The outcome is predetermined: features win.

Common causes

Unbounded WIP

When the team has more work in progress than capacity, every sprint has no slack. Action items from retrospectives require slack to complete. Without slack, improvement work is always displaced by feature work. The team is too busy to get less busy.

Creating and protecting capacity for improvement work is the prerequisite for retrospectives to produce change. Teams that allocate a fixed percentage of each sprint to improvement work - and defend it against feature pressure - actually complete their retrospective action items.

Read more: Unbounded WIP

Push-based work assignment

When work is assigned to the team from outside, the team has no authority over their own capacity allocation. They cannot protect time for improvement work because the queue is filled by someone else. Even if the team agrees in the retrospective that test automation is the priority, the next sprint’s work arrives already planned with no room for it.

Teams that pull work from a prioritized backlog and control their own capacity can make and honor commitments to improvement work. The retrospective can produce action items that the team has the authority to complete.

Read more: Push-based work assignment

Deadline-driven development

When management drives to fixed deadlines, all available capacity goes toward meeting the deadline. Improvement work that does not advance the deadline has no chance. The retrospective can surface the same problems indefinitely, but if the team has no capacity to address them and no organizational support to get that capacity, improvement is structurally impossible.

Read more: Deadline-driven development

How to narrow it down

1. Are retrospective action items ever completed? If not, capacity is the first issue to examine. Start with Unbounded WIP.
2. Does the team control how their sprint capacity is allocated? If improvement work must compete against externally assigned feature work, the team lacks the authority to act on retrospective outcomes. Start with Push-based work assignment.
3. Is the team under sustained deadline pressure with no slack? If the team is always in crunch, improvement work has no room regardless of capacity or authority. Start with Deadline-driven development.

Ready to fix this? The most common cause is Unbounded WIP. Start with its How to Fix It section for week-by-week steps.

3 - The Team Has No Shared Agreements About How to Work

What you are seeing

Half the team uses feature branches; half commit directly to main. Some developers expect code reviews to happen within a few hours; others consider three days fast. Some engineers put every change through a full review; others self-merge small fixes. The WIP limit is nominally three items per person but nobody enforces it and most people carry five or six.

These inconsistencies create friction that is hard to name. Pull requests sit because there is no shared expectation for turnaround. Work items age because there is no agreement about WIP limits. Code quality varies because there is no agreement about review standards. The team functions, but at a lower level of coordination than it could with explicit norms.

The problem compounds as the team grows or becomes more distributed. A two-person co-located team can operate on implicit norms that emerge from constant communication. A six-person distributed team cannot. Without explicit agreements, each person operates on different mental models formed by prior team experiences.

Common causes

Push-based work assignment

When work is assigned to individuals by a manager or lead, team members operate as independent contributors rather than as a team managing flow together. Shared workflow norms only emerge meaningfully when the team experiences work as a shared responsibility - when they pull from a common queue, track shared flow metrics, and collectively own the delivery outcome.

Teams that pull work from a shared backlog develop shared norms because they need those norms to function - without agreement on review turnaround and WIP limits, pulling from the same queue becomes chaotic. When work is individually assigned, each person optimizes for their assigned items, not for team flow, and the shared agreements never form.

Read more: Push-based work assignment

Unbounded WIP

When there are no WIP limits, every norm around flow is implicitly optional. If work can always be added without limit, discipline around individual items erodes. “I’ll review that PR later” is always a reasonable response when there is always more work competing for attention.

WIP limits create the conditions where norms matter. When the team is committed to a WIP limit, review turnaround, merge cadence, and integration frequency become practical necessities rather than theoretical preferences.

Read more: Unbounded WIP

Thin-spread teams

Teams spread across many responsibilities often lack the continuous interaction needed to develop and maintain shared norms. Each member is operating in a different context, interacting with different parts of the codebase, working with different constraints. Common ground for shared agreements is harder to establish when everyone’s daily experience is different.

Read more: Thin-spread teams

How to narrow it down

1. Does the team have written working agreements that everyone follows? If agreements are verbal or assumed, they will diverge under pressure. The absence of written agreements is the starting point.
2. Do team members pull from a shared queue or receive individual assignments? Individual assignment reduces team-level flow ownership. Start with Push-based work assignment.
3. Does the team enforce WIP limits? Without enforced limits, work accumulates until norms break down. Start with Unbounded WIP.

Ready to fix this? The most common cause is Push-based work assignment. Start with its How to Fix It section for week-by-week steps.

4 - The Same Mistakes Happen in the Same Domain Repeatedly

What you are seeing

A post-mortem reveals that the payments module failed in the same way it failed eighteen months ago. The fix applied then was not documented, and the developer who applied it is no longer on the team. A retrospective surfaces a proposal to split the monolith into services - a direction the team two rotations ago evaluated and rejected for reasons nobody on the current team knows.

The same conversations happen repeatedly. The same edge cases get missed. The same architectural directions get proposed, piloted, and quietly abandoned without any record of why. Each new group treats the domain as a fresh problem rather than building on what was learned before.

Common causes

Thin-Spread Teams

When engineers are rotated through a domain based on capacity rather than staying long enough to build expertise, institutional memory does not accumulate. The decisions, experiments, and hard lessons from previous rotations leave with those developers. The next group inherits the code but not the understanding of why it is structured the way it is, what was tried before, or what the failure modes are. They are likely to repeat the same exploration, reach the same dead ends, and make the same mistakes.

Read more: Thin-Spread Teams

Knowledge Silos

When knowledge about a domain lives only in specific individuals, it evaporates when they leave. Architectural decision records, runbooks, and documented post-mortem outcomes are the externalized forms of that knowledge. Without them, every departure is a partial reset. The remaining team cannot distinguish between “we haven’t tried that” and “we tried that and here is what happened.”

Read more: Knowledge Silos

How to narrow it down

1. Do post-mortems show the same root causes in the same areas of the system? If recurring incidents map to the same modules and the fixes do not persist, the team is not accumulating learning. Start with Thin-Spread Teams.
2. Are architectural proposals evaluated without knowledge of what was tried before? If the team cannot answer “was this approach considered previously, and what happened,” decisions are being made without institutional memory. Start with Knowledge Silos.

Ready to fix this? The most common cause is Knowledge Silos. Start with its How to Fix It section for week-by-week steps.

Related Content

• Team Membership Changes Constantly - Roster changes that reset accumulated knowledge
• Rotation Ramp-Up Drag - Delivery slowdown that accompanies each knowledge reset
• Domain Model Erosion - Structural degradation caused by repeated uninformed decisions
• Thin-Spread Teams - Rotation model that prevents institutional memory from forming
• Knowledge Silos - Knowledge not externalized into artifacts the next team can use

5 - Delivery Slows Every Time the Team Rotates

What you are seeing

A developer is moved onto the team because there is capacity there and they know the tech stack. For the first two to three weeks, velocity drops. Simple changes take longer than expected because the new person is learning the domain while doing the work. They ask questions that previous team members would have answered instantly. They make safe, conservative choices to avoid breaking something they don’t fully understand.

Then the rotation ends or another team member is pulled away, and the cycle starts again. The team never fully recovers its pre-rotation pace before the next disruption. Velocity measured across a quarter looks flat even though the team is working as hard as ever.

Common causes

Thin-Spread Teams

When engineers are treated as interchangeable capacity and moved to where utilization is needed, the team never develops stable domain expertise. Each rotation brings someone who knows the technology but not the business rules, the data model quirks, the historical decisions, or the failure modes that prior members learned through experience. The knowledge required to deliver quickly in a domain cannot be acquired in days. It accumulates over months of working in it.

Read more: Thin-Spread Teams

Knowledge Silos

When domain knowledge lives in individuals rather than in documentation, runbooks, and code structure, it is not available to the next person who joins. The new team member must reconstruct understanding that the previous person carried in their head. Every rotation restarts that reconstruction from scratch.

Read more: Knowledge Silos

How to narrow it down

1. Does velocity measurably drop for several weeks after a team change? If the pattern is consistent and repeatable, the team’s delivery speed depends on individual domain knowledge rather than shared, documented understanding. Start with Thin-Spread Teams.
2. Is domain knowledge written down or does it live in specific people? If new team members learn by asking colleagues rather than reading documentation, the knowledge is not externalized. Start with Knowledge Silos.

Ready to fix this? The most common cause is Thin-Spread Teams. Start with its How to Fix It section for week-by-week steps.

Related Content

• Team Membership Changes Constantly - Frequent roster changes that trigger repeated ramp-up cycles
• Blocked Work Sits Idle - Knowledge gaps that prevent anyone else from picking up stuck work
• Thin-Spread Teams - Rotation model that prevents domain expertise from accumulating
• Knowledge Silos - Domain knowledge concentrated in individuals rather than shared
• Working Agreements - Documented practices that survive team changes

6 - Team Membership Changes Constantly

What you are seeing

The team roster changes every quarter. Engineers are pulled to other projects because they have relevant expertise, or they move to new teams as part of organizational restructuring. New members join but onboarding is informal - there is no written record of how the team works, what decisions were made and why, or what the technical context is.

The CD migration effort restarts with every significant roster change. New members bring different mental models and prior experiences. Practices the team adopted with care - trunk-based development, WIP limits, short-lived branches - get questioned by each new cohort who did not experience the problems those practices were designed to solve. The team keeps relitigating settled decisions instead of making progress.

The organizational pattern treats individual contributors as interchangeable resources. An engineer with payment domain expertise can be moved to the infrastructure team because the headcount numbers work out. The cost of that move - lost context, restarted relationships, degraded team performance for months - is invisible to the planning process that made the decision.

Common causes

Knowledge silos

When knowledge lives in individuals rather than in team practices, documentation, and code, departures create immediate gaps. The cost of reassignment is higher when the departing person carries critical knowledge that was never externalized. Losing one person does not just reduce capacity by one; it can reduce effective capability by much more if that person was the only one who understood a critical system or practice.

Teams that externalize knowledge into runbooks, architectural decision records, and documented practices distribute the cost of any individual departure. No single person’s absence leaves a critical gap. When a new cohort joins, the documented decisions and rationale are already there - the team stops relitigating trunk-based development and WIP limits because the record of why those choices were made is readable, not verbal.

Read more: Knowledge silos

Unbounded WIP

Teams with too much in progress are more likely to have members pulled to other projects, because they appear to have capacity even when they are spread thin. If a developer is working on five things simultaneously, moving them to another project looks like it frees up a resource. The depth of their contribution to each item is invisible to the person making the assignment decision.

WIP limits make the team’s actual capacity visible. When each person is focused on one or two things, it is clear that they are fully engaged and that removing them would directly impact those items. The reassignments that have been disrupting the team’s CD progress become less frequent because the real cost is finally visible to whoever is making the staffing decision.

Read more: Unbounded WIP

Thin-spread teams

When a team’s members are already distributed across many responsibilities, any departure creates disproportionate impact. Thin-spread teams have no redundancy to absorb turnover. Each person’s departure leaves a hole in a different area of the team’s responsibility surface.

Teams with focused, overlapping responsibilities can absorb turnover because multiple people share each area of responsibility. Redundancy is built in rather than assumed to exist. When a member is reassigned, the team’s work continues without a collapse in that area - the constant restart cycle that has been stalling the CD migration does not recur with every roster change.

Read more: Thin-spread teams

Push-Based Work Assignment

When work is assigned by specialty - “you’re the database person, so you take the database stories” - knowledge concentrates in individuals rather than spreading across the team. The same person always works the same area, so only they understand it deeply. When that person is reassigned or leaves, no one else can continue their work without starting over. Push-based assignment continuously deepens the knowledge silos that make every roster change more disruptive.

Read more: Push-Based Work Assignment

How to narrow it down

1. Is critical system knowledge documented or does it live in specific individuals? If departures create knowledge gaps, the team has knowledge silos regardless of who leaves. Start with Knowledge silos.
2. Does the team appear to have capacity because members are spread across many items? High WIP makes team members look available for reassignment. Start with Unbounded WIP.
3. Is each team member the sole owner of a distinct area of the team’s work? If so, any departure leaves an unmanned responsibility. Start with Thin-spread teams.
4. Is work assigned by specialty so the same person always works the same area? If departures leave knowledge gaps in specific parts of the system, assignment by specialty is reinforcing the silos. Start with Push-Based Work Assignment.

Ready to fix this? The most common cause is Knowledge silos. Start with its How to Fix It section for week-by-week steps.