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.
They ask. But it doesn’t matter, because the specs are written and the contracts signed.
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.