Tech roles beyond coding

The main roles in software teams whose output is decisions, words or relationships rather than code, and the adjacent roles worth knowing about.

Non-coding tech role

Also called tech jobs without coding, hybrid tech role

What: A job inside a software team where writing production code is not the main output, but understanding how software is built is still required.
Why: These roles need technical literacy plus another strength such as judgement, writing or community skills. People who expect "no technical knowledge needed" struggle quickly.

Watch out

Choosing one of these roles to avoid anything technical; you will still read code, APIs and data every week.

Product manager

Also called PM, product owner

What: The person responsible for deciding what a team builds and why: understanding users and the business, choosing problems worth solving and defining success.
Why: Engineers and designers can build almost anything; the PM helps the team spend its limited time on what matters most and measure whether it worked.
Example: A PM notices many sign-ups never finish onboarding, interviews ten of them, and proposes a shorter flow with a target completion rate.

Watch out

Thinking the PM is the boss of the team. PMs lead through reasoning and trust, not authority.

Technical writer

Also called documentation engineer, docs writer, information developer

What: Someone who creates and maintains documentation such as guides, tutorials, API references and release notes so users and developers can succeed with a product.
Why: Good docs reduce support load, speed up adoption and are often the first thing a developer judges a product by.

Watch out

Believing the job is mostly grammar. Most of it is understanding the product, the reader and the task.

Developer relations

Also called DevRel, developer advocate, developer evangelist

What: The work of helping external developers succeed with a product through content, talks, sample code, community and feedback to the product team.
Why: Developer products spread through trust. DevRel builds it by being useful, and brings real developer pain back inside the company.

Watch out

Seeing DevRel as being paid to travel and tweet. The core is technical teaching and feedback, and it is measured.

Project manager

Also called delivery manager, program manager, scrum master

What: A role focused on delivering agreed work on time: planning, tracking dependencies, risks and communication. Technical program managers do this across engineering teams.
Why: Knowing the difference from product management helps you read job ads: project roles own how and when, product roles own what and why.

Watch out

Applying to "product" roles that are really project coordination, or the reverse, because of the title alone.

Business analyst

Also called BA, systems analyst

What: A role that turns business needs into clear requirements, process maps and acceptance criteria, common in services companies, banks and enterprise IT.
Why: BA roles often hire graduates and build skills that transfer directly to product management.

Solutions engineer

Also called sales engineer, pre-sales engineer, solutions architect, solutions engineering

What: A technical role that helps customers evaluate and adopt a product: demos, proofs of concept, answering technical questions during a sale.
Why: It suits people who enjoy both technology and talking to customers, and it overlaps with DevRel skills.

Customer success

Also called CSM, technical account manager, support engineer

What: Roles that help existing customers get value from a product after they buy it, from onboarding to troubleshooting and renewals.
Why: Support and success teams hear user problems first, which makes them a common route into product, docs and DevRel roles.

Testing role fit cheaply

Also called role fit, test your fit

What: Trying small real tasks from a role before committing to it, such as writing a how-to guide, running two user interviews or giving a short talk.
Why: Job descriptions hide what a role feels like day to day. A weekend of real work tells you more than a month of reading.
Example: Write a README for a classmate's project, interview three users of an app you like, and give a five-minute demo at a study group. Notice which you want to repeat.

Business analyst or product manager

Also called BA vs PM, business analysis vs product management

What: A BA works out what a change must do and makes the requirements clear and testable; a PM decides which problems are worth solving and owns the outcome. In small teams one person often does both.
Why: Job ads blur the two. Knowing the difference tells you what a role will really ask of you, and why BA work is a common route into product.

Watch out

Assuming a BA only writes documents; good analysts spend most of their time with people and data.

BABOK Guide and its knowledge areas

Also called BABOK, IIBA, knowledge areas

What: The BABOK Guide from IIBA describes business analysis in six knowledge areas: planning and monitoring, elicitation and collaboration, requirements life cycle management, strategy analysis, requirements analysis and design definition, and solution evaluation.
Why: It gives you a shared vocabulary with other analysts and is the basis of the IIBA certifications.

Watch out

Treating it as a step-by-step method. It describes tasks and techniques; you still choose what fits the project.

Go deeper