Discover more from Rick Manelius's Newsletter
Hiring Devs: Product vs. Project Mindset
When interviewing developers, a critical differentiator is how approach their work. Unfortunately, it took me years and several mis-hires (and firings) to learn this lesson.
I will no longer work with devs who only work on projects.
No, they are not bad or stupid, or lazy. Just like product devs, they can deliver great work.
It’s just that they’ve become so accustomed to working in a particular way that isn’t compatible with building, delivering, and iterating products.
Let’s compare how these mindsets approach their workday.
Project devs get paid when the work ships.
Product devs keep getting paid if what they’ve shipped works.
Project devs are focused on if the code “works on my machine.”
Product devs are focused on whether the code delivers value to the end-user.
Project devs can take shortcuts in writing their code.
Product devs know that shortcuts will eventually explode in their face.
Project devs can be lone wolves.
Product devs are forced to collaborate.
Project devs don’t have to care if their customer’s business model is shit.
Product devs want to make sure their code impacts the bottom line.
Project devs can live in an echo chamber with other devs.
Product devs have to interact with marketing, design, operations, etc.
Project devs rarely get the chance to refine and improve the product.
Product devs routinely find and make improvements to the product.
Project devs optimize for one deliverable over many clients.
Product devs optimize for many deliverables for one company.
Project devs can be narrowly focused on their piece of the puzzle.
Product devs require a holistic view of how their work touches everything.
Project devs are typically mercenaries (hired guns).
Product devs are more likely to be missionaries (true believers).
Project devs can be fantastic at things like customer websites, where there is a repeatable pattern to collect requirements, design, build, launch, and move on.
But project devs can fall on their face when they find themselves on a diverse team of 10 for a B2B SaaS company trying to figure out the right features to increase customer adoption and reduce churn.
The project dev just “does what they are told.” The product dev must push back and ensure that their work balances multiple competing needs.
There is a time and place for a specialist who is the best in the world at one thing, and you pay them the big bucks to build you that custom piece.
But those situations are rare, IMHO. Instead, you typically want someone that has strong skills across the dimensions of engineering, communication, and leadership.
When interviewing people at a tech startup, I try to assess the style of the work that they’ve done. For example, if they worked at an agency that specialized in a rolling queue of X clients for Y solutions, then they have grown accustomed to project-based workflows.
This doesn’t mean they can’t make the jump. However, you have to be intentional during the onboarding period to make sure they don’t approach it as a project.