I agree with the title, but disagree with the article. If you're at all an experienced software engineer, you should avoid working as a "software engineer" at a startup, because you'll most likely be worked to the bone for a pittance in equity.
You're much better off either finding a VP or C-level position at a much smaller startup, or doing your own side project. At least when you're working at 3am, because the only client wants something by tomorrow, you'll know that all the net will go into your own bank account.
I'm tired of the whole "if you're doing x at a startup you're foolish"
You only live once, it's amazing to be an engineer now and have all the choices of being able to actually work somewhere that you ENJOY working at, that you align with and find interesting. If that job happens to pay you $250k / year then great, but if it pays you only $150k and you actually enjoy half your waking hours then seems like you're the real winner.
Great article. Here are some examples of how you know if you have a software engineer or product engineer at your startup (real experiences from me):
CEO: We need to add a product search to our website so customers can easier find the products which they like.
SE: Ok - and walks off and builds a search box into website.
PE: Ok - walks off and builds a search box into the website. Also logs all search queries with zero results into a big table to give the startup a better insight into products which customers want, but couldn't find.
Another example...
CEO: We need some real time messaging into our communication channel (Slack) when a customer order couldn't be fullfilled during packaging, so customer support can pro-actively reach out to the customer and notify them about whatever the problem was.
SE: Goes away for a few days and builds a complex real time notifications API which needs to hold state about which notifications it has already sent and which not. Uses latest fanciest tech for that.
PE: Starts asking critical questions. Why does it have to be real time? What time are most orders being packed? What time does customer support staff start actually working? Turns out after 10 minutes of asking the right questions that a real time messaging service is overkill if most CS staff only starts working after all the packaging is already done. A simple stateless daily report being sent once to the Slack channel is completely sufficient and does the job just as good if not better than a real time solution. PE walks off and implements this in a couple hours and has the majority of the week still free to do more impactful work.
EDIT:
Product engineers with a real "get shit done" mindset are invaluable not only to startups but even well established companies. They are the ones who really drive success through good communication, great understanding of the business, all the different parties and the tech which they have to their availability to find the best solution for any given problem.
So a 'product engineer' is a 'good software engineer'? Unless you are a drone you should always ask the questions of why something needs to be done before implementing it. The engineering part of software development has to be done before you start typing on a keyboard.
So a product engineer is a PM and software engineer in a single body. In an organization with actual PMs the CEO doesn’t tell this to a software engineer they tell it to a PM. The PM interviews the CEO, customer support team, and engineering team (since the spec depends on whether the real time solution is 10% or 10x more expensive than the daily digest) and produces a spec. As the engineers iterate they uncover holes in the spec which the PM fills in.
Sometimes the old school methods are better than whatever modern crap has the CEO making feature requests to engineering.
> PE: Ok - walks off and builds a search box into the website. Also logs all search queries with zero results into a big table to give the startup a better insight into products which customers want, but couldn't find.
This one confused me. Shouldn't you be logging as much as possible anyway? There's going to be so many things you can't predict ahead of time with this kind of stuff.
What you describe as a Product Engineer, I call a Senior Engineer/Developer/Programmer/etc.
Your examples essentially differentiate between 1) a person who accomplishes an assigned task because it was assigned to them and 2) a person who knows that there is more to completing a task than meeting the defined requirements.
I worked at a startup as the first Dev, it was a shock for me having to now consider things like:
* What company laptops to buy?
* Assess the merits of AWS and GCP and make a decision.
* Divine an architecture that will get the product to the customers ASAP but will last at least a year with growth before needing a major rethink.
* Present to customers, board members and potential investors about the tech.
Eventually I was coding around 60% and doing these other things around 40% of my time.
I guess this would be what a CTO does, so it was a great taster for me however I did get burned out with it after a year (plus working in London was taking its toll as well).
For any developer who is quite senior, I would recommend trying it. I learned a lot about myself.
I'm a CTO at a 30-ish person company and yep this is my job. Lots of development, but also handling all the infrastructure and ops for a long time (I'm able to offload more to other devs these days).
I still primarily code but also do lots of long term tech strategy like cloud? and which, as well as business planning with the rest of our leadership level, hiring, training new devs, keeping all the devs up to date with new stuff, breaking down and delegating work, reviewing code, monitoring & alerting and understanding a system that's practically a living organism and being able to anticipate trouble spots rising, planning and executing what are sometimes multi-year efforts (e.g., significantly refactoring major parts of a 10+ year old code base).
Personally, I like it, though it has its difficulties. It also makes me an exceptionally valuable person for this size of company - big enough to really need breadth and depth of experience, but not in a position to have several tech people with a decade or two of experience. Find the right company (I was lucky to) and it's a golden ticket.
What about London took its toll? I've been contemplating a switch from NYC to London. I know it will be a 30-50% pay cut, but I've been told by other's who have lived and worked in both that it is worth it for the better work/life balance.
Would people please stop shitting on php. It's no better nor worse than let's say, ruby. It gets shit done. It is a valid tool very widely used in the wild.
The best thing about PHP is that it often serves as a good model of how not to solve technical problems. A lot of people have experience with it so taking examples from PHP resonates with them. PHP is getting worse in this regard because the current implementation fixes quite a few things.
Unfixable things remain though and PHP will keep serving as a bad example in the future.
> Would people please stop shitting on php. It's no better nor worse than let's say, ruby. It gets shit done. It is a valid tool very widely used in the wild
And this, ladies and gentlemen, is whom you should hire as your tech leadership. He will get your product shipped in a reasonable amount of time, rather than rewrite an app that is making you $2 million a month in Go because some new log ingestion framework wants protobufs so you can query "what are the new browser agents that we have never seen before".
SAS is a valid tool as well, many colleagues in healthcare research use it. Useful sure, but that Doesn't mean STATA, R, and Python users will heal their scar tissue over using that awful software. I could calculate regressions with pencil and paper but that valid tool is just not performant.
One dynamic that is not discussed explicitly here concerns junior/mid-level engineers who perhaps didn't get the offer at Google/fb the first go-around and are working at your startup as a fallback. They probably don't care about executing strongly on your startup's mission in year one as much as they care about their own careers/CVs. As they should. Things they might talk about implementing that probably won't help your new business:
-distributed systems
-hand-rolled ML
-react
-hiring dedicated QA professionals so that they can focus on coding algorithms
If you say no to all of this and tell them to go write another rails view for the admin dashboard, they will simply quit. The challenge is to find the right balance between "product engineer" tasks and tasks that will show the engineer that you genuinely care about their career outside of the next BD stunt.
Having some sort of secondary bottom line helps enormously with this tension, in my experience.
The author believes working as a software engineer in a startup is fine so long as you have the title "product engineer" rather than "software engineer", as if your job title actually matters.
This is an uncharitable reading of the article. They aren’t just suggesting a different title - they’re suggesting doing a different job - shaping the product rather than just implementing it.
i didn't read the article but in my experience a title is meaningless until head count is > 50 or so. I know people who have 5 separate business cards all with different titles, they choose which one to hand out based on the audience.
Whoosh. He is saying you aren't seeking software engineering perfection - so forget trying to be an architecture astronaut and all that that entails. You are seeking product perfection - at any given time. And product perfection can only be judged by your customer satisfaction and business growth.
I read this article with a bit of hunger and nostalgia to return to my former life as a startup engineer... but I think upon further thought I'm leaning against it again.
As a bit of history, I worked as an engineer at startups for most of my early career. Mostly frontend work, all SaaS businesses. I enjoyed it. I wore many hats, and got to think about the customer a lot. I didn't like always worrying about my paycheck and job security. 2 years ago I transitioned to a Platform Support Engineer at Heroku. Now I manage folks on that team.
The thing I loved most about startup life was getting to be engaged in every facet of the business - my voice carried weight in technical aspects, financial aspects, support, culture, etc. I have a natural aptitude for things beyond just programming, and think often about the larger business and customer impact. It was great being able to speak up and leverage those parts of my brain.
However, part of me thinks that perhaps the joy I found in being involved everywhere was that it made me feel smart. I felt like I could be an expert in every domain. But that's not really realistic, is it? Today I work in a very small domain with a limited breadth of responsibility... but I am _the_ expert on developer support. There is no one else in the organization (outside of my team, of course) that can challenge my thoughts on support, because I am the expert. Similarly, I would not dare challenge the expertise of our finance team. I know quite a bit about finance, but they blow me out of the water. They're specialized, and undeniably make better decisions than me.
Is it really that much better to feel smart and make average/bad decisions based on intuition? I'm not sure. I think as far as output goes, specializing is better.
>But what if I want to join a startup so I can build out the stack of my dreams while accomplishing whatever business goals are set?
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.
You are assuming a whole lot with that one. Even when I have had product people it's very rare that they are connected with the development team and a lot of times they are stacked adversely in a team under 10 people. Bridging the product to dev and back again gap is more than a full time job. More often than that situation I've found that there just isn't a product person. I would like to know where your assumptions find startups that aren't a clusterfuck because I need to check that blog or newsgroup or whatever.
Maybe, maybe not. And if there is, they may or may not have enough bandwidth/power to really flesh out the full product vision. Part of the attraction to startups for some, myself included, is the agency that technical people can gain with respect to what they ultimately work on in an environment where anyone with an idea might get "airtime".
Shouldn't all 'software engineers' be 'product engineers'? I don't really get his point, all he's describing is what any good engineer should be doing anyway.
Fyi.... This type of advice has been given in many essays using different words. Probably the one that HN is most familiar with is "Don't Call Yourself A Programmer,"[0]. Another variation on the same theme "avoid being paid for code"[1].
tldr: try not to be just a "code monkey" but shift your perspective up the value hierarchy so you can provide business solutions. Try not to be an interchangeable and commoditized "cog in the wheel".
IMO, what this essay leaves out is that many people self-select into "product manager" type roles because that's more interesting and fulfilling than coding all day long. On the other hand, other types of programmers prefer to stay "heads down" and just code instead of interfacing with customers.
Take two software startups. StartupA hires nothing but the stereotypical "software engineer". StartupB hires nothing but the stereotypical "product engineer". Which startup will be more likely to have a future?
Aside from the clickbait title and the rough writing, good article. The key to excelling as a developer isn't your technical prowess, it's your soft skills, which includes understanding the business you're in and how to interface well with stakeholders in other divisions.
Some of this is OK. But I've been at companies that just "do what the customer wants in the next quarter" and nothing else. It is usually a shit show. You need to blend long term thinking with customer focus. It's very hard to get it right.
Great article, BUT there are no examples of what the hell a product engineer ACTUALLY does.
It might be good to point out that data driven development is key. A product engineer collect insights with each feature that is created backed BY ACTUAL DATA and not armchair hypothesis
Hire "problem solvers" who have CS degrees and pay them to solve your problems. They should have a practical bent and should accept 80% solutions (good enough). That is key to getting stuff done. Avoid non-pragmatic roles (architects) that like to talk and draw a lot, but not do anything.
If everyone follows this advice then who will implement the system? Outsource to external professional firms? We already outsource to accountants, lawyers, ad agencies etc.
[+] [-] 5trokerac3|6 years ago|reply
You're much better off either finding a VP or C-level position at a much smaller startup, or doing your own side project. At least when you're working at 3am, because the only client wants something by tomorrow, you'll know that all the net will go into your own bank account.
[+] [-] Techonomicon|6 years ago|reply
You only live once, it's amazing to be an engineer now and have all the choices of being able to actually work somewhere that you ENJOY working at, that you align with and find interesting. If that job happens to pay you $250k / year then great, but if it pays you only $150k and you actually enjoy half your waking hours then seems like you're the real winner.
[+] [-] lonelappde|6 years ago|reply
HN is flush of people who did quite well on startup equity.
[+] [-] dustinmoris|6 years ago|reply
CEO: We need to add a product search to our website so customers can easier find the products which they like.
SE: Ok - and walks off and builds a search box into website.
PE: Ok - walks off and builds a search box into the website. Also logs all search queries with zero results into a big table to give the startup a better insight into products which customers want, but couldn't find.
Another example...
CEO: We need some real time messaging into our communication channel (Slack) when a customer order couldn't be fullfilled during packaging, so customer support can pro-actively reach out to the customer and notify them about whatever the problem was.
SE: Goes away for a few days and builds a complex real time notifications API which needs to hold state about which notifications it has already sent and which not. Uses latest fanciest tech for that.
PE: Starts asking critical questions. Why does it have to be real time? What time are most orders being packed? What time does customer support staff start actually working? Turns out after 10 minutes of asking the right questions that a real time messaging service is overkill if most CS staff only starts working after all the packaging is already done. A simple stateless daily report being sent once to the Slack channel is completely sufficient and does the job just as good if not better than a real time solution. PE walks off and implements this in a couple hours and has the majority of the week still free to do more impactful work.
EDIT: Product engineers with a real "get shit done" mindset are invaluable not only to startups but even well established companies. They are the ones who really drive success through good communication, great understanding of the business, all the different parties and the tech which they have to their availability to find the best solution for any given problem.
[+] [-] yoz-y|6 years ago|reply
[+] [-] rficcaglia|6 years ago|reply
CEO: I want X....and Y, Z, and enhance A-F, all yesterday
SE: you outsourced me last month!?
PE: I can’t do anything without more specs
Or
CEO: I want X
SE, PE: 3 months later deliver X
Sales: Customer doesn’t want X, wants Y and Big Deal deadline is tomorrow
CEO: drop everything, R.I.P. out X and build Y and ship it tonight!
[+] [-] paggle|6 years ago|reply
Sometimes the old school methods are better than whatever modern crap has the CEO making feature requests to engineering.
[+] [-] alexandercrohde|6 years ago|reply
CEO: "We need a search box"
Product Owner: "Okay, let me do some research and build out a design. Here are all the metrics we'll track and quantify the success of the project on"
Engineer: "Okay I've implemented your design, and put in all the essential logging to power those dashboards"
Product owner: "Great, after our search box, sales went up 7% for these items. This means $75,000 a year. Success"
CEO: "K."
[+] [-] cameronbrown|6 years ago|reply
This one confused me. Shouldn't you be logging as much as possible anyway? There's going to be so many things you can't predict ahead of time with this kind of stuff.
[+] [-] dhmiller|6 years ago|reply
Your examples essentially differentiate between 1) a person who accomplishes an assigned task because it was assigned to them and 2) a person who knows that there is more to completing a task than meeting the defined requirements.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] cryptozeus|6 years ago|reply
[+] [-] ulisesrmzroche|6 years ago|reply
[+] [-] mothsonasloth|6 years ago|reply
* What company laptops to buy?
* Assess the merits of AWS and GCP and make a decision.
* Divine an architecture that will get the product to the customers ASAP but will last at least a year with growth before needing a major rethink.
* Present to customers, board members and potential investors about the tech.
Eventually I was coding around 60% and doing these other things around 40% of my time.
I guess this would be what a CTO does, so it was a great taster for me however I did get burned out with it after a year (plus working in London was taking its toll as well).
For any developer who is quite senior, I would recommend trying it. I learned a lot about myself.
[+] [-] lucb1e|6 years ago|reply
[+] [-] qes|6 years ago|reply
I still primarily code but also do lots of long term tech strategy like cloud? and which, as well as business planning with the rest of our leadership level, hiring, training new devs, keeping all the devs up to date with new stuff, breaking down and delegating work, reviewing code, monitoring & alerting and understanding a system that's practically a living organism and being able to anticipate trouble spots rising, planning and executing what are sometimes multi-year efforts (e.g., significantly refactoring major parts of a 10+ year old code base).
Personally, I like it, though it has its difficulties. It also makes me an exceptionally valuable person for this size of company - big enough to really need breadth and depth of experience, but not in a position to have several tech people with a decade or two of experience. Find the right company (I was lucky to) and it's a golden ticket.
[+] [-] jermaustin1|6 years ago|reply
[+] [-] asah|6 years ago|reply
[+] [-] bgnm2000|6 years ago|reply
[+] [-] arpa|6 years ago|reply
[+] [-] sterileopinions|6 years ago|reply
PHP can be a bit of a punching bag, even when it's not topical. But it's not exactly unwarranted.
[+] [-] lolc|6 years ago|reply
Unfixable things remain though and PHP will keep serving as a bad example in the future.
[+] [-] triceratops|6 years ago|reply
[+] [-] notyourday|6 years ago|reply
And this, ladies and gentlemen, is whom you should hire as your tech leadership. He will get your product shipped in a reasonable amount of time, rather than rewrite an app that is making you $2 million a month in Go because some new log ingestion framework wants protobufs so you can query "what are the new browser agents that we have never seen before".
[+] [-] ionforce|6 years ago|reply
[+] [-] Dumblydorr|6 years ago|reply
[+] [-] nateburke|6 years ago|reply
-distributed systems
-hand-rolled ML
-react
-hiring dedicated QA professionals so that they can focus on coding algorithms
If you say no to all of this and tell them to go write another rails view for the admin dashboard, they will simply quit. The challenge is to find the right balance between "product engineer" tasks and tasks that will show the engineer that you genuinely care about their career outside of the next BD stunt.
Having some sort of secondary bottom line helps enormously with this tension, in my experience.
[+] [-] onion2k|6 years ago|reply
[+] [-] chrisseaton|6 years ago|reply
[+] [-] chasd00|6 years ago|reply
[+] [-] nbevans|6 years ago|reply
[+] [-] josephwegner|6 years ago|reply
As a bit of history, I worked as an engineer at startups for most of my early career. Mostly frontend work, all SaaS businesses. I enjoyed it. I wore many hats, and got to think about the customer a lot. I didn't like always worrying about my paycheck and job security. 2 years ago I transitioned to a Platform Support Engineer at Heroku. Now I manage folks on that team.
The thing I loved most about startup life was getting to be engaged in every facet of the business - my voice carried weight in technical aspects, financial aspects, support, culture, etc. I have a natural aptitude for things beyond just programming, and think often about the larger business and customer impact. It was great being able to speak up and leverage those parts of my brain.
However, part of me thinks that perhaps the joy I found in being involved everywhere was that it made me feel smart. I felt like I could be an expert in every domain. But that's not really realistic, is it? Today I work in a very small domain with a limited breadth of responsibility... but I am _the_ expert on developer support. There is no one else in the organization (outside of my team, of course) that can challenge my thoughts on support, because I am the expert. Similarly, I would not dare challenge the expertise of our finance team. I know quite a bit about finance, but they blow me out of the water. They're specialized, and undeniably make better decisions than me.
Is it really that much better to feel smart and make average/bad decisions based on intuition? I'm not sure. I think as far as output goes, specializing is better.
[+] [-] halfmatthalfcat|6 years ago|reply
I’m assuming if you _join_ a startup, rather then creating or co-founding one, there’s already a product person on board.
[+] [-] marcinzm|6 years ago|reply
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.
[+] [-] stuntkite|6 years ago|reply
[+] [-] rfeather|6 years ago|reply
[+] [-] longnguyen|6 years ago|reply
[+] [-] ck425|6 years ago|reply
[+] [-] jasode|6 years ago|reply
tldr: try not to be just a "code monkey" but shift your perspective up the value hierarchy so you can provide business solutions. Try not to be an interchangeable and commoditized "cog in the wheel".
IMO, what this essay leaves out is that many people self-select into "product manager" type roles because that's more interesting and fulfilling than coding all day long. On the other hand, other types of programmers prefer to stay "heads down" and just code instead of interfacing with customers.
[0] https://hn.algolia.com/?query=don%27t%20call%20yourself%20a%...
[1] https://news.ycombinator.com/item?id=18227768
[+] [-] thedancollins|6 years ago|reply
[+] [-] onion2k|6 years ago|reply
[+] [-] Aeolun|6 years ago|reply
[+] [-] soulchild37|6 years ago|reply
[+] [-] Dirlewanger|6 years ago|reply
[+] [-] purplezooey|6 years ago|reply
[+] [-] julius_set|6 years ago|reply
It might be good to point out that data driven development is key. A product engineer collect insights with each feature that is created backed BY ACTUAL DATA and not armchair hypothesis
[+] [-] w8rbt|6 years ago|reply
[+] [-] auvi|6 years ago|reply
[+] [-] meabed|6 years ago|reply
[deleted]
[+] [-] draw_down|6 years ago|reply
[deleted]