Is Your Engineering Focus on Product or Craft?

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 a Product Engineer

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 a Craftsmen Engineer

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 types of developers 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 and contexts.

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.”

Another model: Rockstars & Superstars

Another model you can use when looking at developer motivations is the “rockstar” or “superstar” model from Radical Candor. In the book, it describes two types of employees differentiated by their internal motivatations.

Rockstars are motivated by gaining expertise and improving their craft. Unlike their musical namesake, they aren’t looking for attention, but would rather be a foundational rock for their team.

Superstars are motivated by career growth. Superstars want to move up beyong the coding layer and into bigger problems, because that’s how you move up in your career.

I don’t think these models are an exact match, but rockstars being craftsmen and superstars being product focused are going to be more true than not. You could have rockstar product developers, who may become more infatuated with the process of creating product than the product itself. Inversely, you could have superstar craftsmen, who look to move up not within the company, but within the ranks of other developers.

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?