Manager or short order cook?

Does your organization really value quality?

It’s very easy for organizations to have “values” that are uncontroversial - things like “user focus”, “quality first”, etc. Without real commitment, these are just nice things to say though - and we’ve all been in organizations that say they have a certain kind of value but don’t really.

One way to understand if your organization really values something is whether it will make tradeoffs to get it. Quality is a good example, and how engineers and engineering managers are empowered to ship, or not ship, based on quality concerns tells a lot about the real priority. And here, quality is a broad term that encompasses things like bugs but also just overall user experience.

One low-quality pattern is “short order cook”. In that model, engineers and first level managers are just given a series of tasks to complete, with very little in the way of context. They are measured almost entirely on throughput - quality only enters into the picture in so much as a task is returned to be worked on again, and it lowers overall throughput accordingly. These organizations can be effective in execution but rarely build strong user experiences - engineers and managers usually have the best idea of how well something is working, and removing their ability to object to a bad product (and introduce a delay) creates all kinds of problems.

So this is an interesting question to ask when you’re interviewing, and it’s an interesting pattern to look for if you’re a leader. Can engineers hold up a release for quality issues? Usually the answer is yes for the most egregious examples, so then the real question is - what severity of issue is the smallest that an engineer could delay a release over? This is now a kind of uncomfortable question - and now you’re learning something valuable by answering it!

Watch for the short order cook syndrome - both as an engineer and as a manager.