Team Dynamics

• 1: Thin-Spread Teams
• 2: Missing Product Ownership
• 3: Hero Culture
• 4: Blame culture after incidents
• 5: Misaligned Incentives
• 6: Outsourced Development with Handoffs
• 7: No improvement time budgeted
• 8: No On-Call or Operational Ownership
• 9: Pressure to Skip Testing

1 - Thin-Spread Teams

What This Looks Like

Ten developers are responsible for fifteen products. Each developer is the primary contact for two or three of them. When a production issue hits one product, the assigned developer drops whatever they are working on for another product and switches context. Their current work stalls. The team’s board shows progress on many things and completion of very few.

Common variations:

• The pillar model. Each developer “owns” a pillar of products. They are the only person who understands those systems. When they are unavailable, their products are frozen. When they are available, they split attention across multiple codebases daily.
• The interrupt-driven team. The team has no protected capacity. Any stakeholder can pull any developer onto any product at any time. The team’s sprint plan is a suggestion that rarely survives the first week.
• The utilization trap. Management sees ten developers and fifteen products as a staffing problem to optimize rather than a focus problem to solve. The response is to assign each developer to more products to “keep everyone busy” rather than to reduce the number of products the team owns.
• The divergent processes. Because each product evolved independently, each has different build tools, deployment processes, and conventions. Switching between products means switching mental models entirely. The cost of context switching is not just the product domain but the entire toolchain.

The telltale sign: ask any developer what they are working on, and the answer involves three products and an apology for not making more progress on any of them.

Why This Is a Problem

Spreading a team across too many products is a team topology failure. It turns every developer into a single point of failure for their assigned products while preventing the team from building shared knowledge or sustainable delivery practices.

It reduces quality

A developer who touches three codebases in a day cannot maintain deep context in any of them. They make shallow fixes rather than addressing root causes because they do not have time to understand the full system. Code reviews are superficial because the reviewer is also juggling multiple products. Defects accumulate because nobody has the sustained attention to prevent them.

A team focused on one or two products develops deep understanding. They spot patterns, catch design problems, and write code that accounts for the system’s history and constraints.

It increases rework

Context switching has a measurable cost. Research consistently shows that switching between tasks adds 20 to 40 percent overhead as the brain reloads the mental model of each project. A developer who spends an hour on Product A, two hours on Product B, and then returns to Product A has lost significant time to switching. The work they do in each window is lower quality because they never fully loaded context.

The shallow work that results from fragmented attention produces more bugs, more missed edge cases, and more rework when the problems surface later.

It makes delivery timelines unpredictable

When a developer owns three products, their availability for any one product depends on what happens with the other two. A production incident on Product B derails the sprint commitment for Product A. A stakeholder escalation on Product C pulls the developer off Product B. Delivery dates for any single product are unreliable because the developer’s time is a shared resource subject to competing demands.

A team with a focused product scope can make and keep commitments because their capacity is dedicated, not shared across unrelated priorities.

It creates single points of failure everywhere

Each developer becomes the sole expert on their assigned products. When that developer is sick, on vacation, or leaves the company, their products have nobody who understands them. The team cannot absorb the work because everyone else is already spread thin across their own products.

This is Knowledge Silos at organizational scale. Instead of one developer being the only person who knows one subsystem, every developer is the only person who knows multiple entire products.

Impact on continuous delivery

CD requires a team that can deliver any of their products at any time. Thin-spread teams cannot do this because delivery capacity for each product is tied to a single person’s availability. If that person is busy with another product, the first product’s pipeline is effectively blocked.

CD also requires investment in automation, testing, and pipeline infrastructure. A team spread across fifteen products cannot invest in improving the delivery practices for any one of them because there is no sustained focus to build momentum.

How to Fix It

Step 1: Count the real product load

List every product, service, and system the team is responsible for. Include maintenance, on-call, and operational support. For each, identify the primary and secondary contacts. Make the single-point-of-failure risks visible.

Step 2: Consolidate ownership

Work with leadership to reduce the team’s product scope. The goal is to reach a ratio where the team can maintain shared knowledge across all their products. For most teams, this means two to four products for a team of six to eight developers.

Products the team cannot focus on should be transferred to another team, put into maintenance mode with explicit reduced expectations, or retired.

Step 3: Protect focus with capacity allocation

Until the product scope is fully reduced, protect focus by allocating capacity explicitly. Dedicate specific developers to specific products for the full sprint rather than letting them split across products daily. Rotate assignments between sprints to build shared knowledge.

Reserve a percentage of capacity (20 to 30 percent) for unplanned work and production support so that interrupts do not derail the sprint plan entirely.

Step 4: Standardize tooling across products

Reduce the context-switching cost by standardizing build tools, deployment processes, and coding conventions across the team’s products. When all products use the same pipeline structure and testing patterns, switching between them requires loading only the domain context, not an entirely different toolchain.

Measuring Progress

Related Content

• Rotation Ramp-Up Drag - Delivery slowdown that repeats with every team rotation
• Repeated Domain Mistakes - Institutional memory lost with each rotation, same errors recur
• Domain Model Erosion - Codebase degraded by successive teams without domain continuity
• Slow Defect Resolution - Bugs take disproportionately long when debuggers don’t know the domain
• Team Membership Changes Constantly - Roster instability driven by treating engineers as interchangeable capacity
• Knowledge Silos - Thin-spread teams create silos at the product level, not just the subsystem level
• Unbounded WIP - Too many products is WIP at the team level
• Working Agreements - Agreements on product scope and capacity allocation
• Architecture Decoupling - Reducing coupling between products makes ownership boundaries cleaner

2 - Missing Product Ownership

What This Looks Like

The tech lead is in a stakeholder meeting negotiating scope for a feature. Thirty minutes later, they are reviewing a pull request. An hour after that, they are on a call with a different stakeholder who has a different priority. The backlog has items from five stakeholders with no clear ranking. When a developer asks “which of these should I work on first?” the tech lead guesses based on whoever was loudest most recently.

Common variations:

• The tech-lead-as-product-owner. The tech lead writes requirements, prioritizes the backlog, manages stakeholders, reviews code, and writes code. They are the bottleneck for every decision. The team waits for them constantly.
• The committee of stakeholders. Multiple business stakeholders submit requests directly to the team. Each considers their request the top priority. The team receives conflicting direction and has no authority to say no or negotiate scope.
• The requirements churn. Without someone who owns the product direction, requirements change frequently. A developer is midway through implementing a feature when the requirements shift because a different stakeholder weighed in. Work already done is discarded or reworked.
• The absent product owner. The role exists on paper, but the person is shared across multiple teams, unavailable for daily questions, or does not understand the product well enough to make decisions. The tech lead fills the gap by default.

The telltale sign: the team cannot answer “what is the most important thing to work on next?” without escalating to a meeting.

Why This Is a Problem

Product ownership is a full-time responsibility. When it is absorbed into a technical role or distributed across multiple stakeholders, the team lacks clear direction and the person filling the gap burns out from an impossible workload.

It reduces quality

A tech lead splitting time between product decisions and code review does neither well. Code reviews are rushed because the next stakeholder meeting is in ten minutes. Product decisions are uninformed because the tech lead has not had time to research the user need. The team builds features based on incomplete or shifting requirements, and the result is software that does not quite solve the problem.

A dedicated product owner can invest the time to understand user needs deeply, write clear acceptance criteria, and be available to answer questions as developers work. The resulting software is better because the requirements were better.

It increases rework

When requirements change mid-implementation, work already done is wasted. A developer who spent three days on a feature that shifts direction has three days of rework. Multiply this across the team and across sprints, and a significant portion of the team’s capacity goes to rebuilding rather than building.

Clear product ownership reduces churn because one person owns the direction and can protect the team from scope changes mid-sprint. Changes go into the backlog for the next sprint rather than disrupting work in progress.

It makes delivery timelines unpredictable

