Ask HN: Career paths to consider if I am better at supporting than creating?

1 points by _override ↗ HN
I have a BS/MS in computer science and somewhere around 9 years of experience, where the first half was spent working as a backend developer and the second half I've been working in product owner roles. I switched from development to product because I simply realized that I wasn't very good at implementation and system design work to be honest. I wanted to work with tech from a more overarching level, and let the experts who were much more skilled than me handle the implementation work.

Around 8 months ago I switched companies and am still working as a PO, but this organization I am working in is a terrible fit for me. I don't want to go too far into why I really dislike this job, but a big part of it is that the organization wants me to make technical design decisions which I am just really not good at, since the development team doesn’t have this experience themselves. This is making it completely impossible to deliver on the project I’m responsible for.

This has really made me think about what I should do for my next role. I fully admit that I was and still am a mediocre developer, which is why I moved into a PO role in the first place around 4 years ago. I have such a huge amount of respect for people who are great developers and architects. It's a challenging role and I can imagine it's exciting if you are creative and like to build new things. But I am just not cut out for it. I am not very creative, and I often have no clue where to even start when I need to build new things.

The parts I've enjoyed the most in the various roles in my career have been things like: - 2nd/3rd line ticket management and troubleshooting. It's been quite fun going through logs and trying to figure out what went wrong, perhaps trying to recreate the situation in a test environment with an API client. - Supporting customers. For example helping customers with installations of software. It honestly gives me a huge sense of accomplishment when I get to see a customer making use of our products, and helping them investigate why something may not be working. - Being an interface between business and tech. I've always thought of myself as someone who is able to understand both business needs and technical needs quite well. Even though I'm not good at implementing software, I can understand limitations of software, read and understand existing codebases, and so on. - Testing software. It's a lot of fun to test software to see if there are any issues before we go live! - Just working with people in general! I really like to do whatever I can to support my team and the people that I work with.

I thought I'd ask for some advice to see if you guys have any recommendations for career tracks to consider, given that I am just much more comfortable supporting existing software than building new software. I like working with people. I like achieving results. I'm just not cut out for system design and building new software.

