The roles of a software company, explained straight to the point
Published on 2026-09-12 by frfrand
Qué hace realmente cada uno, por qué los títulos varían tanto entre empresas, y qué pasa cuando un rol no existe: el trabajo no desaparece, lo absorbe alguien peor preparado.
Titles in this industry are a mess. The same person can be called a Tech Lead at one company, a Staff Engineer at another, and "the one who knows" at a third.
Since names don’t help, it’s better to look at something else: what question each role answers. That is stable.
Around the product
Product manager. Answers what we build and why. Talks to users, looks at data, decides priorities. Their most important and least visible job is saying no: without that, the product becomes a list of requests.
Project manager / delivery. Answers when it arrives and what’s blocked. Plans, organizes, coordinates between teams, unblocks dependencies.
This is the confusion that costs the most, and it’s worth pausing on: they are two different questions. When one person does both, what almost always happens is that the date starts deciding the scope, instead of the other way around.
Product owner. In teams using Scrum, this is the person who prioritizes the backlog. They often overlap with the product manager; in some companies, it’s the same person with a different title.
Around design
UX / Product designer. How it’s used. Flows, structure, what happens when something fails, what someone sees when they first encounter it.
UI / Visual designer. How it looks. Typography, color, spacing, components.
In small teams they are the same person. The distinction is worth making because they are different skills: someone can make beautiful screens that are a maze, and someone can design a flawless flow that looks ugly.
Around the code
Frontend, backend, full stack. The division we already discussed: one works on what runs in the browser, another on what runs on the server, the third crosses both.
DevOps / SRE / Platform. How it is deployed, how it is monitored, how it is recovered. The name changes and the focus shifts too: DevOps is more cultural (so development and operations are not two separate worlds), SRE comes from Google and emphasizes reliability measured with numbers.
Tech lead. Decides how it is built: architecture, standards, what debt is paid and what is postponed. Usually continues writing code.
Engineering manager. Takes care of people: growth, conflicts, hiring. It is a distinct role from the previous one, although many companies mix them with poor results.
QA. How it breaks. It is not "the one who tests at the end": a good QA participates from when functionality is defined and asks uncomfortable questions before a single line of code is written.
What happens when a role does not exist
This is the most valuable point of the article.
In a small team it is normal not to have all the roles. What is not true is that the work disappears. It gets absorbed by someone, almost always without time or training for it:
- No product role: priorities are decided by whoever programs, based on intuition and whoever insisted the most.
- No design role: the interface ends up being a reflection of the data model. It works and it's not understood.
- No QA: users test. In production.
- No infrastructure person: deployment is sustained by one person, and that knowledge is not written down.
Knowing which role is missing does not force hiring. But it allows saying "we are doing this part wrong on purpose," which is very different from not realizing it.
A note on teams of two or three
On a very small team, one person does everything. What works is not pretending that roles do not exist, but putting on the hat on purpose: "now I am deciding what to build" is a different moment from "now I am deciding how to build it."
Separating those moments, even if it is the same person, improves both decisions quite a bit.
