12 Funciones de un Jefe de Proyectos Tech (2026)

Contratar mal a un jefe de proyectos en una empresa tech quema tiempo, margen y foco. El daño aparece antes de que el equipo lo diga en voz alta. Se retrasa la entrega, suben los cambios de prioridad, los seniors absorben incidencias ajenas y el proyecto sigue figurando como “en marcha” en Jira aunque la ejecución ya vaya torcida.

‍

Lo he visto muchas veces en startups y scaleups. El error no suele ser fichar a alguien desorganizado. El error real es incorporar a una persona que coordina tareas, pero no sabe ordenar dependencias, sostener presión entre equipos y forzar decisiones a tiempo.

‍

En este tipo de compañías, el jefe de proyectos afecta a productividad, calidad de ejecución y desgaste del equipo. Su trabajo toca planificación, seguimiento, comunicación con stakeholders y control de riesgos. También impacta áreas cercanas a la gestión de producción y costos, sobre todo cuando el crecimiento obliga a coordinar varias prioridades con recursos limitados.

‍

El problema es que muchas empresas siguen definiendo este rol de forma vaga. Piden un “PM” y mezclan responsabilidades de entrega, producto, operaciones y atención al cliente interno en una sola vacante. A corto plazo parece eficiente. A medio plazo genera fricción, expectativas cruzadas y contrataciones que no encajan.

‍

Por eso conviene aterrizar el rol con criterios de mercado tech, no con descripciones genéricas. En este artículo el foco está en startups y scaleups reales. Verás qué funciones sí corresponden a un jefe de proyectos, cuáles pertenecen a perfiles como Product Manager o Tech PM, qué señales sirven para evaluar seniority de verdad, una plantilla de descripción de puesto lista para usar y rangos salariales actualizados para España. Ese enfoque es el que ayuda a contratar bien y a evitar un error caro en una fase donde cada incorporación pesa más de lo que parece.

‍

Qué es un jefe de proyectos en entornos tech

‍

En una startup o scaleup tech, un jefe de proyectos no está para “llevar el seguimiento”. Está para convertir prioridades dispersas en entregas reales, con fechas, responsables, dependencias y riesgos visibles. Si no hace eso, el equipo entra en modo reacción y la compañía paga el coste en retrasos, sobrecarga y decisiones tomadas demasiado tarde.

‍

La definición útil del rol es simple. El jefe de proyectos responde de la ejecución transversal. Ordena trabajo entre producto, ingeniería, datos, negocio y terceros. Aterriza alcance con quien corresponda, fuerza decisiones cuando hay ambigüedad y mantiene el proyecto dentro de un marco operable. En empresas tech, esa última parte importa mucho porque casi ningún proyecto serio depende de un solo equipo.

‍

Aquí aparece la confusión que más veo en procesos de selección. Se publica una vacante de “PM” para cubrir a la vez delivery, priorización de producto, reporting a cliente y coordinación técnica. Ese híbrido puede aguantar unos meses en una empresa pequeña. En cuanto suben el volumen, las integraciones o el número de stakeholders, deja de ser eficiente y empieza a romperse.

‍

Un jefe de proyectos no sustituye a un Product Manager, ni a un Engineering Manager, ni a un Tech Lead.

‍

Su valor está en hacer que esas funciones trabajen con una misma secuencia de ejecución.

‍

La diferencia importa también al contratar. Un equipo que necesita ordenar dependencias entre squads, proveedores y áreas internas debe buscar un perfil de project delivery, no un perfil centrado en discovery o estrategia de producto. Por eso muchas compañías recurren a una agencia de talento especializada en perfiles tech cuando el mercado mezcla títulos parecidos con responsabilidades muy distintas.

‍

La delimitación práctica entre roles queda así:

• Jefe de proyectos o Project Manager. Responde por planificación, coordinación, seguimiento, riesgos, comunicación y entrega.
• Product Manager. Define prioridades de producto, problema a resolver, impacto esperado y criterio de valor para negocio y usuario.
• Tech PM. Suele moverse mejor en proyectos con alta carga técnica, como migraciones, plataformas, infra, seguridad o integraciones complejas, porque entiende mejor restricciones de arquitectura y dependencia técnica.
• Delivery Manager. Suele aparecer en estructuras más grandes, con foco más fuerte en capacidad, gobernanza, previsibilidad y escalado del delivery.
• Scrum Master. Facilita un marco de trabajo. No asume por defecto la responsabilidad total sobre alcance, stakeholders, presupuesto o resultados de ejecución.