Without a single prioritized backlog, the team does not know what they are delivering next. Planning is a negotiation among competing stakeholders rather than a selection from a ranked list. The team commits to work that gets reshuffled when a louder stakeholder appears. Sprint commitments are unreliable because the commitment itself changes.

A product owner who maintains a single, ranked backlog gives the team a stable input. The team can plan, commit, and deliver with confidence because the priorities do not shift beneath them.

It burns out technical leaders

A tech lead handling product ownership, technical leadership, and individual contribution is doing three jobs. They work longer hours to keep up. They become the bottleneck for every decision. They cannot delegate because there is nobody to delegate the product work to. Over time, they either burn out and leave, or they drop one of the responsibilities silently. Usually the one that drops is their own coding or the quality of their code reviews.

Impact on continuous delivery

CD requires a team that knows what to deliver and can deliver it without waiting for decisions. When product ownership is missing, the team waits for requirements clarification, priority decisions, and scope negotiations. These waits break the flow that CD depends on. The pipeline may be technically capable of deploying continuously, but there is nothing ready to deploy because the team spent the sprint chasing shifting requirements.

How to Fix It

Step 1: Make the gap visible

Track how much time the tech lead spends on product decisions versus technical work. Track how often the team is blocked waiting for requirements clarification or priority decisions. Present this data to leadership as the cost of not having a dedicated product owner.

Step 2: Establish a single backlog with a single owner

Until a dedicated product owner is hired or assigned, designate one person as the interim backlog owner. This person has the authority to rank items and say no to new requests mid-sprint. Stakeholders submit requests to the backlog, not directly to developers.

Step 3: Shield the team from requirements churn

Adopt a rule: requirements do not change for items already in the sprint. New information goes into the backlog for next sprint. If something is truly urgent, it displaces another item of equal or greater size. The team finishes what they started.

Step 4: Advocate for a dedicated product owner

Use the data from Step 1 to make the case. Show the cost of the tech lead’s split attention in terms of missed commitments, rework from requirements churn, and delivery delays from decision bottlenecks. The cost of a dedicated product owner is almost always less than the cost of not having one.

Measuring Progress

Related Content

• Working Agreements - Establishing norms for how requirements enter the team
• Work Decomposition - Clear product ownership enables effective decomposition during refinement
• Deadline-Driven Development - Missing product ownership often coexists with arbitrary deadlines from competing stakeholders
• Velocity as Individual Metric - Without clear product direction, teams fall back on measuring output instead of outcomes

3 - Hero Culture

What This Looks Like

Every team has that one person - the one you call when the production deployment goes sideways at 11 PM, the one who knows which config file to change to fix the mysterious startup failure, the one whose vacation gets cancelled when the quarterly release hits a snag. This person is praised, rewarded, and promoted for their heroics. They are also a single point of failure quietly accumulating more irreplaceable knowledge with every incident they solo.

Hero culture is often invisible to management because it looks like high performance. The hero gets things done. Incidents resolve quickly when the hero is on call. The team ships, somehow, even when things go wrong. What management does not see is the shadow cost: the knowledge that never transfers, the other team members who stop trying to understand the hard problems because “just ask the hero,” and the compounding brittleness as the system grows more complex and more dependent on one person’s mental model.

Recognition mechanisms reinforce the pattern. Heroes get public praise for fighting fires. The engineers who write the runbook, add the monitoring, or refactor the code so fires stop starting get no comparable recognition because their work prevents the heroic moment rather than creating it. The incentive structure rewards reaction over prevention.

Common variations:

• The deployment gatekeeper. One person has the credentials, the institutional knowledge, or the unofficial authority to approve production changes. No one else knows what they check or why.
• The architecture oracle. One person understands how the system actually works. Design reviews require their attendance; decisions wait for their approval.
• The incident firefighter. The same person is paged for every P1 incident regardless of which service is affected, because they are the only one who can navigate the system quickly under pressure.

The telltale sign: there is at least one person on the team whose absence would cause a visible degradation in the team’s ability to deploy or respond to incidents.

Why This Is a Problem

When your hero is on vacation, critical deployments stall. When they leave the company, institutional knowledge leaves with them. The system appears robust because problems get solved, but the problem-solving capacity is concentrated in people rather than distributed across the team and encoded in systems.

It reduces quality

Heroes develop shortcuts. Under time pressure - and heroes are always under time pressure - the fastest path to resolution is the right one. That often means bypassing the runbook, skipping the post-change verification, applying a hot fix directly to production without going through the pipeline. Each shortcut is individually defensible. Collectively, they mean the system drifts from its documented state and the documented procedures drift from what actually works.

Other team members cannot catch these shortcuts because they do not have enough context to know what correct looks like. Code review from someone who does not understand the system they are reviewing is theater, not quality control. Heroes write code that only heroes can review, which means the code is effectively unreviewed.

The hero’s mental model also becomes a source of technical debt. Heroes build the system to match their intuitions, which may be brilliant but are undocumented. Every design decision made by someone who does not need to explain it to anyone else is a decision that will be misunderstood by everyone else who eventually touches that code.

It increases rework

When knowledge is concentrated in one person, every task that requires that knowledge creates a queue. Other team members either wait for the hero or attempt the work without full context and do it wrong, producing rework. The hero then spends time correcting the mistake - time they did not have to spare.

This dynamic is self-reinforcing. Team members who repeatedly attempt tasks and fail due to missing context stop attempting. They route everything through the hero. The hero’s queue grows. The hero becomes more indispensable. Knowledge concentrates further.

Hero culture also produces a particular kind of rework in onboarding. New team members cannot learn from documentation or from peers - they must learn from the hero, who does not have time to teach and whose explanations are compressed to the point of uselessness. New members remain unproductive for months rather than weeks, and the gap is filled by the hero doing more work.

It makes delivery timelines unpredictable

Any process that depends on one person’s availability is as predictable as that person’s calendar. When the hero is on vacation, in a time zone with a 10-hour offset, or in an all-day meeting, the team’s throughput drops. Deployments are postponed. Incidents sit unresolved. Stakeholders cannot understand why the team slows down for no apparent reason.

This unpredictability is invisible in planning because the hero’s involvement is not a scheduled task - it is an implicit dependency that only materializes when something is difficult. A feature that looks like three days of straightforward work can become a two-week effort if it requires understanding an undocumented subsystem and the hero is unavailable to explain it.

The team also cannot forecast improvement because the hero’s knowledge is not a resource that scales. Adding engineers to the team does not add capacity to the bottlenecks the hero controls.

Impact on continuous delivery

CD depends on automation and shared processes rather than individual expertise. A pipeline that requires a hero to intervene - to know which flag to set, which sequence to run steps in, which credential to use - is not automated in any meaningful sense. It is manual work dressed in pipeline clothing.

CD also requires that every team member be able to see a failing build, understand what failed, and fix it. When system knowledge is concentrated in one person, most team members cannot complete this loop. They can see the build is red; they cannot diagnose why. CD stalls at the diagnosis step and waits for the hero.

More subtly, hero culture prevents the team from building the automation that makes CD possible. Automating a process requires understanding it well enough to encode it. Heroes understand the process but have no time to automate. Other team members have time but not understanding. The gap persists.

How to Fix It

Step 1: Map knowledge concentration

Identify where single-person dependencies exist before attempting to fix them.

1. List every production system and ask: who would we call at 2 AM if this failed? If the answer is one person, document that dependency.
2. Run a “bus factor” exercise: for each critical capability, how many team members could perform it without the hero’s help? Any answer of 1 is a risk.
3. Identify the three most frequent reasons the hero is pulled in - these are the highest-priority knowledge transfer targets.
4. Ask the hero to log their interruptions for one week: every time someone asks them something, record the question and time spent.
5. Calculate the hero’s maintenance and incident time as a percentage of their total working hours.

Expect pushback and address it directly:

Step 2: Begin systematic knowledge transfer (Weeks 2-6)