Honestly it might mean that I need to live with a lower salary, and that is fine with me. To be completely honest, given the fact that my current role is genuinely making me sick with severe anxiety (made a post about this a while back [1], I've learned that money isn't everything. There isn't a point to making more money if my job is literally killing me and I am losing my health. I'd much rather work with something I enjoy that isn't making me feel sick. Life is too short.

Thanks for reading this. I really appreciate any advice or thoughts you may have.

[1] https://news.ycombinator.com/item?id=49533073

29 comments

[ 87.4 ms ] story [ 64.7 ms ] thread
Sounds like you may enjoy being a QA engineer. Good QA engineers are a really really good value add to a software team and can really save our ass. Technical QA engineers understand why things break, and are easy to coordinate with when preparing a larger release.

At my previous employer, the head QA engineer was the one pushing back at the PM when they were too ambitious. They basically owned the current "Is the next release still a buggy mess?" state.

Perhaps a sales engineer?

> I am just much more comfortable supporting existing software than building new software.

Having technical skills is required, but you'd be doing little to no coding or design work.

> Being an interface between business and tech.

A sales engineer matches this almost by definition.

> Just working with people in general!

The job is essentially entirely about working with people, both with the customers you're trying to sell to, and with the developers who are actually making the product.

This also has the added benefit of making a lot of money even by engineering standards in the right organization. Looks for large enterprise companies where custom demos and new customer hypercare are standard. I've been on the other side of the table a few times and often pre-sales cycles are months long and contracts start in the $2-4M range. Those are the places where sales engineers will be treated as first-class citizens and not just "hey grab one of the engineers for this sales call."
I think I can second this. I was offered an FAE job (essentially the sales engineer of hardware) and they were going to pay me more money to write no code and spend most of my time in the road talking to people about products. But I like writing code. Presumably a great job for somebody who doesn't/can't.
This is honestly a career path I’ve never really considered, but after reading about it a little bit the role sounds like it would be right up my alley. I’m going to explore the market for sales engineers here in Sweden and see what kinds of roles are available. Thanks for your comment.
Do you usually need experience in sales to land a sales engineer job?
Developer Experience is gaining in popularity. Your clients are internal and your objective is to remove obstacles, create shortcuts, keep everyone happy and productive. Lots of it is communication, finding out everyone's pain points and discussing what is technically feasible to ease that frustration - so that may tickle your people/support string. Things that are/can be part of DevEx are DevOps/Platform Engineering/Infra/CI/CD, QA, IdP, internal frameworks, onboarding, etc. Fun stuff imo.
> Wanted to work with tech from a more overarching level

> I get a huge sense of accomplishment seeing customers user our product’

> Interface between business and tech

You might like trying your hand in Professional Services either at a System Integrator like Deloitte or first-party in a product company (now often re-labelled as ‘forward deployed engineers’).

Their main problem space is getting customers to successfully use the product through marrying your understanding of the tech’s limitations and sweet spots with the customer’s organizational goals and culture, so daily work revolves less around deep technical design and more about org alignment and strategy (which is why SIs sometimes get a bad rap on a tech forum like HNews).

It probably pays less, and it can be more stressful when you’re billing for (and justifying) every hour, but in my experience the way it tends to be more dynamic (new projects+teams+customers often) and how you get to see very direct impact is quite rewarding.

What about testing / QA / reliability? Plenty of such positions. Not particularly competitive to get into, as many view those jobs as "lesser" jobs.

Software sales engineering could be another, which probably also pays more. But, alas, more competitive.

We're in the AI era now, every job is a supporting role.
Modern big tech software engineering is 98% supporting and maintaining.
AI does this really well, even better than new development. I regularly use Github copilot to automatically read production logs from the app and backend services, find errors logs, deeply scan the codebases, create theories about the issue, verify the theory matches production evidence, verify the theory in a sandbox env, create a failing test, and then suggest a minimal code change in a feature branch, verify in a sandbox, verify test is passing now, and submit a pr, along with a detailed analysis doc and any future design optimizations to fix the class of error.
Solutions architect post-sale fits better if you hate quotas. Same work, calmer.
(comment deleted)
If you have a secondary interest or hobby or real-world-knowledge about what consumers in a certain category want - you might be a good product manager in that field.

Many products require technical product managers.

Being people oriented and a "mediocre" technical engineer is not really a hinderance and can make your focus better aligned customer needs in a high level, not getting nerd-sniped on things that don't matter.

I suspect that engineers would prefer working under someone like you who doesn't have a god-like ego, and is likely to resolve conflicts between people.

I have a coworker who is incredible at the job it sounds like you want. The "keep customers happy" role. It's a massively important role in a company. It's part product support, part sales support and part product owner.

2026 has made him way more useful to us engineers. Before he used to send us tickets. Sometimes we delivered what the customer really wanted because of those tickets, and sometimes we needed a few iterations.

Now he uses AI to deliver pull requests that include full repro environments. These are slop, of course. Sometimes we can approve them almost unchanged. But more often they need to be completely rewritten. But even the latter is super valuable as a much more concrete representation of the bug or customer request than a ticket was.

your skillset sounds like perfect match for technical presales engineer ... you need to work at an enterprise software company, where they sell big tickets software of tens of thousands of dollar service, so you're part of the ensemble, but the sale is big enough and technical enough that they have a pre-sales engineering team. You are 50% customer, 50% medium intensity technical but you just use/config/troubleshoot without being the engineer responsible for building
I'll be blunt rather than couch it: all the things you've listed will make you a ralph loop target in the org. You are adding human in the loop where the industry is moving in the opposite direction.

This is generally true across all roles, but first impact will be working that is more trivial for an agent or n8n flow.

So consider this and pick roles wisely, where you can see this existing for a bit. All the best.

I find this a very engineering/technology focused point of view. Most business related functions run on this “human in the loop” with zero hints from industry this will change anytime soon - quite the opposite.

Even if we take purely engineering, support and operations functions, there is still plenty of “human glue” in the organizations that allow for them to function - the larger the org, the more often you need to interface people between each other, and corner cases become more complex.

Big Tech which is the most vocal about their technological savviness is a great example: pretty much nothing has changed on business and cross-functional side since the 90th and earlier, all key decisions are made via Powerpoint, memos and personal contacts. Jeff’s innovation of preparing and reading a one page of problem statement and proposal at the beginning of a meeting was considered breakthrough in this field. No LLM in sight that can magically fix this [semi-ironically] beautiful mess.

And don’t get me started on B2B Sales and Partnerships.

> I am just much more comfortable supporting existing software than building new software.

> It honestly gives me a huge sense of accomplishment when I get to see a customer making use of our products, and helping them investigate why something may not be working.

> I've learned that money isn't everything.

Put this at the top of your resume, send it around to a few headhunters and see what comes back.

Many (most?) developers are not very interested in supporting someone else's work. The customer seems to get it even worse. AI has turned the ego trips up to 11. You have an advantage if you genuinely feel this way about these topics and can sell that feeling to others.

A few years into my career I realized that I was not cut out to code. Luckily I worked for a good employer and they told me that code was 5% of the business regardless of what the sign over the door said. Over the next 20 years I spent time doing QA, tech support, product management, professional services, and sales engineering.

Rightly or wrongly there is a hierarchy of job roles and QA and tech support are low down on that list. But if you want to stay in the industry that your org serves (eg healthcare, energy, telecom etc) they are good ways to gather real industry experience.

Product is hard but devs do appreciate someone who can clearly tell them what is needed without micromanaging them (and tell the customer what is possible and what is not).

Pro services is great if you have good human skills but it can be a tough sell (some orgs treat it like a body shop, some customers think they dont need it, some sales orgs throw it in for free meaning you are underwater immediately).

Sales Engineering can be lucrative and fun, but only if you are paired up with a good sales team that doesnt treat you like a demo and slideware robot.

Smaller or faster growing companies often need versatile people that can speak to customers and developers.

Or find a tiny niche where you can leverage technology to make a customer life easier. Then do that for more customers.

Or experiment in a consultant capacity outside of the day job.

Stepping back to big picture, your comments about versatility and helping the customer scream small business opportunity rather than big corporate.

And when I say small I think that’s a great thing (autonomy, financial independence) in contrast to Silicon Valley venture capital culture.

* Business analyst and Scrum Master

* Test Automation Engineer

If you want to remain technical I strongly advocate for the second option. It can be super technical and if you end up in an organization where the primary developers suck at what they do (or their management keeps them locked up as infants) you can end up doing more engineering than the developers you are supporting.

Someone mentioned PS, also consider if this new FDE thing is for you in that case.

Some other people suggested QA, if you enjoy interfacing with customers I would also suggest you look into the PM role.