‍

En startups, estos bordes se mezclan. En scaleups, conviene separarlos antes de que el crecimiento fuerce la decisión. Ese punto llega antes en SaaS B2B, fintech, healthtech o marketplaces con varios equipos tocando la misma iniciativa.

‍

He visto el mismo error repetirse muchas veces. La empresa contrata a alguien brillante en ceremonias ágiles para un proyecto de migración con proveedor externo, deuda técnica y presión comercial. A los dos meses hay reuniones, tableros y updates. Lo que no hay es control real de dependencias. El problema no era la persona. Era la definición del puesto.

‍

Incluso fuera del software puro, la lógica es la misma. El caso de éxito de Mobel Suministros muestra algo que en tech también aplica: cuando compras, tiempos, coordinación y seguimiento se gobiernan bien, el impacto operativo se nota rápido. En proyectos digitales cambia el contexto, pero no cambia la necesidad de tener a alguien responsable de que la ejecución avance de verdad.

‍

Dicho de forma útil para hiring: un jefe de proyectos en entornos tech es el perfil que convierte complejidad organizativa en delivery predecible. Si además tu empresa necesita que defina producto, lidere al equipo de ingeniería y resuelva arquitectura, no estás definiendo un jefe de proyectos. Estás mezclando tres puestos en uno.

‍

Las 12 funciones esenciales

‍

Un jefe de proyectos tech aporta orden donde ya existe complejidad. En startups y scaleups, esa complejidad suele venir de varios frentes a la vez: producto presionando plazos, ingeniería protegiendo estabilidad, ventas empujando compromisos y dependencias técnicas que no aparecen en la primera reunión. Estas 12 funciones separan a quien coordina tareas de quien realmente sostiene el delivery.

‍

1. Definición de alcance y roadmap

‍

La primera función consiste en fijar el perímetro real del proyecto. El que se puede ejecutar con el equipo, el tiempo y las dependencias disponibles.

‍

Aquí se gana o se pierde medio proyecto. Si el alcance nace inflado o ambiguo, el resto del trabajo se convierte en corrección constante. En entornos tech lo veo mucho en migraciones, integraciones con terceros, replatforming y proyectos de IA donde negocio pide velocidad antes de validar restricciones.

‍

Un jefe de proyectos sólido aterriza objetivos, entregables, secuencia de trabajo, criterios de aceptación y exclusiones. También fuerza una conversación incómoda pero rentable: qué no entra ahora. Esa parte evita semanas de retrabajo.

‍

Ejemplo típico en scaleup. Se quiere lanzar una funcionalidad basada en LLMs para clientes enterprise. Un buen PM separa discovery, prueba técnica, validación legal, coste de inferencia, integración, observabilidad y mantenimiento. Sin esa secuencia, el roadmap es una intención, no un plan.

‍

Errores frecuentes en esta fase:

• Aceptar alcance ambiguo porque “ya lo veremos sobre la marcha”.
• Planificar sin tech leads y descubrir tarde que la solución no aguanta.
• Mezclar discovery con delivery como si tuvieran la misma certidumbre.

‍

Para proyectos con impacto operativo, también conviene conectar esta definición con gestión de producción y costos si el software afecta compras, operaciones o servicio.

‍

2. Gestión de stakeholders

‍

Los proyectos no se frenan solo por problemas técnicos. Se frenan porque cada área intenta optimizar algo distinto.

‍

Producto quiere velocidad. Ingeniería quiere margen para construir bien. Finanzas quiere control. Founders quieren visibilidad. Clientes enterprise quieren fechas. El jefe de proyectos tiene que alinear esas expectativas sin maquillar la realidad.

‍

Eso exige criterio. No basta con pasar mensajes de un lado a otro.

‍

