There are two types of developers in this world, those who care about the product they produce and those that care about doing their craft well. You can tell them apart by how much they ask “why?”.

Traits of Product Engineers

I was first introduced to the idea of the product developer here: The Product-Minded Software Engineer. Product engineers focus primarily on the outcomes of software development: Use cases, business goals, and internal motivations. They engage with the “why” actively.

Traits of Craftsmen Engineers

Craftsman engineers are what people probably imagine when they think of a traditional developer. They focus on improving their craft first. Craftsman developers prioritize building systems that are simple, efficient, and scalable. While product developers measure success on the outcome, craftsman engineers focus on the speed and quality of the output produced. They engage with the “how.”

It’s a Spectrum, Not A Hierarchy

It’s important to point out that one of these types is not better than the other. Successful products need both skillsets to fill different roles. A developer can also be fluid, and change where they are on this scale at different points in their career, and in different roles.

When defining roles for developers, think about what kind of developer you need for the work at hand. Misfits lead to project failures. For example:

Misfit Failure #1: Craftsman in a Product Role

Stop me if you’ve heard this one before: An aspiring entrepreneur has an idea for a new product. They decide to outsource development to save money and end up with a pile of code that technically meets the specifications but fails in other ways no one anticipated, dooming the project.

In another case, a startup gets funding, puts together a team. Six months later they’ve built something beautiful and scalable that doesn’t solve any real problems, and no one uses it.

Both of these are cases where craftsmen were used and a product engineer was needed. They built what as asked of them well, but there wasn’t enough clarity on what they were building. Craft doesn’t matter without a strategy. In this case, a product engineer could have stepped in to offer guidance on what to build, and help prevent problems before they happen.

Misfit Failure #2: Product Engineer in a Craftsman Role

Across the street at a web development agency, the salesperson is excited about a large new contract. However, when its time to turn the project over to the development team, the initial excitement is blunted by their frustration, and later apathy.

“Why are we building it this way? Do we even need this feature?” They ask. But it doesn’t matter, because the specs are written and the contracts signed. The best thing the engineers can do at this point is to deliver code that is bug-free without going over budget. But they’ll struggle with this since it’s hard to get motivated when you feel like your work is pointless. A more likely outcome is a product with cut corners in order to come in at budget. In the end, nobody is happy.

Craftsmen thrive in these scenarios. They get to focus on what they do best, writing code and designing systems while letting other people worry about “the business stuff.”

Better Fits = Less Risk

By understanding what your needs are, you can better define what kind of developer you need for each role. As someone who is far, far on the product spectrum, I both know how great it is to collaborate with clients to find the best solution, and how frustrating it is to be in the situation of being a powerless order taker.

So before you start your next project, ask yourself:

Do you need someone to help you build the right thing… or someone to help you build the thing right?

I'd love to hear your thoughts. How would you define yourself? Does this dichotomy make sense to you?