A team deploys only once every two weeks, yet releases still contain bugs that affect customers. Engineering excellence addresses the quality of the team’s technical work: whether its code and development practices produce software that is effective, reliable, and sustainable. It includes code quality, test coverage, technical debt, and application security. section 12.0
Engineering excellence and operational excellence are connected but distinct. The first concerns technical work and the resulting product; the second concerns the communication, planning, risk management, and workflows that enable reliable delivery. An engineering manager needs to support both rather than treat better code as a substitute for better coordination. section 12.0 section 1.5
To build a culture of engineering excellence:
- Set practical quality guardrails: raise coding standards, focus on test coverage, and learn from mistakes. Favor decisions that sustain development over short-term gains. section 12.2 section 12.6
- Make trade-offs visible. Discuss customer impact and technical complexity with product partners when feature requests compete with limited engineering capacity. section 12.4
- Keep refining the practices themselves. Seek engineers’ feedback, address friction, and provide opportunities to develop skills. section 12.3
Improve the guardrail, not just the code
A team adds a static-analysis plug-in to detect bugs before code review. After a month, engineers report that false positives slow them down. They add a way to flag those results so they do not recur. The quality check remains, but feedback makes it more useful. section 12.3
Excellence is an ongoing practice, not a final certification. Ask which quality problem is hurting customers or engineers now, then choose a proportionate improvement and revisit its effect. section 12.3 section 12.4