En una startup o scaleup tech, los stakeholders suelen incluir CTO, founders, product managers, engineering managers, data, seguridad, proveedores y, según el modelo de negocio, también clientes. Cada uno necesita un nivel de detalle diferente. El error clásico es contar lo mismo a todos del mismo modo. El segundo error, todavía peor, es cambiar la historia según quién pregunte.

‍

Regla práctica. Si el mensaje se adapta a la audiencia y los hechos no cambian, la gestión va bien. Si la narrativa cambia para evitar tensión, el proyecto ya tiene deuda política.

‍

Al contratar, conviene buscar perfiles que sepan sostener conversaciones difíciles. Pregunta por un caso real donde frenaron una petición de negocio, qué alternativa propusieron y cómo defendieron la decisión ante alguien senior.

‍

3. Planificación y control de riesgos

‍

El riesgo en proyectos tech tiene nombre y apellido. Dependencia de un proveedor. Deuda técnica. Una persona clave saturada. Un requisito mal definido. Una integración que nadie ha probado de verdad.

‍

Por eso esta función no se resuelve con un documento bonito en el kickoff. Se trabaja cada semana.

‍

Un jefe de proyectos útil mantiene un registro vivo de riesgos, asigna propietario, define señal temprana y revisa impacto real en fechas, coste o calidad. Si el riesgo no tiene dueño, nadie lo va a mover. Si nadie revisa señales tempranas, el problema llega tarde a comité y caro al equipo.

‍

Riesgos habituales en startups y scaleups:

• Concentración de conocimiento en una sola persona.
• Integraciones externas inciertas con tiempos o límites poco claros.
• Compromisos comerciales asumidos sin validación técnica.
• Infraestructura inmadura para el nivel de crecimiento esperado.

‍

Lo que mejor funciona en la práctica:

• POCs tempranas para bajar incertidumbre técnica.
• Mapeo de dependencias antes de comprometer fechas.
• Revisión semanal de riesgos activos, no mensual.
• Escalado temprano cuando el impacto ya toca hitos críticos.

‍

En IA esto pesa aún más. Datos, calidad, coste, seguridad y mantenimiento cambian el proyecto completo. Ignorarlo al inicio suele acabar en roadmap ficticio.

‍

4. Coordinación cross-funcional

‍

Gran parte del retraso en una empresa tech no está en el trabajo visible. Está en los huecos entre equipos.

‍

Backend espera a plataforma. Plataforma espera a seguridad. Seguridad espera contexto de producto. Producto asume que ya estaba claro. El jefe de proyectos reduce esas esperas porque ordena secuencia, responsables y definición de cada entrega intermedia.

‍

Coordinar bien no consiste en meter a más gente en más reuniones. Consiste en decidir quién necesita qué, para cuándo y con qué nivel de cierre.

‍

En una migración cloud, por ejemplo, rara vez basta con backend e infraestructura. También intervienen seguridad, finanzas si hay revisión de costes, soporte si cambia la operativa y negocio si existe riesgo para clientes. Si cada área avanza por separado, el retraso aparece aunque cada equipo diga que cumplió su parte.

‍

La herramienta ayuda si se usa con disciplina. Jira, Linear o Asana sirven para mostrar dependencias, responsables y bloqueos. No arreglan una mala coordinación por sí solos.

‍

5. Gestión de presupuesto y recursos

‍

Presupuesto y capacidad se deciden desde el principio. No son un informe de control al final del mes.

‍

En startups financiadas y scaleups con varios frentes abiertos, esta función marca la diferencia entre crecer con criterio o quemar caja en prioridades mal resueltas. El jefe de proyectos tiene que saber dónde poner talento senior, cuándo usar proveedor externo, qué parte del alcance cabe con el equipo actual y qué cuello de botella exige contratación.

‍

La mala asignación se nota rápido. Un backend senior dedicado semanas a tareas de bajo impacto sale caro. Un perfil de plataforma repartido entre cuatro iniciativas frena a todos. Cubrir carencias estructurales con horas extra solo compra deuda y rotación.

‍

Antes de abrir una vacante, conviene entender qué falta de verdad: capacidad, especialización o liderazgo. En ese punto, una agencia de talento especializada en tecnología puede ayudar a definir mejor la necesidad y evitar contrataciones reactivas.

