Good Engineer / Bad Engineer


The following is my adaptation of Ben Horowitz’s Good Product Manager / Bad Product Manager that I use to set expectations for my team:

Good engineers solve customer problems, bad engineers solve technical problems. Good engineers first understand the “why” and the “what”, bad engineers jump straight to the “how”. Good engineers make their colleagues smarter, bad engineers make their colleagues aware of how smart they are. Good engineers come armed with data, bad engineers come armed with opinions.

Bad engineers flip tables, good engineers build bridges. Bad engineers focus on what can’t be done, good engineers focus on what can be done. Bad engineers assume that non-technical people are stupid, good engineers welcome varying perspectives. Bad engineers always know what’s best for the customer, good engineers know how to best serve the customer’s needs. Bad engineers are quick to tell you how they would do it, good engineers are quick to ask how others are doing it.

Good engineers frustrate easily and channel that energy towards improving things, bad engineers blame others for their frustration and are paralyzed by it. Good engineers question their superiors, bad engineers undermine them. Good engineers lead without titles, bad engineers need titles to lead. Good engineers disrupt the status quo, bad engineers use the status quo as justification.

A bad engineer can be the smartest person in the room, a good engineer rarely feels like the smartest person in the room. Bad engineers always focus on what sucks, good engineers can find some genius in almost anything. Bad engineers explain things in minute detail, good engineers convey complex topics in a manner the audience can digest. Bad engineers say “it works”, good engineers say “I can’t break it”.

No engineer is completely bad, no engineer is completely good. All engineers have power over which type of engineer they choose to be. A good engineer accepts this, a bad engineer labels their colleagues.