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?
Top comments (8)
Hey Glenn, thanks for this. I think about this topic pretty regularly.
I think the concept of product vs craft is the wrong dichotomy to use here. All truly exceptional workers need to ask why. A craftsman asks "Why did this system work? Why did that system fail?" A product engineer asks "Why did this feature work? Why did that feature fail?" I would pick something like "leaders vs followers" or maybe "autonomous vs dependent" to represent the why vs how dichotomy.
This is a scenario that will probably not have a good outcome no matter who is working on it. I don't think I have ever seen a salesperson throw a contract over the wall with a deadline and have it turn out well unless it is for something that has been done dozens of times.
As Bob Martin likes to point out, contracts can be changed if both parties agree to it.
Thanks for the feedback. One reason I love sharing ideas here is that thoughtful conversations like this help me refine these ideas more.
What you are saying about asking "why" makes total sense. There is probably a better way to phrase it.
My issue with "leaders vs. followers" is that it implies a hierarchy where I don't think one exists, though on some teams it can. Lead developers can be craftsmen, and lead the team when it comes to not only code quality, but also internal processes and communication.
The agency example could also be stronger. What I was trying to say is that I know other developers who relish in situations where they prefer to do deep work on code and let others focus on the external details, while for others that same work is frustrating.
I have definitely worked on projects where the people responsible for developing the solution were disconnected from the design and definition of said solution. Whether or not those projects ended well is a matter of perspective. If the developers deliver what the client asked for, and the client pays on time, is that a "good" outcome? Did the feature do what it was supposed to do? Does it matter? Sometimes the only metric of success is client happiness.
This is a good distinction to make. So, I didn't mean that in terms of corporate hierarchy, but in terms of the concept of servant-leadership. Where the workers lead on their projects and management is there to help with blockers and stewarding the team. This is in contrast to the standard command and control style where workers are employed to bring the vision of the management to fruition.
Thanks for this post, Glenn!
Like you, I lean heavily towards the "Product Engineer" mindset (although I'd not heard that phrase until now). My first question is usually "What problem does this feature solve?". This is a habit that has developed naturally -- I've had too many carefully crafted features that went unused and unloved. Those failures sting, and so one learns to ask the question. That and empathising with users. After all, I'm quite often a frustrated user of software myself!
Like @kwstannard , I'm not sure there's a dichotomy between product and craft. If anything, the two can complement each other -- by stripping down the requirements, you can focus on crafting the work that is being done.
However, I agree with your follow-up statement that some developers prefer to do the deep work on the code and let others deal with the requirements. In this case, they need to trust that other person.
So, in all, I'm not sure what the dichotomy is. "Leader" - "Follower" downplays the importance of the deep worker. Perhaps "Asker" - "Maker". Or "Why-er" - "Wow-er".
Really interesting discussion!
Interesting. I think I lean more towards asking questions about craft and systems because I have been bitten too many times by technical debt making completing features hard or sometimes even impossible.
Very good point. I guess that just furthers the case that craft and product aren't mutually exclusive. If anything, they're two stages of the same process: product first, craft second. It's possible to ask questions about both.
My thinking is: all unused features are technical debt, regardless of how well they're crafted. They're all noise. Any time spent on them is wasted up front and then multiplied in their maintenance. (Although, as with any grand statement, there are no doubt exceptions.)
Perhaps there should be a distinction to be made between types of technical debt: Used and Unused. I would tend to treat the two very differently.
Agreed.
I always felt, in some cases, things we are doing aren't just right. Now I know why. Thank you for this post.