‍

Señales de buen criterio en esta función:

• Distingue entre recurso crítico y recurso conveniente.
• Protege a los perfiles cuello de botella.
• Trabaja con capacidad real, no con disponibilidad teórica.
• Anticipa contrataciones antes de que el delivery se degrade.

‍

Fuera del software también se ve claro. El caso de éxito de Mobel Suministros muestra cómo compras, coordinación y seguimiento afectan al resultado operativo.

‍

6. Seguimiento de KPIs y reporting

‍

Un buen PM no mide por medir. Selecciona pocas señales y las conecta con decisiones.

‍

En startups, el reporting suele fallar por dos motivos. O es tan superficial que no sirve, o es tan detallado que nadie lo lee. Las dos versiones consumen tiempo y reducen claridad.

En software, suelen funcionar bien métricas como hitos cumplidos, bloqueos abiertos, lead time de validación, estabilidad de sprint y desviaciones sobre capacidad prevista. En proyectos de IA entran además métricas técnicas del caso de uso, siempre que sirvan para decidir algo concreto.

‍

La regla es simple. Cada KPI debe responder a una pregunta de gestión. Si un dashboard no cambia prioridades, no compensa el tiempo que cuesta mantenerlo.

‍

Un caso habitual. El equipo cierra tickets, pero seguridad acumula validaciones pendientes y eso compromete el despliegue. El reporting tiene que reflejar ese cuello de botella y su impacto en fecha. Decir que “el proyecto avanza” no aporta nada.

‍

El ritmo también importa. Seguimiento operativo frecuente y reporting semanal a stakeholders suele funcionar mejor que reuniones largas donde se mezclan detalle técnico y actualización ejecutiva.

‍

7. Gestión de dependencias técnicas

‍

La mayoría de los retrasos serios aparecen por una dependencia mal entendida o directamente ignorada.

‍

Puede ser una API que no llega, un entorno sin preparar, una decisión de arquitectura sin cerrar, una validación de seguridad pendiente o un proveedor que cambia condiciones. El jefe de proyectos tiene que detectar esas dependencias antes de que se conviertan en bloqueo en cascada.

‍

Hay dependencias entre equipos y también entre decisiones. Un squad no puede implementar bien una integración si producto no ha cerrado flujos, seguridad no ha validado requisitos y plataforma no ha preparado entorno. Sobre el papel parece obvio. En la operación diaria se olvida con facilidad.

‍

Qué hace bien un PM aquí:

• Visualiza dependencias pronto en herramientas compartidas.
• Distingue bloqueo real de problema de ejecución.
• Escala rápido cuando una dependencia ya afecta hitos.
• Evita sorpresas tardías entre squads o áreas.

‍

En compañías con varios equipos tocando la misma iniciativa, esta función deja de ser táctica y pasa a ser parte del diseño del delivery.

‍

8. Facilitación de metodologías ágiles

‍

La metodología ágil va más allá de realizar dailies o adoptar Scrum sin un propósito claro. El trabajo del jefe de proyectos consiste en elegir un sistema de trabajo que mejore la entrega y ajustarlo al contexto de la empresa.

‍

En startups con interrupciones frecuentes, incidencias y soporte continuo, Kanban suele encajar mejor. En equipos con foco protegido y objetivos claros por ciclo, Scrum puede funcionar bien. En scaleups, muchas veces aparece un modelo híbrido porque conviven discovery, mantenimiento y entregas comprometidas con clientes.

‍

El criterio importa más que la ortodoxia. Un PM maduro cambia el marco si deja de servir al proyecto.

‍

Lo que suele funcionar:

• Ceremonias cortas con decisiones claras.
• Backlog priorizado de verdad.
• Trabajo definido antes de entrar en sprint.
• Revisión periódica del sistema de trabajo según etapa y tipo de proyecto.

‍

Lo que suele generar ruido:

• Rituales sin utilidad operativa.
• Cambios constantes dentro del sprint.
• Roles mezclados hasta el punto de que nadie decide.
• Adoptar un marco por moda o por imitación a empresas más grandes.

‍