1. Require pair programming or pairing on all incidents and deployments for the next sprint, with the hero as the driver and a different team member as the navigator each time.
2. Create runbooks collaboratively: after each incident, the hero and at least one other team member co-author the post-mortem and write the runbook for the class of problem, not just the instance.
3. Assign “deputy” owners for each system the hero currently owns alone. Deputies shadow the hero for two weeks, then take primary ownership with the hero as backup.
4. Add a “could someone else do this?” criterion to the definition of done. If a feature or operational change requires the hero to deploy or maintain it, it is not done.
5. Schedule explicit knowledge transfer sessions - not all-hands training, but targeted 30-minute sessions where the hero explains one specific thing to two or three team members.

Expect pushback and address it directly:

Step 3: Encode knowledge in systems instead of people (Weeks 6-12)

1. Automate the deployments the hero currently performs manually. If the hero is the only one who knows the deployment steps, that is the first automation target.
2. Add observability - logs, metrics, and alerts - to the systems only the hero currently understands. If a system cannot be diagnosed without the hero’s intuition, it needs more instrumentation.
3. Rotate the on-call schedule so every team member takes primary on-call. Start with a shadow rotation where the hero is backup before moving to independent coverage.
4. Remove the hero from informal escalation paths. When the hero gets a direct message asking about a system they are no longer the owner of, they respond with “ask the deputy owner” rather than answering.
5. Measure and celebrate knowledge distribution: track how many team members have independently resolved incidents in each system over the quarter.
6. Change recognition practices to reward documentation, runbook writing, and teaching - not just firefighting.

Expect pushback and address it directly:

Measuring Progress

Related Content

• Working agreements - define shared ownership expectations that prevent hero dependencies from forming
• Rollback - automated rollback reduces the need for a hero to manually recover from bad deployments
• Identify constraints - hero dependencies are a form of constraint; map them before attempting to resolve them
• Blame culture after incidents - hero culture and blame culture frequently co-exist and reinforce each other
• Retrospectives - use retrospectives to surface and address hero dependencies before they become critical

4 - Blame culture after incidents

What This Looks Like

A production incident occurs. The system recovers. And then the real damage begins: a meeting that starts with “who approved this change?” The person whose name is on the commit that preceded the outage is identified, questioned, and in some organizations disciplined. The post-mortem document names names. The follow-up email from leadership identifies the engineer who “caused” the incident.

The immediate effect is visible: a chastened engineer, a resolved incident, a documented timeline. The lasting effect is invisible: every engineer on that team just learned that making a mistake in production is personally dangerous. They respond rationally. They slow down code that might fail. They avoid touching systems they do not fully understand. They do not volunteer information about the near-miss they had last Tuesday. They do not try the deployment approach that might be faster but carries more risk of surfacing a latent bug.

Blame culture is often a legacy of the management model that preceded modern software practices. In manufacturing, identifying the worker who made the bad widget is meaningful because worker error is a significant cause of defects. In software, individual error accounts for a small fraction of production incidents - system complexity, unclear error states, inadequate tooling, and pressure to ship fast are the dominant causes. Blaming the individual is not only ineffective; it actively prevents the systemic analysis that would reduce the next incident.

Common variations:

• Silent blame. No formal punishment, but the engineer who “caused” the incident is subtly sidelined - fewer critical assignments, passed over for the next promotion, mentioned in hallway conversations as someone who made a costly mistake.
• Blame-shifting post-mortems. The post-mortem nominally follows a blameless format but concludes with action items owned entirely by the person most directly involved in the incident.
• Public shaming. Incident summaries distributed to stakeholders that name the engineer responsible. Often framed as “transparency” but functions as deterrence through humiliation.

The telltale sign: engineers are reluctant to disclose incidents or near-misses to management, and problems are frequently discovered by monitoring rather than by the people who caused them.

Why This Is a Problem

After a blame-heavy post-mortem, engineers stop disclosing problems early. The next incident grows larger than it needed to be because nobody surfaced the warning signs. Blame culture optimizes for the appearance of accountability while destroying the conditions needed for genuine improvement.

It reduces quality

When engineers fear consequences for mistakes, they respond in ways that reduce system quality. They write defensive code that minimizes their personal exposure rather than code that makes the right tradeoffs. They avoid refactoring systems they did not write because touching unfamiliar code creates risk of blame. They do not add the test that might expose a latent defect in someone else’s module.

Near-misses - the most valuable signal in safety engineering - disappear. An engineer who catches a potential problem before it becomes an incident has two options in a blame culture: say nothing, or surface the problem and potentially be asked why they did not catch it sooner. The rational choice in a blame culture is silence. The near-miss that would have generated a systemic fix becomes a time bomb that goes off later.

Post-mortems in blame cultures produce low-quality systemic analysis. When everyone in the room knows the goal is to identify the responsible party, the conversation stops at “the engineer deployed the wrong version” rather than continuing to “why was it possible to deploy the wrong version?” The root cause is always individual error because that is what the culture is looking for.

It increases rework

Blame culture slows the feedback loop that catches defects early. Engineers who fear blame are slow to disclose problems when they are small. A bug that would take 20 minutes to fix when first noticed takes hours to fix after it propagates. By the time the problem surfaces through monitoring or customer reports, it is significantly larger than it needed to be.

Engineers also rework around blame exposure rather than around technical correctness. A change that might be controversial - refactoring a fragile module, removing a poorly understood feature flag, consolidating duplicated infrastructure - gets deferred because the person who makes the change owns the risk of anything that goes wrong in the vicinity of their change. The rework backlog accumulates in exactly the places the team is most afraid to touch.

Onboarding is particularly costly in blame cultures. New engineers are told informally which systems to avoid and which senior engineers to consult before touching anything sensitive. They spend months navigating political rather than technical complexity. Their productivity ramp is slow, and they frequently make avoidable mistakes because they were not told about the landmines everyone else knows to step around.

It makes delivery timelines unpredictable

Fear slows delivery. Engineers who worry about blame take longer to review their own work before committing. They wait for approvals they do not technically need. They avoid the fast, small change in favor of the comprehensive, well-documented change that would be harder to blame them for. Each of these behaviors is individually rational; collectively they add days of latency to every change.

The unpredictability is compounded by the organizational dynamics blame culture creates around incident response. When an incident occurs, the time to resolution is partly technical and partly political - who is available, who is willing to own the fix, who can authorize the rollback. In a blame culture, “who will own this?” is a question with no eager volunteers. Resolution times increase.

Release schedules also suffer. A team that has experienced blame-heavy post-mortems before a major release will become extremely conservative in the weeks approaching the next major release. They stop deploying changes, reduce WIP, and wait for the release to pass before resuming normal pace. This batching behavior creates exactly the large releases that are most likely to produce incidents.

Impact on continuous delivery

CD requires frequent, small changes deployed with confidence. Confidence requires that the team can act on information - including information about mistakes - without fear of personal consequences. A team operating in a blame culture cannot build the psychological safety that CD requires.

CD also depends on fast, honest feedback. A pipeline that detects a problem and alerts the team is only valuable if the team responds to the alert immediately and openly. In a blame culture, engineers look for ways to resolve problems quietly before they escalate to visibility. That delay - the gap between detection and response - is precisely what CD is designed to minimize.

The improvement work that makes CD better over time - the retrospective that identifies a flawed process, the blameless post-mortem that finds a systemic gap, the engineer who speaks up about a near-miss before it becomes an incident - requires that people feel safe to be honest. Blame culture forecloses that safety.

How to Fix It

Step 1: Establish the blameless post-mortem as the standard

1. Read or distribute “How Complex Systems Fail” by Richard Cook and discuss as a team - it provides the conceptual foundation for why individual blame is not a useful explanation for system failures.
2. Draft a post-mortem template that explicitly prohibits naming individuals as causes. The template should ask: what conditions allowed this failure to occur, and what changes to those conditions would prevent it?
3. Conduct the next incident post-mortem publicly using the new template, with leadership participating to signal that the format has institutional backing.
4. Add a “retrospective quality check” to post-mortem reviews: if the root cause analysis concludes with a person rather than a systemic condition, the analysis is not complete.
5. Identify a senior engineer or manager who will serve as the post-mortem facilitator, responsible for redirecting blame-focused questions toward systemic analysis.

