Los roles de una empresa de software, explicados sin vueltas

Publicado el 2026-09-12 por 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.

Los títulos en esta industria son un caos. La misma persona puede llamarse Tech Lead en una empresa, Staff Engineer en otra y "el que sabe" en una tercera.

Como los nombres no ayudan, conviene mirar otra cosa: qué pregunta contesta cada rol. Eso sí es estable.

Alrededor del producto

Product manager. Contesta qué construimos y por qué. Habla con usuarios, mira datos, decide prioridades. Su trabajo más importante y menos visible es decir que no: sin eso, el producto se convierte en una lista de pedidos.

Project manager / delivery. Contesta cuándo llega y qué está trabado. Planifica, ordena, coordina entre equipos, destraba dependencias.

Esta es la confusión que más caro sale, y vale detenerse: son dos preguntas distintas. Cuando una sola persona hace las dos, lo que casi siempre pasa es que la fecha empieza a decidir el alcance, en vez de al revés.

Product owner. En equipos que usan Scrum, es quien prioriza el backlog. Suele solaparse con el product manager; en algunas empresas es la misma persona con otro nombre.

Alrededor del diseño

UX / Product designer. Cómo se usa. Flujos, estructura, qué pasa cuando algo falla, qué ve alguien que entra por primera vez.

UI / Visual designer. Cómo se ve. Tipografía, color, espaciado, componentes.

En equipos chicos son la misma persona. Vale la distinción porque son habilidades diferentes: alguien puede hacer pantallas hermosas que son un laberinto, y alguien puede diseñar un flujo impecable que se ve feo.

Alrededor del código

Frontend, backend, full stack. La división que ya tratamos: uno trabaja en lo que corre en el navegador, otro en lo que corre en el servidor, el tercero cruza.

DevOps / SRE / Platform. Cómo se despliega, cómo se monitorea, cómo se recupera. El nombre cambia y el foco también: DevOps es más cultural (que desarrollo y operaciones no sean dos mundos), SRE viene de Google y pone el acento en confiabilidad medida con números.

Tech lead. Decide cómo se construye: arquitectura, estándares, qué deuda se paga y cuál se posterga. Suele seguir escribiendo código.

Engineering manager. Se ocupa de las personas: crecimiento, conflictos, contrataciones. Es un rol distinto del anterior, aunque muchas empresas los mezclen con malos resultados.

QA. Cómo se rompe. No es "el que prueba al final": un buen QA participa desde que se define la funcionalidad y hace preguntas incómodas antes de que se escriba una línea.

Lo que pasa cuando un rol no existe

Este es el punto que más vale del artículo.

En un equipo chico es normal no tener todos los roles. Lo que no es cierto es que el trabajo desaparezca. Lo absorbe alguien, casi siempre sin tiempo ni formación para eso:

• Sin rol de producto: las prioridades las decide quien programa, basándose en intuición y en quién insistió más fuerte.
• Sin rol de diseño: la interfaz termina siendo un reflejo del modelo de datos. Funciona y no se entiende.
• Sin QA: los usuarios prueban. En producción.
• Sin nadie de infraestructura: el despliegue lo sostiene una persona, y ese conocimiento no está escrito.

Saber qué rol falta no obliga a contratar. Pero permite decir "esta parte la estamos haciendo mal a propósito", que es muy distinto de no darse cuenta.

Un apunte sobre equipos de dos o tres

En un equipo muy chico, una persona hace de todo. Lo que funciona no es fingir que los roles no existen, sino ponerse el sombrero a propósito: "ahora estoy decidiendo qué construir" es un momento distinto de "ahora estoy decidiendo cómo construirlo".

Separar esos momentos, aunque sea la misma persona, mejora bastante las dos decisiones.