9. Comunicación con cliente interno o externo

‍

La comunicación de proyecto tiene que ser precisa, frecuente y útil. Eso aplica igual si el interlocutor es un founder, un director de área, un partner o un cliente enterprise.

‍

El error más caro aquí es el optimismo mal gestionado. Aplaza una conversación incómoda hoy y multiplica el problema la semana siguiente.

‍

Quien recibe la actualización necesita tres cosas: qué está pasando, qué impacto tiene el problema si existe, y qué decisión o ajuste toca hacer. La transparencia bien gestionada protege la relación. Lo que la deteriora es enterarse tarde.

‍

Si una integración con AWS, Google Cloud o Microsoft Azure se retrasa por una limitación técnica, la conversación correcta incluye impacto en fecha, alternativas y decisión necesaria. Hablar en términos vagos solo compra tiempo y resta confianza.

‍

10. Gestión del cambio

‍

Todo proyecto cambia. Lo importante es decidir cómo entra ese cambio y qué desplaza.

‍

Una buena gestión del cambio hace visible el coste de cada nueva petición. Tiempo, foco, presupuesto, riesgo y capacidad afectada. Sin ese filtro, el equipo entra en multitarea permanente y la velocidad cae aunque el backlog siga “avanzando”.

‍

Un jefe de proyectos sólido suele resolver cada cambio de una de estas formas:

• Entra ahora y se mueve otra prioridad.
• Se agenda después con impacto asumido.
• Se rechaza porque no compensa el coste.

‍

La clave es dejar rastro de la decisión y del trade-off. En startups con presión comercial, esta disciplina evita que ventas o dirección conviertan cada oportunidad en desorden operativo.

‍

11. Mentoring y desarrollo del equipo

Un jefe de proyectos que solo persigue estados se queda corto. En equipos buenos, también mejora la forma de trabajar del grupo.

‍

Eso no significa sustituir al manager técnico. Significa detectar saturación antes del burnout, repartir exposición a responsabilidades, dar feedback sobre ejecución y ayudar a que perfiles intermedios ganen autonomía. En startups y scaleups esto importa mucho porque los equipos crecen rápido y no siempre existe una capa de management madura.

‍

He visto proyectos recuperarse sin cambiar la tecnología, solo mejorando claridad, ownership y coordinación entre personas. Ese tipo de mejora también es parte del trabajo del PM.

‍

En empresas que quieren retener talento, conviene ligar esta función a una estructura clara de plan de carrera en tecnología. Si no, la mentoría se queda en conversaciones sueltas.

‍

12. Cierre y lecciones aprendidas

‍

El cierre de proyecto define si la empresa aprende o repite.

‍

Un cierre útil deja decisiones documentadas, incidencias registradas, deuda visible, desvíos explicados y acciones concretas para el siguiente ciclo. Si todo termina con un “en general salió bien”, el aprendizaje real se pierde en una semana.

‍

Qué debería salir de un buen cierre:

• Decisiones que funcionaron y conviene repetir.
• Errores de estimación y su causa.
• Dependencias mal resueltas.
• Huecos de talento o proceso detectados.
• Acciones concretas con responsable.

‍

En tech, donde cambian equipos, prioridades y contexto de negocio con rapidez, esta función vale mucho más de lo que suele parecer. Un buen cierre evita volver a pagar por el mismo error.

Diferencias según tipo de empresa

‍

El mismo título significa cosas distintas según dónde contrates. En una startup, el jefe de proyectos suele estar más pegado a la operación diaria. Toca ordenar caos, bajar prioridades a tareas y mantener velocidad sin añadir capas. Si el perfil viene de entornos demasiado pesados, puede ahogar al equipo.

‍

En consultoría, el rol suele incorporar más gestión de cliente, control contractual, reporting formal y coordinación con varias cuentas. Puede ser muy útil para perfiles con fuerte disciplina de delivery, pero a veces llegan demasiado acostumbrados a gobernanza y poco a producto propio.

‍

En corporate, la complejidad suele venir por estructura, compliance y múltiples stakeholders. Hay más dependencia entre áreas y más necesidad de navegar organización. El riesgo aquí es contratar a alguien muy hábil en contexto interno grande pero lento en ejecución real dentro de una scaleup.