Expect pushback and address it directly:

Step 2: Change how incidents are communicated upward (Weeks 2-4)

1. Agree with leadership that incident communications will focus on impact, timeline, and systemic improvement - not on who was involved.
2. Remove names from incident reports that go to stakeholders. Identify the systems and conditions involved, not the engineers.
3. Create a “near-miss” reporting channel - a low-friction way for engineers to report close calls anonymously if needed. Track near-miss reports as a leading indicator of system health.
4. Ask leadership to visibly praise the next engineer who surfaces a near-miss or self-discloses a problem early. The public signal that transparency is rewarded, not punished, matters more than any policy document.
5. Review the last 10 post-mortems and rewrite the root cause sections using the new systemic framing as an exercise in applying the new standard.

Expect pushback and address it directly:

Step 3: Institutionalize learning from failure (Weeks 4-8)

1. Schedule a monthly “failure forum” - a safe space for engineers to share mistakes and near-misses with the explicit goal of systemic learning, not evaluation.
2. Track systemic improvements generated from post-mortems. The measure of post-mortem quality is the quality of the action items, not the quality of the root cause narrative.
3. Add to the onboarding process: walk every new engineer through a representative blameless post-mortem before they encounter their first incident.
4. Establish a policy that post-mortem action items are scheduled and prioritized in the same backlog as feature work. Systemic improvements that are never resourced signal that blameless culture is theater.
5. Revisit the on-call and alerting structure to ensure that incident response is a team activity, not a solo performance by the engineer who happened to be on call.

Expect pushback and address it directly:

Measuring Progress

Related Content

• Hero culture - blame culture and hero culture reinforce each other; heroes are often exempt from blame, everyone else is not
• Retrospectives - retrospectives that follow blameless principles build the same muscle as blameless post-mortems
• Working agreements - team norms that explicitly address how failure is handled prevent blame culture from taking hold
• Metrics-driven improvement - system-level metrics provide objective analysis that reduces the tendency to attribute outcomes to individuals
• Current state checklist - cultural safety is a prerequisite for many checklist items; assess this early

5 - Misaligned Incentives

What This Looks Like

Performance reviews ask about features delivered. OKRs are written as “ship X, Y, and Z by end of quarter.” Bonuses are tied to project completions. The team is recognized in all-hands meetings for delivering the annual release on time. Nobody is ever recognized for reducing the mean time to repair an incident. Nobody has a goal that says “increase deployment frequency from monthly to weekly.” Nobody’s review mentions the change fail rate.

The metrics that predict delivery health over time - lead time, deployment frequency, change fail rate, mean time to repair - are invisible to the incentive system. The metrics that the incentive system rewards - features shipped, deadlines met, projects completed - measure activity, not outcomes. A team can hit every OKR and still be delivering slowly, with high failure rates, into a fragile system.

The mismatch is often not intentional. The people who designed the OKRs were focused on the product roadmap. They know what features the business needs and wrote goals to get those features built. The idea of measuring how features get built - the flow, the reliability, the delivery system itself - was not part of the frame.

Common variations:

• The ops-dev split. Development is rewarded for shipping features. Operations is rewarded for system stability. These goals conflict: every feature deployment is a stability risk from operations’ perspective. The result is that operations resists deployments and development resists operational feedback. Neither team has an incentive to collaborate on making deployment safer.
• The quantity over quality trap. Velocity is tracked. Story points per sprint are reported to leadership as a productivity metric. The team maximizes story points by cutting quality. A 2-point story completed quickly beats a 5-point story done right, from a velocity standpoint. Defects show up later, in someone else’s sprint.
• The project success illusion. A project “shipped on time and on budget” is labeled a success even when the system it built is slow to change, prone to incidents, and unpopular with users. The project metrics rewarded are decoupled from the product outcomes that matter.
• The hero recognition pattern. The engineer who stays late to fix the production incident is recognized. The engineer who spent three weeks preventing the class of defects that caused the incident gets no recognition. Heroic recovery is visible and rewarded. Prevention is invisible.

The telltale sign: when asked about delivery speed or deployment frequency, the team lead says “I don’t know, that’s not one of our goals.”

Why This Is a Problem

Incentive systems define what people optimize for. When the incentive system rewards feature volume, people optimize for feature volume. When delivery health metrics are absent from the incentive system, nobody optimizes for delivery health. The organization’s actual delivery capability slowly degrades, invisibly, because no one has a reason to maintain or improve it.

It reduces quality

A developer cuts a corner on test coverage to hit the sprint deadline. The defect ships. It shows up in a different reporting period, gets attributed to operations or to a different team, and costs twice as much to fix. The developer who made the decision never sees the cost. The incentive system severs the connection between the decision to cut quality and the consequence.

Teams whose incentives include quality metrics - defect escape rate, change fail rate, production incident count - make different decisions. When a bug you introduced costs you something in your own OKR, you have a reason to write the test that prevents it. When it is invisible to your incentive system, you have no such reason.

It increases rework

A team spends four hours on manual regression testing every release. Nobody has a goal to automate it. After twelve months, that is fifty hours of repeated manual work that an automated suite would have eliminated after week two. The compounded cost dwarfs any single defect repair - but the automation investment never appears in feature-count OKRs, so it never gets prioritized.

Cutting quality to hit feature goals also produces defects fixed later at higher cost. When no one is rewarded for improving the delivery system, automation is not built, tests are not written, pipelines are not maintained. The team continuously re-does the same manual work instead of investing in automation that would eliminate it.

It makes delivery timelines unpredictable

A project closes. The team disperses to new work. Six months later, the next project starts with a codebase that has accumulated unaddressed debt and a pipeline nobody maintained. The first sprint is slower than expected. The delivery timeline slips. Nobody is surprised - but nobody is accountable either, because the gap between projects was invisible to the incentive system.

Each project delivery becomes a heroic effort because the delivery system was not kept healthy between projects. Timelines are unpredictable because the team’s actual current capability is unknown - they know what they delivered on the last project under heroic conditions, not what they can deliver routinely. Teams with continuous delivery incentives keep their systems healthy continuously and have much more reliable throughput.

Impact on continuous delivery

CD is fundamentally about optimizing the delivery system, not just the products the system produces. The four key metrics - deployment frequency, lead time, change fail rate, mean time to repair - are measurements of the delivery system’s health. If none of these metrics appear in anyone’s performance review, OKR, or team goal, there is no organizational will to improve them.

A CD adoption initiative that does not address the incentive system is building against the gradient. Engineers are being asked to invest time improving the deployment pipeline, writing better tests, and reducing batch sizes - investments that do not produce features. If those engineers are measured on features, every hour spent on pipeline work is an hour they are failing their OKR. The adoption effort will stall because the incentive system is working against it.

How to Fix It

Step 1: Audit current metrics and OKRs against delivery health

List all current team-level metrics, OKRs, and performance criteria. Mark each one: does it measure features/output, or does it measure delivery system health? In most organizations, the list will be almost entirely output measures. Making this visible is the first step - it is hard to argue for change when people do not see the gap.

Step 2: Propose adding one delivery health metric per team (Weeks 2-3)

Do not attempt to overhaul the entire incentive system at once. Propose adding one delivery health metric to each team’s OKRs. Good starting options:

• Deployment frequency: how often does the team deploy to production?
• Lead time: how long from code committed to running in production?
• Change fail rate: what percentage of deployments require a rollback or hotfix?

Even one metric creates a reason to discuss delivery system health in planning and review conversations. It legitimizes the investment of time in CD improvement work.

Step 3: Make prevention visible alongside recovery (Weeks 2-4)

Change recognition patterns. When the on-call engineer’s fix is recognized in a team meeting, also recognize the engineer who spent time the previous week improving test coverage in the area that failed. When a deployment goes smoothly because a developer took care to add deployment verification, note it explicitly. Visible recognition of prevention behavior - not just heroic recovery - changes the cost-benefit calculation for investing in quality.

