‘Product engineers’ vs ‘Software engineers’ in startups

The article would argue that the startup has a higher chance of failing then since you're focusing on what you personally want rather than what the business/customers need. Startups aren't big companies, the business goals are always "get as much of this done as possible as soon as possible" rather than "we need X by Y." You can't execute on the minimum needs of the business and expect success.

>I’m assuming if you _join_ a startup, rather then creating or co-founding one, there’s already a product person on board.

In a traditional company the product people (ie: those who define product and how product interacts with technology) includes engineering management (CTO, VP Eng, etc.). It's not just the people with product in their titles. In a startup, however, there isn't a deep hierarchy so that job falls onto everyone in engineering.

What OP is calling a "product engineer" is a good perspective for people that don't quite get that we live in a cash ecosystem and love to write good code but a lot of people hired as product engineers haven't written any code in decades. Hiring for that title is as clear as mud. Even if I have one that'll make my day in my company I might still need a senior dev that understands this stuff but wouldn't bother calling himself a "product engineer" for fear of getting crushed by the wheel of chasing customer expectations without qualifying them.

At the end of the day no matter what decisions the "product" team makes, as the "software developer" I need to make things happen and that takes leading the narrative enough that I don't get hung out to dry. Engineering predictability and its communication is the key to all success. Something that has helped me wildly has been the Microsoft book Software Requirements (3rd Ed) [0]. The system it lays out for planning, analysis, and risk mitigation is something everyone should read if they want to be more effective. It doesn't even have to be applied dogmatically.

If I can respond with a common lexicon of a vision and scope with a well laid out requirements spec then there isn't an issue with product, c suite, and dev communicating and everyone making money. It still shocks me every time I'm in a new org how hard that is to pull off even with the instructions. If comms and velocity track then there's enough wind to fill the sales sails.

[0] https://www.amazon.com/dp/0735679665

It hasn't. On the other hand, the gravitas of the "engineer" title has significantly eroded to business titles so much that "real engineers" are rarely seen with a seat at the table where power convenes. I don't know if this is just a local minima over the span of history, or the new normal. I hope it is the former, but I have reasons to suspect it will actually get worse.

The political power haloed around the "engineer" title, and thus the capacity to affect real, lasting change within organizations, is significantly less than the various equivalent-level management titles. It has eroded to the point that it is a notable anomaly when people remark, "the company is run by engineers". In some circles like some (not all) VC, they use that phrase to damn with faint praise.

But I agree that I'm not a fan of using software engineer and programmer interchangeably.