Plantilla de escalera de carrera

Plantilla de escalera de carrera para ingenieros de software

Cinco niveles de júnior a principal y seis competencias, desde entregar código hasta hacer crecer al equipo.

Plan gratuito · Sin tarjeta de crédito

Esta escalera de carrera está pensada para empresas de producto de unas 20 a 200 personas: los ingenieros llevan las funcionalidades de principio a fin, los equipos son pequeños y nadie en RR. HH. está diseñando una arquitectura de puestos. Describe cinco niveles, desde alguien que empieza su carrera hasta alguien que marca la dirección técnica de toda la empresa. Su nivel más alto, Ingeniero principal, es un nivel de especialista; la gestión de ingenieros se cubre en la escalera de carrera de Engineering Manager, que es independiente.

Cada nivel se define por lo que hace la persona, no por los años de experiencia. Lee una fila de la matriz de competencias de izquierda a derecha para ver cómo crece una expectativa; lee la sección de un nivel para ver de un vistazo todo lo que se espera en él. Úsala para explicar qué significa el siguiente nivel, para estructurar autoevaluaciones y check-ins, y para que las propuestas de ascenso sean comparables entre equipos.

Tómala como punto de partida. Cambia el nombre de los niveles para que coincidan con los puestos de tu empresa, fusiona o elimina las competencias que no encajen en tu empresa y reescribe las expectativas con tus propias palabras antes de publicar la escalera para el equipo.

Los niveles de un vistazo

Ingeniero júnior
Aprende el código base y entrega tareas bien definidas con orientación.
Alcance
Tareas concretas en un área del producto, normalmente desglosadas por alguien con más experiencia.
Ingeniero
Entrega funcionalidades de forma autónoma y es un miembro fiable del equipo.
Alcance
Funcionalidades pequeñas y medianas dentro del área de un equipo, desde una breve nota de diseño hasta producción.
Ingeniero sénior
Lidera trabajos de mayor envergadura y eleva el nivel del equipo que le rodea.
Alcance
Proyectos que abarcan varios servicios o varias personas, y las decisiones técnicas de un equipo.
Ingeniero staff
Resuelve problemas que cruzan los límites entre equipos y orienta decisiones técnicas más allá de un solo equipo.
Alcance
Varios equipos o toda un área de producto, incluidos los problemas que no pertenecen a ningún equipo en concreto.
Ingeniero principal
Marca la dirección técnica de la empresa y responde de su salud técnica a largo plazo.
Alcance
Toda la organización de ingeniería y la estrategia técnica de la empresa para los próximos años.

Matriz de competencias

Cada fila es una competencia y cada columna, un nivel. Lee una fila de izquierda a derecha para ver cómo crece lo que se espera.

Qué significa cada competencia

Entrega técnica: Convertir los requisitos en software que funciona y se puede mantener, y hacerlo llegar a los usuarios.
Diseño de sistemas: Elegir estructuras, interfaces y compromisos que aguanten a medida que crece el producto.
Calidad y fiabilidad: Mantener el producto correcto, observable y disponible, y aprender de los fallos.
Colaboración y comunicación: Trabajar de forma eficaz con otros ingenieros, con producto, con diseño y con el resto del negocio.
Responsabilidad e impacto en el producto: Entender por qué importa el trabajo y responsabilizarse de los resultados, no solo de las tareas.
Mentoría y desarrollo del equipo: Ayudar a otros a mejorar y hacer que el equipo sea más fuerte que cualquiera de sus miembros.