‍

Mi criterio es simple. Si eres startup o scaleup, prioriza capacidad de ejecución, criterio para priorizar y suficiente comprensión técnica para hablar de dependencias con credibilidad. Lo demás se entrena mejor que eso.

‍

Hard skills y soft skills críticas

‍

En entornos tech, un jefe de proyectos flojo en habilidades duras genera una falsa sensación de control. Hay reuniones, hay tableros, hay updates. Pero nadie tiene claro qué bloquea el delivery, qué dependencia va a romper una fecha o qué decisión técnica exige alinear negocio y engineering antes de que el problema escale.

‍

Las hard skills que sí separan a un perfil útil de uno decorativo son bastante concretas. Debe manejar con soltura herramientas de coordinación y documentación como Confluence, Notion, GitHub o GitLab. Debe saber leer un backlog de verdad, distinguir entre una incidencia operativa y un riesgo estructural, y seguir dependencias entre producto, datos, backend, frontend e integraciones sin perderse en el detalle.

‍

También necesita suficiente criterio técnico para hacer preguntas buenas. No para programar. Sí para entender qué implica una integración con terceros, un cambio de arquitectura, una validación de seguridad, una deuda técnica mal resuelta o un cuello de botella en CI/CD. En startups y scaleups esto pesa más de lo que parece, porque muchas veces no hay capas intermedias que traduzcan entre negocio y equipo técnico.

‍

Aquí veo un error de contratación muy repetido. Se valora a perfiles muy ordenados en reporting, pero sin capacidad real para tensionar prioridades con leads técnicos o detectar que un plan está mal planteado desde el inicio. Si quieres evitar ese fallo, conviene revisar también cómo estructuras tus procesos de selección para roles tech, porque este puesto se evalúa mal cuando la entrevista se queda en discurso y no baja a casos.

‍

En soft skills, yo priorizo cinco.

• Comunicación ejecutiva y operativa. Debe adaptar el mensaje. Una cosa es hablar con founders o dirección. Otra, bajar una decisión a un equipo técnico sin generar ruido.
• Criterio de priorización. El buen jefe de proyectos no intenta meter todo en fecha. Decide qué se retrasa, qué se simplifica y qué merece escalarse.
• Gestión de conflicto. En producto digital hay fricción constante entre velocidad, calidad y alcance. Si no sabe intervenir, el equipo entra en desgaste o el proyecto se vuelve político.
• Orden operativo. Hace seguimiento, cierra cabos sueltos y convierte acuerdos ambiguos en próximos pasos claros.
• Influencia sin autoridad formal. En muchas scaleups coordinar significa conseguir compromiso de personas que no le reportan.

‍

La prueba real no está en cómo se define el candidato, sino en cómo trabaja bajo presión. En entrevista, prefiero pedir un caso concreto: una prioridad mal decidida, un cambio de alcance a mitad de proyecto o un conflicto entre negocio y desarrollo. Ahí se ve rápido si el perfil sabe conducir proyectos de software o solo sabe hablar de ellos.

‍

Certificaciones que valen la pena

‍

Las certificaciones no garantizan nada. Sirven como señal secundaria. Nunca como prueba principal.

‍

PMP tiene peso cuando el rol exige estructura, gobernanza, control y exposición a múltiples stakeholders. PMI-ACP puede tener más sentido si el entorno es claramente ágil y necesitas a alguien con práctica real, no solo vocabulario de Scrum. PRINCE2 encaja mejor en organizaciones con procesos más formales. Y certificaciones del ecosistema Scrum pueden ser útiles, pero están muy sobrevaloradas cuando se usan como filtro principal.

‍

Si tengo que priorizar, prefiero experiencia demostrable en proyectos complejos de software antes que una colección de logos. La certificación suma cuando el candidato ya sabe ejecutar. Si no, solo maquilla.

‍

Plantilla de descripción de puesto editable

‍

Este es un ejemplo práctico de job description para hiring.

‍

Título del puesto

‍
Jefe de Proyectos Tech

Misión del rol

