The advice given to anyone interested in technology is to learn to code. Reasonable for people who want to be engineers, misleading for everyone else, because engineering is a minority of the headcount at most software companies. Everything around the product — getting it working for customers, keeping it working, explaining it, testing it, measuring it, policing it — is staffed by people who do not write production code.
These are also the roles where outsiders have the clearest route in, because the scarce skill is not technical depth. It is holding a technical and a business conversation in the same hour without losing either.
The roles, and what they actually are
Technical support
The default entry point and the most underrated. You diagnose faults customers report, reproduce them, and either resolve them or write them up precisely enough for engineering to act on. Senior support engineers do real diagnostic work with logs, APIs and databases. It is also the fastest route to product knowledge, the currency for moving into implementation or solutions work.
Implementation and onboarding
Getting a customer who has just bought the software live: configuration, data migration, integration, training. Part consultancy, part project management, part diplomacy when the customer's own data turns out to be a mess.
Solutions engineering and pre-sales
Showing a prospective customer that the product solves their problem — demonstrations, technical discovery, proofs of concept. It needs enough credibility to be believed by the buyer's engineers and enough commercial sense to know which objections matter.
Data analysis
Answering questions with the company's own data: which customers are at risk of leaving, which feature changed behaviour, where the funnel leaks. SQL is essential, but the difficulty is rarely the query. It is knowing which question is worth asking.
Quality assurance and test
Finding out what breaks before customers do. Manual and exploratory testing remains real work, particularly in regulated products where evidence of testing is a compliance artefact. Test automation pays more and involves scripting, so treat it as a progression, not an entry point.
Technical writing
Documentation, API references, release notes, in-product guidance. The job is understanding something complicated well enough to explain it in the fewest words. Writers with the product's domain background — clinical, legal, financial — are scarcer still.
Product operations
The connective tissue around a product team: release coordination, feedback triage from support and sales into the roadmap, tooling and reporting. Often the route into product management from inside a company.
IT service management
Running internal technology services rather than the product — service desk, access and identity, endpoints, change and incident management, vendor contracts. Structured, well-defined and present in every organisation of any size. ITIL-aligned process is the language.
Trust and safety
Policy, enforcement and abuse prevention for platforms with user-generated content or transactions. Half policy judgement, half operational scale, with fraud, moderation and regulatory compliance alongside each other. Emotionally demanding, and honest employers say so.
| Role | What it involves | Way in |
|---|---|---|
| Technical support engineer | Diagnosing customer faults with logs, APIs and databases | Any service or troubleshooting background |
| Implementation consultant | Configuration, migration and training to get a customer live | Project coordination or operations plus domain knowledge |
| Solutions engineer | Technical discovery, demos and proofs of concept | Support or implementation; occasionally the customer side |
| Data analyst | SQL, dashboards and the judgement to ask the right question | Any numerate role; SQL and one visualisation tool |
| QA analyst | Exploratory and structured testing, defect reporting | Detail-heavy admin or operations backgrounds |
| Technical writer | Documentation, API references and in-product guidance | Writing or teaching background plus a portfolio |
| Product operations | Release coordination, feedback triage, tooling and reporting | Usually internal transfer from support or QA |
| IT service manager | Service desk, access, change and incident management | Service desk upward; ITIL-aligned process knowledge |
| Trust and safety analyst | Policy enforcement, moderation, fraud and abuse investigation | Compliance, investigation, legal or customer operations |
Which backgrounds transfer
Four groups move into these roles regularly, consistently enough to plan around it.
- Customer-facing service and operations. Contact centres, retail management, claims handling. Transfers into support and QA almost directly: the scarce part — staying calm and precise with an angry person while working out what is wrong — you already have.
- Teaching and training. Transfers into technical writing, onboarding and enablement. Explaining something difficult to someone who does not want to hear it is the whole job.
- Regulated and administrative professions. Healthcare administration, insurance, banking operations, legal support. Transfers into implementation, trust and safety, and any product sold into your old sector.
- Numerate roles outside technology. Finance, logistics planning, research. Transfers into data analysis once SQL is in place.
What to learn first
Pick the role, then learn the one thing that gates it: SQL for analysis, a working understanding of APIs and how to read a log for support and solutions, a written sample or documentation portfolio for technical writing, and ITIL-aligned process vocabulary for service management. Each is a few weeks of deliberate effort, not a degree — and none of them is a programming language.
Pay, progression and the honest trade-offs
These roles pay a premium over equivalent-seniority work in retail, hospitality or general administration, and less than software engineering at the same level. Solutions engineering and data analysis sit at the higher end, support and QA at the entry end with a steep early curve.
Progression runs two ways: deeper into the specialism, or sideways after two years into product management, customer success or operations. The sideways move is the common one, and it is why support deserves to be taken seriously as a start rather than a consolation.
The thing technology companies cannot hire easily is someone who understands the customer's world and is not frightened of the product. Neither half requires code.
One market note: remote hiring for support, QA and technical writing is more established than in most functions, which widens the field but means you compete beyond your own city. In regulated sectors — health, finance, defence — background checks and data-residency rules often require candidates in a specific jurisdiction, which works in your favour if you are in it.