Ingeniero de software: expectativas por competencia y nivel
Competencia	Ingeniero júnior	Ingeniero	Ingeniero sénior	Ingeniero staff	Ingeniero principal
Entrega técnica	Completa tareas bien acotadas con código legible y tests, pide ayuda tras unas horas atascado y no tras varios días, y resuelve los comentarios de la revisión antes de hacer merge.	Lleva una funcionalidad desde una breve nota de diseño hasta producción sin que nadie le lleve de la mano, la divide en pull requests fáciles de revisar y da estimaciones realistas para trabajo conocido.	Entrega proyectos que abarcan varios servicios o colaboradores, ordena el trabajo para que algo útil salga pronto y elimina los riesgos antes de que bloqueen al equipo.	Desbloquea la entrega entre equipos: desenreda dependencias compartidas, construye las herramientas o ejecuta las migraciones que necesitan varios equipos, y mantiene encauzados los proyectos multiequipo.	Da forma a cómo entrega software toda la organización (prácticas de release, elecciones de plataforma, herramientas de build y despliegue) para que cada equipo entregue más rápido y con más seguridad.
Diseño de sistemas	Sigue los patrones existentes en el código base y sabe explicar por qué el código que ha cambiado está estructurado así.	Diseña componentes dentro de un servicio existente, escribe una breve nota de diseño para los cambios no triviales y compara al menos dos opciones antes de elegir una.	Lidera el diseño de funcionalidades que abarcan varios servicios, deja por escrito los compromisos para que otros los revisen y revisa los diseños de otros ingenieros de forma constructiva.	Define la arquitectura más allá de los límites de cada equipo (modelos de datos compartidos, contratos entre servicios, decisiones de construir o comprar) y anticipa cómo tendrá que cambiar el sistema en el próximo año o dos.	Es responsable de la estrategia técnica de la empresa: en qué tecnologías apostar, cuáles retirar y cómo debe evolucionar la arquitectura junto con el negocio a lo largo de varios años.
Calidad y fiabilidad	Escribe tests para sus propios cambios, revisa su trabajo antes del release y corrige los bugs del código que ha tocado.	Añade monitorización y alertas a las funcionalidades que construye, participa en las guardias y gestiona los incidentes rutinarios siguiendo el runbook.	Lidera la respuesta a incidentes en los sistemas del equipo, escribe post-mortems sin culpables y se asegura de que las acciones de seguimiento se completan de verdad.	Detecta riesgos de fiabilidad y seguridad que afectan a varios sistemas, fija estándares como la estrategia de testing y los objetivos de nivel de servicio, e impulsa las correcciones entre equipos.	Define qué significan la fiabilidad, la seguridad y la calidad para la empresa, las equilibra con la velocidad junto con el equipo directivo y es el último punto de escalado en los incidentes más difíciles.
Colaboración y comunicación	Comparte abiertamente sus avances y bloqueos, y hace preguntas claras cuando un requisito no está claro.	Trabaja directamente con producto y diseño para aclarar requisitos, explica las limitaciones técnicas en un lenguaje sencillo y escribe descripciones de pull request que los revisores pueden seguir.	Representa al equipo en la planificación, negocia alcance y compromisos con producto y escribe documentos que entiende la gente de fuera de ingeniería.	Alinea a varios equipos y funciones en torno a un plan técnico, resuelve desacuerdos entre equipos y explica el riesgo técnico a la dirección.	Es una voz de confianza en las decisiones de la empresa, traduce la estrategia de negocio en dirección técnica y viceversa, y representa a ingeniería ante clientes, socios o inversores cuando hace falta.
Responsabilidad e impacto en el producto	Entiende el propósito de sus tareas, comprueba que lo que ha entregado funciona para los usuarios y hace seguimiento hasta que funcione.	Se hace cargo de una funcionalidad tras el lanzamiento: vigila su uso y sus errores, corrige lo que falla y propone mejoras a partir de lo que aprende.	Es responsable de un área del producto de principio a fin, cuestiona los requisitos que no sirven a los usuarios y propone trabajo que hace avanzar los objetivos del equipo.	Encuentra los problemas de mayor impacto en un área de producto, incluidos los que ningún equipo ha asumido, y se asegura de que se resuelvan.	Conecta la inversión en ingeniería con los resultados de la empresa y defiende o rechaza las grandes apuestas según su impacto técnico y de negocio.
Mentoría y desarrollo del equipo	Pide feedback y actúa en consecuencia, y deja por escrito lo que ha aprendido para que la próxima persona que llegue lo tenga más fácil.	Hace revisiones de código cuidadosas, ayuda a incorporar a nuevos compañeros y trabaja en pareja con ingenieros júnior en partes del código que no conocen.	Ejerce de mentor de uno o dos ingenieros de forma deliberada, les da feedback que les ayuda a llegar al siguiente nivel y participa en entrevistas de selección.	Hace crecer a ingenieros sénior de distintos equipos, da forma al proceso de entrevistas y a las prácticas de ingeniería, y es alguien a quien los demás acuden en busca de consejo.	Construye la cultura técnica de la empresa (cómo se toman las decisiones y cómo se comparte el conocimiento) y forma a la próxima generación de ingenieros staff.

Desplaza la tabla hacia los lados para ver todos los niveles.

Descargar en CSV Se abre en Excel, Google Sheets o Numbers.

Ingeniero júnior: qué se espera

Aprende el código base y entrega tareas bien definidas con orientación. Tareas concretas en un área del producto, normalmente desglosadas por alguien con más experiencia.