‍
Liderar la ejecución de proyectos tecnológicos, coordinando equipos cross-funcionales para entregar dentro de alcance, tiempos y recursos acordados, con foco en calidad y visibilidad para negocio.

‍

Responsabilidades

‍

• Definir alcance, hitos, plan de trabajo y dependencias.
• Coordinar a ingeniería, producto, datos, infraestructura y stakeholders de negocio.
• Gestionar riesgos, bloqueos y cambios de alcance.
• Hacer seguimiento del progreso con KPIs y reporting periódico.
• Alinear prioridades con CTO, founders y responsables funcionales.
• Asegurar cierre de proyecto y captura de lecciones aprendidas.

‍

Requisitos

‍

• Experiencia gestionando proyectos de software en entornos startup, scaleup o producto digital.
• Manejo fluido de Jira y herramientas de documentación.
• Capacidad para coordinar perfiles técnicos sin necesidad de supervisión jerárquica directa.
• Buen criterio para priorización, escalado y resolución de bloqueos.
• Comunicación clara con perfiles técnicos y no técnicos.

‍

Se valora

‍

• Experiencia en cloud, datos, IA o ciberseguridad.
• Exposición a equipos en crecimiento.
• Certificaciones como PMP, PMI-ACP, Scrum o PRINCE2.

‍

Señales de encaje

‍

• Ha trabajado con ambigüedad sin perder control.
• Sabe decir no con contexto.
• Aporta orden sin burocracia.

‍

Si estás montando proceso desde cero, conviene revisar también cómo diseñas tus procesos de selección en tecnología, porque un mal proceso atrae justo al tipo de PM que mejor habla y peor ejecuta.

‍

10 preguntas para entrevistar a un jefe de proyectos

‍

No preguntes teoría. Pregunta comportamiento real.

‍

• Háblame de un proyecto donde el alcance estaba mal definido al inicio. Qué hiciste y qué cambió.
• Cuéntame un caso donde negocio pidió algo que el equipo no podía asumir en plazo. Cómo lo gestionaste.
• Qué indicadores usaste en tu último proyecto y por qué esos.
• Cuál fue el riesgo más serio que detectaste tarde. Qué aprendiste.
• Cómo coordinaste equipos con prioridades distintas.
• Qué herramienta usabas para seguimiento y cómo evitabas que se convirtiera en burocracia.
• Descríbeme una situación donde tuviste que escalar un problema incómodo.
• Cómo gestionas cambios de alcance sin romper la relación con stakeholders.
• Qué tipo de equipo necesita más estructura y cuál menos.
• Qué error cometen muchas empresas al contratar este rol.

‍

La clave no es si responde “bonito”. La clave es si baja a detalles, decisiones, trade-offs y consecuencias.

‍

Rango salarial en España 2026 por seniority y sector

‍

En tech, pagar mal este rol sale caro. Un jefe de proyectos flojo no solo retrasa entregas. También quema al equipo, multiplica cambios evitables y obliga a founders, CTOs o heads of product a apagar fuegos que no deberían tocar.

‍

La banda salarial no se define por el título. Se define por el nivel de complejidad que va a absorber esa persona. En startups y scaleups españolas, no valoro igual a quien coordina un roadmap acotado con un equipo estable que a quien ordena varios frentes, depende de terceros, gestiona presión comercial y mantiene visibilidad real sobre riesgos técnicos.

‍

Por seniority, la diferencia suele estar en cuatro cosas: autonomía, calidad de criterio, capacidad de priorización y manejo de conflicto. Un perfil junior o middle puede seguir procesos y sostener el día a día. Un perfil senior evita que el proyecto se descontrole cuando cambian prioridades, falta información o el negocio pide más de lo que el equipo puede entregar.

‍

Por sector, también cambia mucho el precio razonable del rol. SaaS B2B, fintech, healthtech o eCommerce con operaciones complejas suelen exigir más coordinación transversal, más presión por plazos y más exposición a stakeholders críticos. Eso empuja la compensación hacia arriba. En cambio, entornos con menor dependencia técnica o menor ritmo de cambio pueden cubrir la posición con bandas más contenidas.

‍

La referencia útil no es solo salario fijo.

‍

