The context of that is entirely different than a "do we need QA" context. "Think and Analyze" is an abstract philosophy, not a process for engineering.
I'd say that if you have a T&A team it would be great to measure and publish your defect rate. Of course, if you just have better than average coders, then naturally your defect rate can be low.
But even a low defect rate does not preclude having a formal QA process. Even the best coders in the world can ship the wrong product when the specifications are wrong.
I used to run a QA department for a large e-commerce company and love what this article has to say. Nothing gets executive attention like putting a dollar value on downtime (like $1k per minute on a slow day).
A sysadmin knows and loves the OS. Can script to craft utilities for repetitive tasks. Can field strip and installation down to device drives. Can provision identical systems in his/her sleep. Can solve critical problems under pressure. Is not afraid of doing it live. Will argue for a test lab endlessly. Has read the Bash man page. Favors practicality over aesthetics. Uses the right tool.