Entrega técnica: Completa tareas bien acotadas con código legible y tests, pide ayuda tras unas horas atascado y no tras varios días, y resuelve los comentarios de la revisión antes de hacer merge.
Diseño de sistemas: Sigue los patrones existentes en el código base y sabe explicar por qué el código que ha cambiado está estructurado así.
Calidad y fiabilidad: Escribe tests para sus propios cambios, revisa su trabajo antes del release y corrige los bugs del código que ha tocado.
Colaboración y comunicación: Comparte abiertamente sus avances y bloqueos, y hace preguntas claras cuando un requisito no está claro.
Responsabilidad e impacto en el producto: Entiende el propósito de sus tareas, comprueba que lo que ha entregado funciona para los usuarios y hace seguimiento hasta que funcione.
Mentoría y desarrollo del equipo: Pide feedback y actúa en consecuencia, y deja por escrito lo que ha aprendido para que la próxima persona que llegue lo tenga más fácil.

Ingeniero: qué se espera

Entrega funcionalidades de forma autónoma y es un miembro fiable del equipo. Funcionalidades pequeñas y medianas dentro del área de un equipo, desde una breve nota de diseño hasta producción.

Entrega técnica: Lleva una funcionalidad desde una breve nota de diseño hasta producción sin que nadie le lleve de la mano, la divide en pull requests fáciles de revisar y da estimaciones realistas para trabajo conocido.
Diseño de sistemas: Diseña componentes dentro de un servicio existente, escribe una breve nota de diseño para los cambios no triviales y compara al menos dos opciones antes de elegir una.
Calidad y fiabilidad: Añade monitorización y alertas a las funcionalidades que construye, participa en las guardias y gestiona los incidentes rutinarios siguiendo el runbook.
Colaboración y comunicación: Trabaja directamente con producto y diseño para aclarar requisitos, explica las limitaciones técnicas en un lenguaje sencillo y escribe descripciones de pull request que los revisores pueden seguir.
Responsabilidad e impacto en el producto: Se hace cargo de una funcionalidad tras el lanzamiento: vigila su uso y sus errores, corrige lo que falla y propone mejoras a partir de lo que aprende.
Mentoría y desarrollo del equipo: Hace revisiones de código cuidadosas, ayuda a incorporar a nuevos compañeros y trabaja en pareja con ingenieros júnior en partes del código que no conocen.

Ingeniero sénior: qué se espera

Lidera trabajos de mayor envergadura y eleva el nivel del equipo que le rodea. Proyectos que abarcan varios servicios o varias personas, y las decisiones técnicas de un equipo.

Entrega técnica: Entrega proyectos que abarcan varios servicios o colaboradores, ordena el trabajo para que algo útil salga pronto y elimina los riesgos antes de que bloqueen al equipo.
Diseño de sistemas: Lidera el diseño de funcionalidades que abarcan varios servicios, deja por escrito los compromisos para que otros los revisen y revisa los diseños de otros ingenieros de forma constructiva.
Calidad y fiabilidad: Lidera la respuesta a incidentes en los sistemas del equipo, escribe post-mortems sin culpables y se asegura de que las acciones de seguimiento se completan de verdad.
Colaboración y comunicación: Representa al equipo en la planificación, negocia alcance y compromisos con producto y escribe documentos que entiende la gente de fuera de ingeniería.
Responsabilidad e impacto en el producto: Es responsable de un área del producto de principio a fin, cuestiona los requisitos que no sirven a los usuarios y propone trabajo que hace avanzar los objetivos del equipo.
Mentoría y desarrollo del equipo: Ejerce de mentor de uno o dos ingenieros de forma deliberada, les da feedback que les ayuda a llegar al siguiente nivel y participa en entrevistas de selección.

Ingeniero staff: qué se espera

Resuelve problemas que cruzan los límites entre equipos y orienta decisiones técnicas más allá de un solo equipo. Varios equipos o toda un área de producto, incluidos los problemas que no pertenecen a ningún equipo en concreto.

Entrega técnica: Desbloquea la entrega entre equipos: desenreda dependencias compartidas, construye las herramientas o ejecuta las migraciones que necesitan varios equipos, y mantiene encauzados los proyectos multiequipo.
Diseño de sistemas: Define la arquitectura más allá de los límites de cada equipo (modelos de datos compartidos, contratos entre servicios, decisiones de construir o comprar) y anticipa cómo tendrá que cambiar el sistema en el próximo año o dos.
Calidad y fiabilidad: Detecta riesgos de fiabilidad y seguridad que afectan a varios sistemas, fija estándares como la estrategia de testing y los objetivos de nivel de servicio, e impulsa las correcciones entre equipos.
Colaboración y comunicación: Alinea a varios equipos y funciones en torno a un plan técnico, resuelve desacuerdos entre equipos y explica el riesgo técnico a la dirección.
Responsabilidad e impacto en el producto: Encuentra los problemas de mayor impacto en un área de producto, incluidos los que ningún equipo ha asumido, y se asegura de que se resuelvan.
Mentoría y desarrollo del equipo: Hace crecer a ingenieros sénior de distintos equipos, da forma al proceso de entrevistas y a las prácticas de ingeniería, y es alguien a quien los demás acuden en busca de consejo.