Step 4: Align operations and development incentives (Weeks 4-8)

If development and operations are separate teams with separate OKRs, introduce a shared metric that both teams own. Change fail rate is a good candidate: development owns the change quality, operations owns the deployment process, both affect the outcome. A shared metric creates a reason to collaborate rather than negotiate.

Step 5: Include delivery system health in planning conversations (Ongoing)

Every planning cycle, include a review of delivery health metrics alongside product metrics. “Our deployment frequency is monthly; we want it to be weekly” should have the same status in a planning conversation as “we want to ship Feature X by Q2.” This frames delivery system improvement as legitimate work, not as optional infrastructure overhead.

Measuring Progress

Related Content

• Deadline-Driven Development - Deadline incentives are a specific form of misaligned incentives
• Velocity as Individual Metric - Using velocity as a performance metric creates its own misalignment
• Metrics-Driven Improvement - Building the case for delivery health metrics
• Baseline Metrics - Establishing current delivery health as a foundation for improvement goals
• Retrospectives - The forum for surfacing incentive misalignment and proposing change

6 - Outsourced Development with Handoffs

What This Looks Like

A feature is developed by an offshore team that works in a different time zone. When the code is complete, a build is packaged and handed to a separate QA team, who test against a documented requirements list. The QA team finds defects and files tickets. The offshore team receives the tickets the next morning, fixes the defects, and sends another build. After QA signs off, a deployment request is submitted to the operations team. Operations schedules the deployment for the next maintenance window.

From “code complete” to “feature in production” is three weeks. In those three weeks, the developer who wrote the code has moved on to the next feature. The QA engineer testing the code never met the developer and does not know why certain design decisions were made. The operations engineer deploying the code has never seen the application before.

Each handoff has a communication cost, a delay cost, and a context cost. The communication cost is the effort of documenting what is being passed and why. The delay cost is the latency between the handoff and the next person picking up the work. The context cost is what is lost in the transfer - the knowledge that lives in the developer’s head and does not make it into any artifact.

Common variations:

• The time zone gap. Development and testing are in different time zones. A question from QA arrives at 3pm local time. The developer sees it at 9am the next day. The answer enables a fix that goes to QA the following day. A two-minute conversation took 48 hours.
• The contract boundary. The outsourced team is contractually defined. They deliver to a specification. They are not empowered to question the specification or surface ambiguity. Problems discovered during development are documented and passed back through a formal change request process.
• The test team queue. The QA team operates a queue. Work enters the queue when development finishes. The queue has a service level of five business days. All work waits in the queue regardless of urgency.
• The operations firewall. The development and test organizations are not permitted to deploy to production. Only a separate operations team has production access. All deployments require a deployment request document, a change ticket, and a scheduled maintenance window.
• The specification waterfall. Requirements are written by a business analyst team, handed to development, then to QA, then to operations. By the time operations deploys, the requirements document is four months old and several things have changed, but the document has not been updated.

The telltale sign: when a production defect is discovered, tracking down the person who wrote the code requires a trail of tickets across three organizations, and that person no longer remembers the relevant context.

Why This Is a Problem

A bug found in production gets routed to a ticket queue. By the time it reaches the developer who wrote the code, the context is gone and the fix takes three times as long as it would have taken when the code was fresh. That delay is baked into every defect, every clarification, every deployment in a multi-team handoff model.

It reduces quality

A defect found in the hour after the code was written is fixed in minutes with full context. The same defect found by a separate QA team a week later requires reconstructing context, writing a reproduction case, and waiting for the developer to return to code they no longer remember clearly. The quality of the fix suffers because the context has degraded - and the cost is paid on every defect, across every handoff.

When testing is done by a separate team, the developer’s understanding of the code is lost. QA engineers test against written requirements, which describe what was intended but not why specific implementation decisions were made. Edge cases that the developer would recognize are tested by people who do not have the developer’s mental model of the system.

Teams where developers test their own work - and where testing is automated and runs continuously - catch a higher proportion of defects earlier. The person closest to the code is also the person best positioned to test it thoroughly.

It increases rework

QA files a defect. The developer reviews it and responds that the code matches the specification. QA disagrees. Both are right. The specification was ambiguous. Resolving the disagreement requires going back to the original requirements, which may themselves be ambiguous. The round trip from QA report to developer response to QA acceptance takes days - and the feature was not actually broken, just misunderstood.

These misunderstanding defects multiply wherever the specification is the only link between two teams that never spoke directly. The QA team tests against what was intended; the developer implemented what they understood. The gap between those two things is rework.

The operations handoff creates its own rework. Deployment instructions written by someone who did not build the system are often incomplete. The operations engineer encounters something not covered in the deployment guide, must contact the developer for clarification, and the deployment is delayed. In the worst case, the deployment fails and must be rolled back, requiring another round of documentation and scheduling.

It makes delivery timelines unpredictable

A feature takes one week to develop and two days to test. It spends three weeks in queues. The developer can estimate the development time. They cannot estimate how long the QA queue will be three weeks from now, or when the next operations maintenance window will be scheduled. The delivery date is hostage to a series of handoff delays that compound in unpredictable ways.

Queue times are the majority of elapsed time in most outsourced handoff models - often 60-80% of total time - and they are largely outside the development team’s control. Forecasting is guessing at queue depths, not estimating actual work.

Impact on continuous delivery

CD requires a team that owns the full delivery path: from code to production. Multi-team handoff models fragment this ownership deliberately. The developer is responsible for code correctness. QA is responsible for verified functionality. Operations is responsible for production stability. No one is responsible for the whole.

CD practices - automated testing, deployment pipelines, continuous integration - require investment and iteration. With fragmented ownership, nobody has both the knowledge and the authority to invest in the pipeline. The development team knows what tests would be valuable but does not control the test environment. The operations team controls the deployment process but does not know the application well enough to automate its deployment safely. The gap between the two is where CD improvement efforts go to die.

How to Fix It

Step 1: Map the current handoffs and their costs

Draw the current flow from development complete to production deployed. For each handoff, record the average wait time (time in queue) and the average active processing time. Calculate what percentage of total elapsed time is queue time versus actual work time. In most outsourced multi-team models, queue time is 60-80% of total time. Making this visible creates the business case for reducing handoffs.

Step 2: Embed testing earlier in the development process (Weeks 2-4)

The highest-value handoff to eliminate is the gap between development and testing. Two paths forward:

Option A: Shift testing left. Work with the QA team to have a QA engineer participate in development rather than receive a finished build. The QA engineer writes acceptance test cases before development starts; the developer implements against those cases. When development is complete, testing is complete, because the tests ran continuously during development.

Option B: Automate the regression layer. Work with the development team to build an automated regression suite that runs in the pipeline. The QA team’s role shifts from executing repetitive tests to designing test strategies and exploratory testing.

Both options reduce the handoff delay without eliminating the QA function.

Step 3: Create a deployment pipeline that the development team owns (Weeks 3-6)

Negotiate with the operations team for the development team to own deployments to non-production environments. Production deployment can remain with operations initially, but the deployment process should be automated so that operations is executing a pipeline, not manually following a deployment runbook. This removes the manual operations bottleneck while preserving the access control that operations legitimately owns.

Step 4: Introduce a shared responsibility model for production (Weeks 6-12)

The goal is a model where the team that builds the service has a defined role in running it. This does not require eliminating the operations team - it requires redefining the boundary. A starting position: the development team is on call for application-level incidents. The operations team is on call for infrastructure-level incidents. Both teams are in the same incident channel. The development team gets paged when their service has a production problem. This feedback loop is the foundation of operational quality.

Step 5: Renegotiate contract or team structures based on evidence (Months 3-6)

After generating evidence that reduced-handoff delivery produces better quality and shorter lead times, use that evidence to renegotiate. If the current model involves a contracted outsourced team, propose expanding their scope to include testing, or propose bringing automated pipeline work in-house while keeping feature development outsourced. The goal is to align contract boundaries with value delivery rather than functional specialization.

