Ask HN: What to do as a software engineer that cares more about what to build?

[oncethere]

I've been an engineer for many years and it's become pretty clear that What a team chooses to build (or not) has far more impact than the architecture / code design choices. Nowadays the role feels like someone else figures out what to build, and we just code it up.

I love coding, but I've gotten to the point where I just can't enjoy it if I'm not involved also choosing what we build. The most interesting time in my career was when I did the spec, architecture, and code of a pretty fundamental system (small team, just lost the PM, fell to me as tech lead). The worst time was contributing for a number of years to a large software platform that had incredible groundbreaking tech and fundamentally failed in the marketplace.

It seems my only choices are to 1.) be a PM and stop coding or 2.) find a team where engineering also makes product decisions

Has anyone else successfully navigated this dilemma?

PS I've had the same experience as an engineering manager - less coding, no real responsibility for what the team chooses to build.

[Epenthesis]

The easiest way to do this is to go to a small company where everyone wears multiple hats. 50 people is probably the upper limit.

[theoblank]

I agree with this as well. Around 50 people (maybe even 40) companies are required to start operating in a more bureaucratic way, and more often than not this means there's a top-down approach where software developers are just doing what they're told rather than influencing what gets built.

[mooreds]

Came here to say this. Go to a small product company in a domain you are interested in.

Consulting companies are ok, but there you pretty much build what clients want. If you can find one that focuses on an interesting domain, that can be a good fit.

At small companies you get to be part time product manager, project manager, customer support, QA, developer, doc writer, and more. Especially if you are relatively senior.

For some folks I know, this is a nightmare. I personally love it. Give it a go!

How can you find such small companies? I'd look in the "Who's hiring" threads and on sites like https://www.builtincolorado.com/ (if they exist for your area). Also, ask in your network.

[d--b]

Seconded. 50 people is a good round upper limit.

[markus_zhang]

I think Paul Graham has an excellent article named Hacker and Painter regarding this. I think the only way is to develop your own products.

So far I habe worked in a few companies as a business analyst and a bi developer but I have never seen one that allows the dev team to have some final say in the products. Products are always dictated by business team, then project manager or business analyst breaks them down to tickets that you guus understand, i. e. the scope. The lead further breaks them dowm into sprints and tickets.

So you can see that sometimes even product managers don't have much a say in the product.

[oncethere]

Thanks for the pointer to the article!

Yeah, that's a good point. The PM is sometimes pretty constrained by the business. Maybe it's just a grass is greener thing. Have you been anywhere where the eng team had some say in what they make?

[Twixes]

Currently working at PostHog, an engineering-centric product-led startup (20-odd people currently) all our engineering teams fully own an aspect of the product and prioritize themselves. Obviously there's company-wide context and company leadership has crucial input, but since hiring optimizes for maximally self-sufficient people, there's no PMs. I'm a big fan of that as an engineer

[markus_zhang]

