Organizational and Cultural

• 1: Change Advisory Board Gates
• 2: Pressure to Skip Testing

1 - Change Advisory Board Gates

What This Looks Like

Before any change can reach production, it must be submitted to the Change Advisory Board. The developer fills out a change request form: description of the change, impact assessment, rollback plan, testing evidence, and approval signatures. The form goes into a queue. The CAB meets once a week - sometimes every two weeks - to review the queue. Each change gets a few minutes of discussion. The board approves, rejects, or requests more information.

A one-line configuration fix that a developer finished on Monday waits until Thursday’s CAB meeting. If the board asks a question, the change waits until the next meeting. A two-line bug fix sits in the same queue as a database migration, reviewed by the same people with the same ceremony.

Common variations:

• The rubber-stamp CAB. The board approves everything. Nobody reads the change requests carefully because the volume is too high and the context is too shallow. The meeting exists to satisfy an audit requirement, not to catch problems. It adds delay without adding safety.
• The bottleneck approver. One person on the CAB must approve every change. That person is in six other meetings, has 40 pending reviews, and is on vacation next week. Deployments stop when they are unavailable.
• The emergency change process. Urgent fixes bypass the CAB through an “emergency change” procedure that requires director-level approval and a post-hoc review. The emergency process is faster, so teams learn to label everything urgent. The CAB process is for scheduled changes, and fewer changes are scheduled.
• The change freeze. Certain periods - end of quarter, major events, holidays - are declared change-free zones. No production changes for days or weeks. Changes pile up during the freeze and deploy in a large batch afterward, which is exactly the high-risk event the freeze was meant to prevent.
• The form-driven process. The change request template has 15 fields, most of which are irrelevant for small changes. Developers spend more time filling out the form than making the change. Some fields require information the developer does not have, so they make something up.

The telltale sign: a developer finishes a change and says “now I need to submit it to the CAB” with the same tone they would use for “now I need to go to the dentist.”

Why This Is a Problem

CAB gates exist to reduce risk. In practice, they increase risk by creating delay, encouraging batching, and providing a false sense of security. The review is too shallow to catch real problems and too slow to enable fast delivery.

It reduces quality

A CAB review is a review by people who did not write the code, did not test it, and often do not understand the system it affects. A board member scanning a change request form for five minutes cannot assess the quality of a code change. They can check that the form is filled out. They cannot check that the change is safe.

The real quality checks - automated tests, code review by peers, deployment verification - happen before the CAB sees the change. The CAB adds nothing to quality because it reviews paperwork, not code. The developer who wrote the tests and the reviewer who read the diff know far more about the change’s risk than a board member reading a summary.

Meanwhile, the delay the CAB introduces actively harms quality. A bug fix that is ready on Monday but cannot deploy until Thursday means users experience the bug for three extra days. A security patch that waits for weekly approval is a vulnerability window measured in days.

Teams without CAB gates deploy quality checks into the pipeline itself: automated tests, security scans, peer review, and deployment verification. These checks are faster, more thorough, and more reliable than a weekly committee meeting.

It increases rework

The CAB process generates significant administrative overhead. For every change, a developer must write a change request, gather approval signatures, and attend (or wait for) the board meeting. This overhead is the same whether the change is a one-line typo fix or a major feature.

When the CAB requests more information or rejects a change, the cycle restarts. The developer updates the form, resubmits, and waits for the next meeting. A change that was ready to deploy a week ago sits in a review loop while the developer has moved on to other work. Picking it back up costs context-switching time.

The batching effect creates its own rework. When changes are delayed by the CAB process, they accumulate. Developers merge multiple changes to avoid submitting multiple requests. Larger batches are harder to review, harder to test, and more likely to cause problems. When a problem occurs, it is harder to identify which change in the batch caused it.

It makes delivery timelines unpredictable

The CAB introduces a fixed delay into every deployment. If the board meets weekly, the minimum time from “change ready” to “change deployed” is up to a week, depending on when the change was finished relative to the meeting schedule. This delay is independent of the change’s size, risk, or urgency.

The delay is also variable. A change submitted on Monday might be approved Thursday. A change submitted on Friday waits until the following Thursday. If the board requests revisions, add another week. Developers cannot predict when their change will reach production because the timeline depends on a meeting schedule and a queue they do not control.