Measuring Progress

Related Content

• Single Path to Production - The pipeline model that replaces multi-team handoff chains
• Testing Fundamentals - Building the automated test layer that replaces manual QA handoffs
• Production-Like Environments - Reducing the gap between test and production that creates late defect discovery
• No On-Call or Operational Ownership - The related pattern where the team that builds does not run
• Value Stream Mapping - Visualizing the handoff delays in the current delivery process

7 - No improvement time budgeted

What This Looks Like

The sprint planning meeting begins. The product manager presents the list of features and fixes that need to be delivered this sprint. The team estimates them. They fill to capacity. Someone mentions the flaky test suite that takes 45 minutes to run and fails 20% of the time for non-code reasons. “We’ll get to that,” someone says. It goes on the backlog. The backlog item is a year old.

This is the feature treadmill: a delivery system where the only work that gets done is work that produces a demo-able feature or resolves a visible customer complaint. Infrastructure improvements, test automation, pipeline maintenance, technical debt reduction, and process improvement are perpetually deprioritized because they do not produce something a product manager can put in a release note. The team runs at 100% utilization, feels busy all the time, and makes very little actual progress on delivery capability.

The treadmill is self-reinforcing. The slow, flaky test suite means developers do not run tests locally, which means more defects reach CI, which means more time diagnosing test failures. The manual deployment process means deploying is risky and infrequent, which means releases are large, which means releases are risky, which means more incidents, which means more firefighting, which means less time for improvement. Every hour not invested in improvement adds to the cost of the next hour of feature development.

Common variations:

• Improvement as a separate team’s job. A “DevOps” or “platform” team owns all infrastructure and tooling work. Development teams never invest in their own pipeline because it is “not their job.” The platform team is perpetually backlogged.
• Improvement only after a crisis. The team addresses technical debt and pipeline problems only after a production incident or a missed deadline makes the cost visible. Improvement is reactive, not systematic.
• Improvement in a separate quarter. The organization plans one quarter per year for “technical work.” The quarter arrives, gets partially displaced by pressing features, and provides a fraction of the capacity needed to address accumulating debt.

The telltale sign: the team can identify specific improvements that would meaningfully accelerate delivery but cannot point to any sprint in the last three months where those improvements were prioritized.

Why This Is a Problem

The test suite that takes 45 minutes and fails 20% of the time for non-code reasons costs each developer hours of wasted time every week - time that compounds sprint after sprint because the fix was never prioritized. A team operating at 100% utilization has zero capacity to improve. Every hour spent on features at the expense of improvement is an hour that makes the next hour of feature development slower.

It reduces quality

Without time for test automation, tests remain manual or absent. Manual tests are slower, less reliable, and cover less of the codebase than automated ones. Defect escape rates - the percentage of bugs that reach production - stay high because the coverage that would catch them does not exist.

Without time for pipeline improvement, the pipeline remains slow and unreliable. A slow pipeline means developers commit infrequently to avoid long wait times for feedback. Infrequent commits mean larger diffs. Larger diffs mean harder reviews. Harder reviews mean more missed issues. The causal chain from “we don’t have time to improve the pipeline” to “we have more defects in production” is real, but each step is separated from the others by enough distance that management does not perceive the connection.

Without time for refactoring, code quality degrades over time. Features added to a deteriorating codebase are harder to add correctly and take longer to test. The velocity that looks stable in the sprint metrics is actually declining in real terms as the code becomes harder to work with.

It increases rework

Technical debt is deferred maintenance. Like physical maintenance, deferred technical maintenance does not disappear - it accumulates interest. A test suite that takes 45 minutes to run and is not fixed this sprint will still be 45 minutes next sprint, and the sprint after that, but will have caused 45 minutes of wasted developer time each sprint. Across a team of 8 developers running tests twice per day for six months, that is hundreds of hours of wasted time - far more than the time it would have taken to fix the test suite.

Infrastructure problems that are not addressed compound in the same way. A deployment process that requires three manual steps does not become safer over time - it becomes riskier, because the system around it changes while the manual steps do not. The steps that were accurate documentation 18 months ago are now partially wrong, but no one has updated them because no one had time.

Feature work built on a deteriorating foundation requires more rework per feature. Developers who do not understand the codebase well - because it was never refactored to maintain clarity - make assumptions that are wrong, produce code that must be reworked, and create tests that are brittle because the underlying code is brittle.

It makes delivery timelines unpredictable

A team that does not invest in improvement is flying with degrading instruments. The test suite was reliable six months ago; now it is flaky. The build was fast last year; now it takes 35 minutes. The deployment runbook was accurate 18 months ago; now it is a starting point that requires improvisation. Each degradation adds unpredictability to delivery.

The compounding effect means that improvement debt is not linear. A team that defers improvement for two years does not just have twice the problems of a team that deferred for one year - they have a codebase that is harder to change, a pipeline that is harder to fix, and a set of habits that resist improvement. The capacity needed to escape the treadmill grows over time.

Unpredictability frustrates stakeholders and erodes trust. When the team cannot reliably forecast delivery timelines because their own systems are unpredictable, the credibility of every estimate suffers. The response is often more process - more planning, more status meetings, more checkpoints - which consumes more of the time that could go toward improvement.

Impact on continuous delivery

CD requires a reliable, fast pipeline and a codebase that can be changed safely and quickly. Both require ongoing investment to maintain. A pipeline that is not continuously improved becomes slower, less reliable, and harder to operate. A codebase that is not refactored becomes harder to test, slower to understand, and more expensive to change.

The teams that achieve and sustain CD are not the ones that got lucky with an easy codebase. They are the ones that treat pipeline and codebase quality as continuous investments, budgeted explicitly in every sprint, and protected from displacement by feature pressure. CD is a capability that must be built and maintained, not a state you arrive at once.

Teams that allocate zero time to improvement typically never begin the CD journey, or begin it and stall when the initial improvements erode under feature pressure.

How to Fix It

Step 1: Quantify the cost of not improving

Management will not protect improvement time without evidence that the current approach is expensive. Build the business case.

1. Measure the time your team spends per sprint on activities that are symptoms of deferred improvement: waiting for slow builds, diagnosing flaky tests, executing manual deployment steps, triaging recurring bugs.
2. Estimate the time investment required to address the top three items on your improvement backlog. Compare this to the recurring cost calculated above.
3. Identify one improvement item that would pay back its investment in under one sprint cycle - a quick win that demonstrates the return on improvement investment.
4. Calculate your deployment lead time and change fail rate. Poor performance on these metrics is a consequence of deferred improvement; use them to make the cost visible to management.
5. Present the findings as a business case: “We are spending X hours per sprint on symptoms of deferred debt. Addressing the top three items would cost Y hours over Z sprints. The payback period is W sprints.”

Expect pushback and address it directly:

Step 2: Protect a regular improvement allocation (Weeks 2-4)

1. Negotiate a standing allocation of improvement time: the standard recommendation is 20% of team capacity per sprint, but even 10% is better than zero. This is not a one-time improvement sprint - it is a permanent budget.
2. Add improvement items to the sprint backlog alongside features with the same status as user stories: estimated, prioritized, owned, and reviewed at the sprint retrospective.
3. Define “improvement” broadly: test automation, pipeline speed, dependency updates, refactoring, runbook creation, monitoring improvements, and process changes all qualify. Do not restrict it to infrastructure.
4. Establish a rule: improvement items are not displaced by feature work within the sprint. If a feature takes longer than estimated, the feature scope is reduced, not the improvement allocation.
5. Track the improvement allocation as a sprint metric alongside velocity and report it to stakeholders with the same regularity as feature delivery.

Expect pushback and address it directly:

Step 3: Make improvement outcomes visible and accountable (Weeks 4-8)

