A team can ship features and still struggle to serve customers reliably. Operational excellence (OE) means improving the processes, practices, and workflows that make delivery efficient and dependable. It includes communication, capacity planning, risk mitigation, and service-level agreements (SLAs). Engineering excellence is closely connected but distinct: it concerns the quality of technical work, including code quality, tests, technical debt, and security. section 12.0
When on-call work keeps growing
A rising on-call workload prompted one team to examine its core services. Quick fixes had increased technical debt, while missed infrastructure updates contributed to deterioration. Rather than treat each alert as an isolated interruption, the team worked with site reliability colleagues and dedicated a quarter to improving service health. The risk of doing nothing was less time for new products, lower morale, and burnout. section 1.2.4
A practical OE routine combines observation, prioritization, and follow-through:
- Identify constraints and recurring problems. Review on-call reports, defects arriving versus defects resolved, downtime, production availability, SLA performance, costs, and technical debt. Do not substitute lines of code or raw story counts for service health. section 1.1.1 section 1.2.4
- Make safer work repeatable. Improve documentation, change-management guardrails, and standard operating procedures; participate in design discussions, code reviews, and bug hunting. section 1.1.1
- Reserve capacity for maintenance. Keep a prioritized OE backlog and select technical-debt tasks each sprint, rather than waiting for all product work to end. section 12.2.3
- Agree on trade-offs with product partners. Discuss customer impact, technical complexity, and OE goals when deciding which features and improvements to pursue. section 12.4
OE is continuous, not a certification a team earns once. Improvements can themselves create friction, so invite feedback and refine them. Ambitious changes also need timing: a major rearchitecture may be valuable later but can overload a team already stretched by current operations. section 12.3 section 1.3.5
Improve the improvement
A team added a plug-in to catch code bugs and smells before review. After a month, false positives were slowing developers down. Engineers responded by letting developers flag false positives so they would not recur. The guardrail stayed, but its workflow became less disruptive. section 12.3
Start by asking: Which recurring operational problem consumes capacity, how will we recognize improvement, and what work can we prioritize alongside product delivery? section 12.5 section 12.4
