> There's a whole checklist Patterson looks for whenever he makes product hires... One of my main frustrations with non-technical PMs (chefs and soldiers proba

> There's a whole checklist Patterson looks for whenever he makes product hires... One of my main frustrations with non-technical PMs (chefs and soldiers probably apply, but not always) is when they aren't actual experts in the software business, in the business of code. There are Dunning Kruger effects in play. The usual response is "find the smart people and listen to them" but hopefully everyone on the project is smart, in which case the advice isn't actionable. And the Dunning Kruger effect is a huge deal when trying to find the people that are specifically great at technical strategy. Another response is to find a more objective way to find the best technical advice, whether through metrics or less specific track records. But building a good software product is complex and time-consuming enough that you get very few data points to work with. Sometimes the negative effects of bad decisions (massive technical debt, intractable legacy systems, retention problems, etc.) are indirect or won't really be felt until at least some of the personnel on the project has moved on. A specific concern that a non-technical PM will underestimate is tooling. Unsupported dependencies, old language versions, old compilers, mostly broken IDEs, undersized build farms (if they exist), and so on typically happen when the people making strategic decisions can't code, or at least haven't coded lately. It's not always easy to know when to buckle down and fix something like that, but I often see equivalent (organizational-value-wise) feature work getting star treatment.