Ingeniero principal: qué se espera

Marca la dirección técnica de la empresa y responde de su salud técnica a largo plazo. Toda la organización de ingeniería y la estrategia técnica de la empresa para los próximos años.

Entrega técnica: Da forma a cómo entrega software toda la organización (prácticas de release, elecciones de plataforma, herramientas de build y despliegue) para que cada equipo entregue más rápido y con más seguridad.
Diseño de sistemas: Es responsable de la estrategia técnica de la empresa: en qué tecnologías apostar, cuáles retirar y cómo debe evolucionar la arquitectura junto con el negocio a lo largo de varios años.
Calidad y fiabilidad: Define qué significan la fiabilidad, la seguridad y la calidad para la empresa, las equilibra con la velocidad junto con el equipo directivo y es el último punto de escalado en los incidentes más difíciles.
Colaboración y comunicación: Es una voz de confianza en las decisiones de la empresa, traduce la estrategia de negocio en dirección técnica y viceversa, y representa a ingeniería ante clientes, socios o inversores cuando hace falta.
Responsabilidad e impacto en el producto: Conecta la inversión en ingeniería con los resultados de la empresa y defiende o rechaza las grandes apuestas según su impacto técnico y de negocio.
Mentoría y desarrollo del equipo: Construye la cultura técnica de la empresa (cómo se toman las decisiones y cómo se comparte el conocimiento) y forma a la próxima generación de ingenieros staff.

Cómo adaptar esta escalera

Haz coincidir los niveles con tus puestos
Si tus puestos son Desarrollador I, II y III, cambia el nombre de los niveles, pero mantén un nivel por cada salto real de alcance. La mayoría de las empresas con menos de 100 ingenieros aún no necesitan un nivel principal: déjalo fuera hasta que alguien esté haciendo realmente ese trabajo.
Quédate con entre cinco y siete competencias
Con más de siete, nadie las lee; con menos de cuatro, personas muy distintas parecen iguales. Fusiona las competencias que siempre valoras juntas y añade una solo cuando cambiaría una decisión real.
Reescribe las expectativas como cosas que se puedan ver
En cada celda, pregúntate si un responsable podría señalar un ejemplo de los últimos seis meses. Sustituye palabras como «sólido» o «profundo» por lo que la persona hace de verdad, por ejemplo «lidera la respuesta a incidentes en los servicios del equipo».
Pruébala con personas reales antes de publicarla
Pide a dos o tres responsables que sitúen a los miembros de su equipo en el borrador. Allí donde no coincidan, la redacción es ambigua: corrígela, publica la escalera y comprométete a revisarla de nuevo dentro de seis meses.

Preguntas frecuentes

Preguntas sobre esta escalera

¿Cuántos niveles debe tener la escalera de carrera de un ingeniero de software?

Lo habitual en una empresa de 20 a 200 personas son entre cuatro y seis. Con menos, los ascensos se vuelven escasos y enormes; con más, la diferencia entre dos niveles es demasiado pequeña para describirla. Esta plantilla usa cinco: Ingeniero júnior, Ingeniero, Sénior, Staff y Principal.

¿Los ingenieros tienen que pasar a ser responsables de equipo para crecer?

No. Esta es una escalera del itinerario de especialista: los ingenieros staff y principal crecen en alcance e influencia sin gestionar personas. Úsala junto con la escalera de Engineering Manager, de modo que pasar a la gestión sea un cambio de itinerario y no un ascenso.

¿Cómo usamos la escalera en las decisiones de ascenso?

Asciende a quienes ya trabajan de forma constante en el siguiente nivel, no a quienes podrían hacerlo. Pide a la persona y a su responsable que reúnan ejemplos concretos para cada competencia del nivel objetivo, y compara cada propuesta con la misma matriz para que las decisiones sean coherentes entre equipos.

¿Cómo encaja la escalera en los check-ins y las reuniones 1:1?

Úsala como orden del día de los check-ins periódicos: la persona se evalúa frente a su nivel actual, el responsable hace lo mismo, y las diferencias entre ambas valoraciones se convierten en unas pocas acciones de desarrollo concretas para los próximos meses.

¿Con qué frecuencia debemos actualizar la escalera?

Revísala una o dos veces al año, y siempre que la empresa cambie de forma, por ejemplo cuando creas un equipo de plataforma o empiezas a contratar ingenieros staff. Reescribe una celda en cuanto las evaluaciones tropiecen con ella una y otra vez.

Crea esta escalera de carrera en LadderKit, gratis

Configura sus niveles y habilidades para tu equipo, evalúa a las personas con ellos en los check-ins y mantén la coherencia en las decisiones de ascenso.

Empieza gratis Explorar la demo Sin registro