The Engineering Executive's Primer

Chapter 19. How to Run Engineering Processes

Uber ran a tech spec review process called the DUCK Review. Although “DUCK” didn’t stand for anything—it was created as a deliberate non-acronym—this was otherwise a fairly typical review process. When I first joined, we’d review one or two specs each week. The volume of requested reviews kept growing, and six months later there was a one- to two-week delay between requesting a review and receiving feedback. A year after that, the process was disbanded due to lack of bandwidth to process all the incoming specifications. This was an instructive experience for me, because the DUCK Review produced very valuable feedback but ultimately still failed because its operational costs were higher than we were willing to pay for that feedback.

Early in my management career, I believed most processes failed because they insufficiently addressed the problem at hand. I thought that if a process’ results were poor, it was because the process needed more nuance and sophistication. What I’ve learned since, mostly through designing thoughtful processes that nonetheless failed, is that a good process is a deliberate trade-off between quality and overhead. It’s common to see a code review process that runs quickly but provides low-quality feedback (for example, requiring code reviews be completed within two working hours of a pull request being made). It’s equally common to see a very involved, high-quality process that folks eventually ignore because it’s ...