1. Set quarterly improvement goals with measurable outcomes: “Test suite run time below 10 minutes,” “Zero manual deployment steps for service X,” “Change fail rate below 5%.”
2. Report pipeline and delivery metrics to stakeholders monthly: build duration, change fail rate, deployment frequency. Make the connection between improvement investment and metric improvement explicit.
3. Celebrate improvement outcomes with the same visibility as feature deliveries. A presentation that shows the team cut build time from 35 minutes to 8 minutes is worth as much as a feature demo.
4. Include improvement capacity as a non-negotiable in project scoping conversations. When a new initiative is estimated, the improvement allocation is part of the team’s effective capacity, not an overhead to be cut.
5. Conduct a quarterly improvement retrospective: what did we address this quarter, what was the measured impact, and what are the highest-priority items for next quarter?
6. Make the improvement backlog visible to leadership: a ranked list with estimated cost and projected benefit for each item provides the transparency that builds trust in the prioritization.

Expect pushback and address it directly:

Measuring Progress

Related Content

• Metrics-driven improvement - use delivery metrics to identify where improvement investment has the highest return
• Retrospectives - retrospectives are the forum where improvement items should be identified and prioritized
• Identify constraints - finding the highest-leverage improvement targets requires identifying the constraint that limits throughput
• Testing fundamentals - test automation is one of the first improvement investments that pays back quickly
• Working agreements - defining the improvement allocation in team working agreements protects it from sprint-by-sprint negotiation

8 - No On-Call or Operational Ownership

What This Looks Like

The development team builds a service and hands it to operations when it is “ready for production.” From that point, operations owns it. When the service has an incident, the operations team is paged. They investigate, apply workarounds, and open tickets for anything requiring code changes. Those tickets go into the development team’s backlog. The development team triages them during sprint planning, assigns them a priority, and schedules them for a future sprint.

The developer who wrote the code that caused the incident is not involved in the middle-of-the-night recovery. They find out about the incident when the ticket arrives in their queue, often days later. By then, the immediate context is gone. The incident report describes the symptom but not the root cause. The developer fixes what the ticket describes, which may or may not be the actual underlying problem.

The operations team, meanwhile, is maintaining a growing portfolio of services, none of which they built. They understand the infrastructure but not the application logic. When the service behaves unexpectedly, they have limited ability to distinguish a configuration problem from a code defect. They escalate to development, who has no operational context. Neither team has the full picture.

Common variations:

• The “thrown over the wall” deployment. The development team writes deployment documentation and hands it to operations. The documentation was accurate at the time of writing; the service has since changed in ways that were not reflected in the documentation. Operations deploys based on stale instructions.
• The black-box service. The service has no meaningful logging, no metrics exposed, and no health endpoints. Operations cannot distinguish “running correctly” from “running incorrectly” without generating test traffic. When an incident occurs, the only signal is a user complaint.
• The ticket queue gap. A production incident opens a ticket. The ticket enters the development team’s backlog. The backlog is triaged weekly. The incident recurs three more times before the fix is prioritized, because the ticket does not communicate severity in a way that interrupts the sprint.
• The “not our problem” boundary. A performance regression is attributed to the infrastructure by development and to the application by operations. Each team’s position is technically defensible. Nobody is accountable for the user-visible outcome, which is that the service is slow and nobody is fixing it.

The telltale sign: when asked “who is responsible if this service has an outage at 2am?” there is either silence or an answer that refers to a team that did not build the service and does not understand its code.

Why This Is a Problem

Operational ownership is a feedback loop. When the team that builds a service is also responsible for running it, every production problem becomes information that improves the next decision about what to build, how to test it, and how to deploy it. When that feedback loop is severed, the signal disappears into a ticket queue and the learning never happens.

It reduces quality

A developer adds a third-party API call without a circuit breaker. The 3am pager alert goes to operations, not to the developer. The developer finds out about the outage when a ticket arrives days later, stripped of context, describing a symptom but not a cause. The circuit breaker never gets added because the developer who could add it never felt the cost of its absence.

When developers are on call for their own services, that changes. The circuit breaker gets added because the developer knows from experience what happens without it. The memory leak gets fixed permanently because the developer was awakened at 2am to restart the service. Consequences that are immediate and personal produce quality that abstract code review cannot.

It increases rework

The service crashes. Operations restarts it. A ticket is filed: “service crashed; restarted; running again.” The development team closes it as “operations-resolved” without investigating why. The service crashes again the following week. Operations restarts it. Another ticket is filed. This cycle repeats until the pattern becomes obvious enough to force a root-cause investigation - by which point users have been affected multiple times and operations has spent hours on a problem that a proper first investigation would have closed.

The root cause is never identified without the developer who wrote the code. Without operational feedback reaching that developer, problems are fixed by symptom and the underlying defect stays in production.

It makes delivery timelines unpredictable

A critical bug surfaces at midnight. Operations opens a ticket. The developer who can fix it does not see it until the next business day - and then has to drop current work, context-switch into code they may not have touched in weeks, and diagnose the problem from an incident report written by someone who does not know the application. By the time the fix ships, half a sprint is gone.

This unplanned work arrives without warning and at unpredictable intervals. Every significant production incident is a sprint disruption. Teams without operational ownership cannot plan their sprints reliably because they cannot predict how much of the sprint will be consumed by emergency responses to production problems in services they no longer actively maintain.

Impact on continuous delivery

CD requires that the team deploying code has both the authority and the accountability to ensure it works in production. The deployment pipeline - automated testing, deployment verification, health checks - is only as valuable as the feedback it provides. When the team that deployed the code does not receive the feedback from production, the pipeline is not producing the learning it was designed to produce.

CD also depends on a culture where production problems are treated as design feedback. “The service went down because the retry logic was wrong” is design information that should change how the next service’s retry logic is written. When that information lands in an operations team rather than in the development team that wrote the retry logic, the design doesn’t change. The next service is written with the same flaw.

How to Fix It

Step 1: Instrument the current services for observability (Weeks 1-3)

Before changing any ownership model, make production behavior visible to the development team. Add structured logging with a correlation ID that traces requests through the system. Add metrics for the key service-level indicators: request rate, error rate, latency distribution, and resource utilization. Add health endpoints that reflect the service’s actual operational state. The development team needs to see what the service is doing in production before they can be meaningfully accountable for it.

Step 2: Give the development team read access to production telemetry

The development team should be able to query production logs and metrics without filing a request or involving operations. This is the minimum viable feedback loop: the team can see what is happening in the system they built. Even if they are not yet on call, direct access to production observability changes the development team’s relationship to production behavior.

Step 3: Introduce a rotating “production week” responsibility (Weeks 3-6)

Before full on-call rotation, introduce a gentler entry point: one developer per week is the designated production liaison. They monitor the service during business hours, triage incoming incident tickets from operations, and investigate root causes. They are the first point of contact when operations escalates. This builds the team’s operational knowledge without immediately adding after-hours pager responsibility.

Step 4: Establish a joint incident response practice (Weeks 4-8)

For the next three significant incidents, require both the development team’s production-week rotation and the operations team’s on-call engineer to work the incident together. The goal is mutual knowledge transfer: operations learns how the application behaves, development learns what operations sees during an incident. Write joint runbooks that capture both operational response steps and development-level investigation steps.

Step 5: Transfer on-call ownership incrementally (Months 2-4)

Once the development team has operational context - observability tooling, runbooks, incident experience - formalize on-call rotation. The development team is paged for application-level incidents (errors, performance regressions, business logic failures). The operations team is paged for infrastructure-level incidents (hardware, network, platform). Both teams are in the same incident channel. The boundary is explicit and agreed upon.

Step 6: Close the feedback loop into development practice (Ongoing)

Every significant production incident should produce at least one change to the development process: a new automated test that would have caught the defect, an improvement to the deployment health check, a metric added to the dashboard. This is the core feedback loop that operational ownership is designed to enable. Track the connection between incidents and development practice improvements explicitly.

Measuring Progress

Related Content