This unpredictability makes it impossible to make reliable commitments. When a stakeholder asks “when will this be live?” the developer must account for development time plus an unpredictable CAB delay. The answer becomes “sometime in the next one to three weeks” for a change that took two hours to build.

It creates a false sense of security

The most dangerous effect of the CAB is the belief that it prevents incidents. It does not. The board reviews paperwork, not running systems. A well-written change request for a dangerous change will be approved. A poorly written request for a safe change will be questioned. The correlation between CAB approval and deployment safety is weak at best.

Studies of high-performing delivery organizations consistently show that external change approval processes do not reduce failure rates. The 2019 Accelerate State of DevOps Report found that teams with external change approval had higher failure rates than teams using peer review and automated checks. The CAB provides a feeling of control without the substance.

This false sense of security is harmful because it displaces investment in controls that actually work. If the organization believes the CAB prevents incidents, there is less pressure to invest in automated testing, deployment verification, and progressive rollout - the controls that actually reduce deployment risk.

Impact on continuous delivery

Continuous delivery requires that any change can reach production quickly through an automated pipeline. A weekly approval meeting is fundamentally incompatible with continuous deployment.

The math is simple. If the CAB meets weekly and reviews 20 changes per meeting, the maximum deployment frequency is 20 per week. A team practicing CD might deploy 20 times per day. The CAB process reduces deployment frequency by two orders of magnitude.

More importantly, the CAB process assumes that human review of change requests is a meaningful quality gate. CD assumes that automated checks - tests, security scans, deployment verification - are better quality gates because they are faster, more consistent, and more thorough. These are incompatible philosophies. A team practicing CD replaces the CAB with pipeline-embedded controls that provide equivalent (or superior) risk management without the delay.

How to Fix It

Eliminating the CAB outright is rarely possible because it exists to satisfy regulatory or organizational governance requirements. The path forward is to replace the manual ceremony with automated controls that satisfy the same requirements faster and more reliably.

Step 1: Classify changes by risk (Week 1)

Not all changes carry the same risk. Introduce a risk classification:

The goal is to route 80-90% of changes through the standard process, which requires no CAB involvement at all.

Step 2: Define pipeline controls that replace CAB review (Weeks 2-3)

For each concern the CAB currently addresses, implement an automated alternative:

Document these controls. They become the evidence that satisfies auditors in place of the CAB meeting minutes.

Step 3: Pilot auto-approval for standard changes (Week 3)

Pick one team or one service as a pilot. Standard-risk changes from that team bypass the CAB entirely if they meet the automated criteria:

1. Code review approved by at least one peer.
2. All pipeline stages passed (build, test, security scan).
3. Change classified as standard risk.
4. Deployment includes automated health checks and rollback capability.

Track the results: deployment frequency, change fail rate, and incident count. Compare with the CAB-gated process.

Step 4: Present the data and expand (Weeks 4-8)

After a month of pilot data, present the results to the CAB and organizational leadership:

• How many changes were auto-approved?
• What was the change fail rate for auto-approved changes vs. CAB-reviewed changes?
• How much faster did auto-approved changes reach production?
• How many incidents were caused by auto-approved changes?

If the data shows that auto-approved changes are as safe or safer than CAB-reviewed changes (which is the typical outcome), expand the auto-approval process to more teams and more change types.

Step 5: Reduce the CAB to high-risk changes only (Week 8+)

With most changes flowing through automated approval, the CAB’s scope shrinks to genuinely high-risk changes: major architectural shifts, compliance-sensitive changes, and cross-team infrastructure modifications. These changes are infrequent enough that a review process is not a bottleneck.

The CAB meeting frequency drops from weekly to as-needed. The board members spend their time on changes that actually benefit from human review rather than rubber-stamping routine deployments.

Measuring Progress

Related Content

• Single Path to Production - The pipeline replaces manual gates
• Deterministic Pipeline - Automated controls that provide consistent quality checks
• Rollback - Automated rollback replaces manual rollback plans in change requests
• Metrics-Driven Improvement - Using data to prove that automated controls work
• Deploy on Demand - The end state where any change can deploy when ready

2 - 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 no test automation 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 (Week 1)

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 (Week 2)

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 (Week 3)

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
• No Test Automation - Where this anti-pattern ends up if left unchecked
• Flaky Test Suites - Another way trust in the test suite erodes
• Metrics-Driven Improvement - Using data to make the case for quality practices