Aside from that, while it might seem like an ideal engineering culture, I find it a bit extreme. The harsh SLA leaves little room for prioritization. Sometime the team is in fact working on a tough integration deadline, and medium-level bugs can wait for it to finish.

Going over my current list of bugs, some are minor and can wait to the last mile of the release and some will be resolved by new features we have in planning. I do aim to minimize the list of bugs and even my email inbox is based on a "zero inbox" policy. Still "zero" in this case is some small epsilon that is under control, and will go down to zero if no new bugs/emails arrive in the meantime. Call it a sliding window of epsilon width, but it almost never really reaches zero.

> The zero-bug stance means that we address bugs immediately

That's the key part. What does it mean "address"? I worked in organizations, where a dev could push any fix to dev basically anytime. CI pipeline would get the fix deployed in 3 minutes and it's there. However, getting that fix to production and to the end user was a completely different story. It required hours or even days of concentrated effort in managing all the communication. Justifying an out-of-process deploy was painful enough. So most people wouldn't do it, the bug will be fixed in the next quarterly release anyway, and my paycheck is the same, so why bother?