En procesos de contratación para empresas tech, reviso siempre el paquete completo: fijo, variable si existe, phantom shares o stock options, bonus por objetivos realistas, flexibilidad y nivel de responsabilidad sobre delivery. En una startup, un fijo algo más bajo puede tener sentido si el rol tiene impacto real, acceso a liderazgo y un variable creíble. En una scaleup más madura, el candidato bueno suele esperar más estructura, más claridad de alcance y una banda mejor cerrada desde el inicio.

‍

El error típico es copiar tablas genéricas de project management y aplicarlas al ecosistema tech como si todos los contextos fueran iguales. No lo son. Un Jefe de Proyectos en una software factory, en una scaleup de producto o en una empresa con fuerte componente de integración técnica puede compartir cargo y hacer trabajos muy distintos.

‍

Si quieres fijar una banda 2026 con criterio, usa esta secuencia: alcance real del rol, número de equipos implicados, complejidad técnica, presión de stakeholders, impacto en negocio y madurez de la empresa. Con eso se define mejor la compensación que con un título bonito en LinkedIn.

‍

Kit de contratación cómo fichar al jefe de proyectos que necesitas

‍

Saber cuáles son las funciones de un jefe de proyectos no basta si luego contratas a alguien que solo sabe actualizar estados. El buen PM en tecnología no brilla por la cantidad de ceremonias que organiza. Brilla porque reduce fricción, anticipa problemas y consigue que equipos distintos avancen en la misma dirección sin perder velocidad.

‍

Si eres una startup, tu riesgo más común es contratar un perfil demasiado corporativo, muy fuerte en reporting y débil en ejecución bajo ambigüedad. Si eres una consultora, el error suele ser el contrario. Traer a alguien con poca disciplina de seguimiento, poca tolerancia a cliente exigente o sin capacidad para sostener compromisos formales. En corporate, el fallo típico es confundir experiencia en gobernanza interna con capacidad real de entrega.

‍

Las hard skills que importan son concretas. Planificación, seguimiento, manejo de herramientas, criterio para leer dependencias técnicas y capacidad para estructurar trabajo sin sobredocumentarlo. Las soft skills marcan la diferencia final. Comunicación, conflicto, claridad y temple bajo presión. Si el candidato evita decisiones difíciles o habla siempre en abstracto, normalmente no es el perfil.

‍

Las certificaciones ayudan, pero no lideran la decisión. PMP, PMI-ACP, PRINCE2 o credenciales Scrum pueden sumar contexto. No sustituyen experiencia real. En entrevistas, lo útil es forzar ejemplos. Proyectos con alcance cambiante, stakeholders enfrentados, riesgos mal detectados, equipo saturado, hitos en peligro. Ahí se ve quién ejecuta y quién recita frameworks.

‍

La plantilla de job description que has visto arriba sirve para arrancar rápido. Lo importante es no publicar un puesto genérico. Si necesitas un PM para producto propio en una scaleup, dilo. Si necesitas exposición a cloud, datos o IA, dilo. Si esperas interlocución con CTO y founders, dilo. Cuanto más ambigua es la descripción, más irrelevantes serán los candidatos.

‍

Con el salario pasa algo parecido. No fijes una banda solo por benchmark superficial. Ajusta por complejidad, seniority real, criticidad del proyecto y contexto de mercado. Si quieres a alguien que de verdad pueda sostener delivery en un entorno tech exigente, no compites solo con otros puestos de Project Manager. Compites con empresas que entienden el impacto real de este rol.

‍

Mi recomendación final es clara. Si estás contratando este perfil para una empresa tecnológica, no busques a alguien que “lleve proyectos”. Busca a alguien que haga que las cosas pasen sin romper al equipo en el camino. Ese matiz separa un coste fijo de una contratación que cambia el rendimiento de la empresa.

‍

Si necesitas ayuda para encontrar un Project Manager que sí ejecute en startups y scaleups tecnológicas, Kulturo trabaja precisamente en ese punto. Ayudamos a CTOs, founders y líderes de ingeniería a fichar perfiles de delivery, software, datos, IA, cloud y ciberseguridad con contexto real de mercado y foco en contratación eficaz.