• Blind Operations - The observability gap that makes operational ownership impossible to exercise effectively
• Outsourced Development with Handoffs - The related pattern of separating builders from operators
• Production-Like Environments - Environments that surface operational problems before production does
• Deploy on Demand - The end state where the team owns the full delivery path including production
• Retrospectives - The forum for converting production incidents into development process improvements

9 - Pressure to Skip Testing

What This Looks Like

A deadline is approaching. The manager asks the team how things are going. A developer says the feature is done but the tests still need to be written. The manager says “we’ll come back to the tests after the release.” The tests are never written. Next sprint, the same thing happens. After a few months, the team has a codebase with patches of coverage surrounded by growing deserts of untested code.

Nobody made a deliberate decision to abandon testing. It happened one shortcut at a time, each one justified by a deadline that felt more urgent than the test suite.

Common variations:

• “Tests are a nice-to-have.” The team treats test writing as optional scope that gets cut when time is short. Features are estimated without testing time. Tests are a separate backlog item that never reaches the top.
• “We’ll add tests in the hardening sprint.” Testing is deferred to a future sprint dedicated to quality. That sprint gets postponed, shortened, or filled with the next round of urgent features. The testing debt compounds.
• “Just get it out the door.” A manager or product owner explicitly tells developers to skip tests for a specific release. The implicit message is that shipping matters and quality does not. Developers who push back are seen as slow or uncooperative.
• The coverage ratchet in reverse. The team once had 70% test coverage. Each sprint, a few untested changes slip through. Coverage drops to 60%, then 50%, then 40%. Nobody notices the trend because each individual drop is small. By the time someone looks at the number, half the safety net is gone.
• Testing theater. Developers write the minimum tests needed to pass a coverage gate - trivial assertions, tests that verify getters and setters, tests that do not actually exercise meaningful behavior. The coverage number looks healthy but the tests catch nothing.

The telltale sign: the team has a backlog of “write tests for X” tickets that are months old and have never been started, while production incidents keep increasing.

Why This Is a Problem

Skipping tests feels like it saves time in the moment. It does not. It borrows time from the future at a steep interest rate. The effects are invisible at first and catastrophic later.

It reduces quality

Every untested change is a change that nobody can verify automatically. The first few skipped tests are low risk - the code is fresh in the developer’s mind and unlikely to break. But as weeks pass, the untested code is modified by other developers who do not know the original intent. Without tests to pin the behavior, regressions creep in undetected.

The damage accelerates. When half the codebase is untested, developers cannot tell which changes are safe and which are risky. They treat every change as potentially dangerous, which slows them down. Or they treat every change as probably fine, which lets bugs through. Either way, quality suffers.

Teams that maintain their test suite catch regressions within minutes of introducing them. The developer who caused the regression fixes it immediately because they are still working on the relevant code. The cost of the fix is minutes, not days.

It increases rework

Untested code generates rework in two forms. First, bugs that would have been caught by tests reach production and must be investigated, diagnosed, and fixed under pressure. A bug found by a test costs minutes to fix. The same bug found in production costs hours - plus the cost of the incident response, the rollback or hotfix, and the customer impact.

Second, developers working in untested areas of the codebase move slowly because they have no safety net. They make a change, manually verify it, discover it broke something else, revert, try again. Work that should take an hour takes a day because every change requires manual verification.

The rework is invisible in sprint metrics. The team does not track “time spent debugging issues that tests would have caught.” But it shows up in velocity: the team ships less and less each sprint even as they work longer hours.

It makes delivery timelines unpredictable

When the test suite is healthy, the time from “code complete” to “deployed” is a known quantity. The pipeline runs, tests pass, the change ships. When the test suite has been hollowed out by months of skipped tests, that step becomes unpredictable. Some changes pass cleanly. Others trigger production incidents that take days to resolve.

The manager who pressured the team to skip tests in order to hit a deadline ends up with less predictable timelines, not more. Each skipped test is a small increase in the probability that a future change will cause an unexpected failure. Over months, the cumulative probability climbs until production incidents become a regular occurrence rather than an exception.

Teams with comprehensive test suites deliver predictably because the automated checks eliminate the largest source of variance - undetected defects.

It creates a death spiral

The most dangerous aspect of this anti-pattern is that it is self-reinforcing. Skipping tests leads to more bugs. More bugs lead to more time spent firefighting. More time firefighting means less time for testing. Less testing means more bugs. The cycle accelerates.

At the same time, the codebase becomes harder to test. Code written without tests in mind tends to be tightly coupled, dependent on global state, and difficult to isolate. The longer testing is deferred, the more expensive it becomes to add tests later. The team’s estimate for “catching up on testing” grows from days to weeks to months, making it even less likely that management will allocate the time.

Eventually, the team reaches a state where the test suite is so degraded that it provides no confidence. The team is effectively back to manual testing only but with the added burden of maintaining a broken test infrastructure that nobody trusts.

Impact on continuous delivery

Continuous delivery requires automated quality gates that the team can rely on. A test suite that has been eroded by months of skipped tests is not a quality gate - it is a gate with widening holes. Changes pass through it not because they are safe but because the tests that would have caught the problems were never written.

A team cannot deploy continuously if they cannot verify continuously. When the manager says “skip the tests, we need to ship,” they are not just deferring quality work. They are dismantling the infrastructure that makes frequent, safe deployment possible.

How to Fix It

Step 1: Make the cost visible

The pressure to skip tests comes from a belief that testing is overhead rather than investment. Change that belief with data:

1. Count production incidents in the last 90 days. For each one, identify whether an automated test could have caught it. Calculate the total hours spent on incident response.
2. Measure the team’s change fail rate - the percentage of deployments that cause a failure or require a rollback.
3. Track how long manual verification takes per release. Sum the hours across the team.

Present these numbers to the manager applying pressure. Frame it concretely: “We spent 40 hours on incident response last quarter. Thirty of those incidents would have been caught by tests that we skipped.”

Step 2: Include testing in every estimate

Stop treating tests as separate work items that can be deferred:

1. Agree as a team: no story is “done” until it has automated tests. This is a working agreement, not a suggestion.
2. Include testing time in every estimate. If a feature takes three days to build, the estimate is three days - including tests. Testing is not additive; it is part of building the feature.
3. Stop creating separate “write tests” tickets. Tests are part of the story, not a follow-up task.

When a manager asks “can we skip the tests to ship faster?” the answer is “the tests are part of shipping. Skipping them means the feature is not done.”

Step 3: Set a coverage floor and enforce it

Prevent further erosion with an automated guardrail:

1. Measure current test coverage. Whatever it is - 30%, 50%, 70% - that is the floor.
2. Configure the pipeline to fail if a change reduces coverage below the floor.
3. Ratchet the floor up by 1-2 percentage points each month.

The floor makes the cost of skipping tests immediate and visible. A developer who skips tests will see the pipeline fail. The conversation shifts from “we’ll add tests later” to “the pipeline won’t let us merge without tests.”

Step 4: Recover coverage in high-risk areas (Weeks 3-6)

You cannot test everything retroactively. Prioritize the areas that matter most:

1. Use version control history to find the files with the most changes and the most bug fixes. These are the highest-risk areas.
2. For each high-risk file, write tests for the core behavior - the functions that other code depends on.
3. Allocate a fixed percentage of each sprint (e.g., 20%) to writing tests for existing code. This is not optional and not deferrable.

Step 5: Address the management pressure directly (Ongoing)

The root cause is a manager who sees testing as optional. This requires a direct conversation:

If the manager continues to apply pressure after seeing the data, escalate. Test suite erosion is a technical risk that affects the entire organization’s ability to deliver. It is appropriate to raise it with engineering leadership.

Measuring Progress

Related Content

• Testing Fundamentals - Building a test strategy that becomes part of how the team works
• Working Agreements - Making “done includes tests” an explicit team agreement
• Manual Testing Only - Where this anti-pattern ends up if left unchecked
• Flaky Tests - Another way trust in the test suite erodes
• Metrics-Driven Improvement - Using data to make the case for quality practices
• ACD - How ACD counters this anti-pattern by making test-first workflow mandatory