A performance bottleneck is a workflow constraint that limits throughput or delays progress. In software teams, it often appears when code reviews, approvals, or deployments depend on one person or an oversized process. section 7.1.4 section 8.0
The useful question is not simply “Who is slow?” but “Where does work wait, and what safeguard or decision makes it wait?” A bottleneck can form before review, during review, or after approval. Long delays reduce the value of releases, increase organizational cost, and can make people disengage from the process. section 7.1.4 section 8.0
Use the intervention that matches the constraint:
- If every pull request requires one senior developer, distribute approval authority across the development team rather than treating seniority as a mandatory gate. section 8.1
- Support broader approval with safeguards such as automated checks, unit and integration tests, staged environments, easy rollback, shared accountability, and a blameless culture. section 8.1
- If deployment requires rebuilding an entire monolith for every small change, separate logical domains into independently buildable projects while retaining shared libraries where useful. section 12.2.1
- Keep code review in the workflow, but reduce the amount of work waiting behind the bottleneck and inspect adjacent lifecycle problems that create oversized pull requests. section 12.2.1 section 8.0
From monthly releases to almost daily releases
A team discovered that small CSS or test changes required redeploying its entire monolithic application. It divided the application along five logical domains, moved them into separate projects, and kept shared utilities in shared libraries. Each change then triggered a build and release only for its project, allowing the team to move from monthly releases to almost daily releases without adopting a full microservices architecture. section 12.2.1
Figure 12.2 Agree and then split approach to doing both mob programming and code reviews
Use the agree-and-then-split workflow to coordinate shared design decisions before dividing implementation work and continuing code reviews. section 12.2.1