Sorry I have never seen one such place. I mean for sure in each place I stayed (custom service center, gaming and one I can't say), the eng team has SOME say in the product, but most od the time it's just small details of the design or something similar that they can argue about. Actually data analysts have a lot more say because they have the data to back them up when they want to make recommendations.

[tppiotrowski]

Get in the habit of asking: "What is the problem?"

CEO - "We need a live streaming video platform"

Me - "What is the problem?"

CEO - "I want to do a webcast on our website"

Me - "Would embedding a YouTube video player work? It does x, y and z and it can be ready by tomorrow"

CEO - "Oh! I hadn't considered that"

You need to get back to first principles. Usually your boss wants to accomplish something and then they come up with a solution. Then they fall in love with the solution, not the problem.

You should be asking your boss what they're trying to accomplish instead of letting them propose the solution. If you help devise the solution/product you'll be much happier building it.

[quickthrower2]

Never that simple at a macro level. Business will claim more knowledge of the “market” and are probably right if they have got feedback from customers. “We need to build X as part of our strategy”

Sure you can choose to use nodejs instead of ruby or embed video instead of streaming it yourself or find a better confit system than admin pages but the entire product ideas are probably decided by the business well in advance of when the developer gets whiff of it.

Imagine you are about to purchase a car and the car dealer weirdly tries to convince you to take up cycling via “what’s the problem”. You’d probably walk to the next dealer as you’ve made up your mind you want a car.

[tppiotrowski]

Maybe it's more of a startup thing. Another startup I worked at turned their entire website into an SPA over the course of 12 months. The website was never broken. It wasn't sleek but it worked. I kept my head down and rewrote it.

The email order confirmations, however, took 30 minutes to be delivered to customers. In the end, it was this uncertainty of whether an order went through that killed the customers trust, not the fact that it was not an SPA. I wish I had asked more questions instead of blindly following orders.

[oncethere]

Haha. Yes, I do that potentially a bit too much. It always feels like pulling teeth -- like the official process doesn't have room for that kind of back and forth. For example, in scrum, the product owner is meant to have that conversation, not the engineers.

[karmakaze]

> I love coding, but I've gotten to the point where I just can't enjoy it if I'm not involved also choosing what we build.

Would it be sufficient if what is chosen to be built is something you see as a high-value thing to build? Working at a company that is good at setting product directions could be a possible solution.

[afarrell]

When you interview, make sure you talk to PMs. Also, network at places like Mind the Product.

[oncethere]

Does anyone else feel this way? Curious about your experience and what works for you. I know lots of engineers that are super happy working against solid requirements.

[throwaway4233]

I have worked with 3 types of PMs during my time as an engineer as well as a lead.

1. The one who tries to reinvent the product and you tend to end up questioning their design or product decisions because they seem flaky and makes no sense. Being a newly promoted lead with my own ideas I was often at loggerheads with them. For anyone who reads this and is in the same position, I would suggest to continue building what the PM asks you to do. Any opposition or pushback you create regarding their choices will just lead to chaos for your team and in the end you would have to go with it since their role is the one making such decisions.

2. The one whose requirement are empty shells waiting to be filled with the questions raising by the people they present it to. I would suggest to get away as far as possible since your requirements will never remain fixed as the PM will be open to suggestions and influences from all over the company and you would end up with a rube goldberg machine.

3. PMs who take time to do research, write down solid requirements, convince stakeholders and also have a iteration based release plan in mind. I worked with only 2-3 PMs like this and based on what I saw, they tend to burn out faster than you do and either quit or regress to type 1 or type 2 just to get the release out.

Having said all this, I would rather be happier working with solid requirements rather than making them. I have played the role of a PM temporarily and found that it is generally a thankless job, regardless of the effort you put in.

[quickthrower2]

I do too. There is something about building your own idea that’s magic. Even partially magic is given the “we need an x” but deciding on the technical and visual design. Team work is probably more effective here: graphic designer. UX, product managers etc. at producing the polished results we expect in the 2020s but man … why are we drawn to side projects? The urge to build from the ground up is strong.

[bobm_kite9]

Hell yes. After 20 or more years doing this, you build a reasonable bullshit filter. A lot of the time, if the ask doesn’t pass that filter I find it very, very hard to commit. It’s hard enough being useful without that. Life is too short to be wasting it on building something you know is d destined for the bin.

[jbjbjbjb]

I think the majority (80% I’d guess) prefer to have the requirements come from someone else. To be honest I’ve worked with many people who would always say there isn’t enough ‘design’, as if the classes and methods should be written out for them and do as little thinking as possible.

[zeroc8]

I love the idea of "hands on product management", where you are both the product manager and one of the developers. The difficulty is finding a balance between passion and financial wisdom.

[jf22]

I think all humans want to feel like they've had an impact and that their work is valuable.

[barrysaunders]

third option is to go and work somewhere that builds software that helps people make product decisions - think a Dovetail, Figma, Atlassian etc. Your perspective will make you an effective engineering leader!