Platform engineer vs DevOps: cuándo contratar cada perfil

La mala recomendación que sigue circulando es esta, contratar “DevOps” o “Platform Engineer” como si fueran sinónimos. No lo son, y tratarlos como equivalentes suele acabar en el mismo error, una contratación cara que no resuelve el cuello de botella real. DevOps es un enfoque de trabajo, platform engineering es la construcción de una capa interna reutilizable para escalar ese trabajo.

‍

La diferencia importa más en España de lo que muchos equipos quieren admitir. Gartner proyectó que 80% de las grandes organizaciones de ingeniería de software tendrían equipos de plataforma dedicados en 2026, frente a 45% en 2022. Esa trayectoria encaja con lo que ya se ve en startups y scaleups, menos bricolaje por squad, más autoservicio, más estandarización y menos dependencia de tickets manuales.

‍

DimensiónDevOpsPlatform EngineerObjetivo principalEntregar y operar mejor un producto o servicio concretoConstruir una plataforma interna que sirva a muchos equiposUnidad de trabajoPipelines, despliegues, incidentes, automatización tácticaIDP, golden paths, autoservicio, estándares comunesMétrica mentalVelocidad de entrega, estabilidad operativaExperiencia del desarrollador, adopción interna, reducción de fricciónEscala naturalSuele crecer de forma lineal con cada equipoPuede escalar de forma multiplicativa al reutilizar una capa común

‍

El debate que nadie está resolviendo bien

‍

La confusión nace porque mucha gente sigue hablando de DevOps como si fuera un puesto, cuando en realidad es una forma de organizar desarrollo y operaciones. Red Hat lo resume bien, DevOps integra desarrollo y operaciones para mejorar la entrega continua, mientras que platform engineering se centra en crear plataformas internas que hagan ese flujo más fácil de escalar. Esa diferencia no es semántica, cambia quién configura, quién aprueba, quién mantiene y quién responde cuando algo falla. Red Hat sobre platform engineering frente a DevOps

‍

El problema real no es el título, es el reparto del trabajo

‍

En la práctica, muchas empresas llamaron “DevOps” a un rol que absorbía infra, despliegues, observabilidad y parte del soporte a producto. Eso funcionó mientras había pocos squads y pocas dependencias, pero se rompe cuando cada equipo empieza a montar su propio stack, su propio pipeline y su propia forma de desplegar. Ahí es donde platform engineering deja de ser moda y pasa a ser una respuesta organizativa.

‍

Regla útil: si un perfil pasa la mayor parte del tiempo apagando fuegos y manteniendo pipelines para un solo producto, necesitas un DevOps. Si el problema es que todos los squads repiten el mismo trabajo, necesitas una plataforma.

‍

En el mercado español, esto además afecta a contratación. El talento cloud y DevOps está tensionado, así que no puedes permitirte descripciones vagas ni títulos intercambiables. Si tu equipo está creciendo y no distingues entre operación táctica y producto interno, acabas entrevistando mal y contratando peor.

‍

La señal de madurez es sencilla, aunque muchos la ignoran. Cuando tu organización todavía necesita automatizar lo básico y estabilizar entregas, DevOps es la prioridad. Cuando ya tienes varios equipos chocando con la misma fricción, platform engineering empieza a tener más sentido que seguir añadiendo manos a la rotación operativa.

‍

Qué hace cada rol en su día a día

Un DevOps Engineer vive pegado a la entrega. Su día gira alrededor de pipelines de CI/CD, despliegues, monitorización, incidencias y automatización para que un producto llegue a producción sin fricción. Un Platform Engineer mira el mismo problema desde otro sitio, diseña una capa interna que otros equipos puedan reutilizar sin tener que entender la maquinaria de debajo.

‍

DevOps trabaja sobre flujos concretos

‍

En un equipo pequeño o mediano, DevOps suele tocar Jenkins, GitHub Actions, Terraform o Kubernetes para que un producto despliegue bien y se recupere rápido cuando algo falla. También se mete en alertas, logs, métricas y runbooks, porque la responsabilidad operativa está muy cerca del código y del negocio. El valor se nota cuando el equipo deja de perder tiempo en tareas repetitivas y puede sacar cambios con menos riesgo.

‍

Platform Engineering construye producto interno

‍

El platform engineer no debería vivir resolviendo el mismo ticket veinte veces. Su trabajo es definir golden paths, abstraer complejidad, montar un Internal Developer Platform y hacer que el autoservicio funcione para todos los squads. La mentalidad cambia, ya no preguntas solo “¿está estable?”, sino “¿está siendo usado?”, “¿reduce fricción?” y “¿sirve para escalar sin multiplicar operaciones?”.

‍

Si quieres una visión más táctica del día a día de DevOps, esta guía de qué hace un ingeniero DevOps ayuda a aterrizar responsabilidades reales sin caer en definiciones genéricas. Y si necesitas una referencia laboral más amplia para orientar carrera o hiring, profesiones recomendadas por Global MAE encaja bien como lectura complementaria.

‍

Clave práctica: DevOps optimiza el flujo. Platform Engineering optimiza el sistema que genera ese flujo.

‍

Ese matiz cambia cómo entrevistas, cómo organizas el equipo y cómo mides el éxito. Si el candidato habla solo de herramientas, probablemente está más cerca de ejecución táctica. Si habla de experiencia interna, autoservicio y reducción de fricción entre squads, ya estás mirando un perfil de plataforma.

‍

Habilidades técnicas y blandas que los separan

‍

Hay solapamiento, claro. Ambos perfiles necesitan entender cloud, contenedores, automatización, observabilidad y seguridad básica. Pero el peso de cada habilidad cambia mucho, y en una entrevista eso se nota enseguida.

‍

El DevOps fuerte resuelve operación y automatización

‍

Un buen DevOps suele ser sólido en scripting, IaC, CI/CD, Kubernetes, monitorización y gestión de incidentes. También tiene que soportar presión, porque su día a día no es solo construir, sino responder cuando algo se degrada o rompe. La habilidad blanda más importante aquí no es “comunicar bien” en abstracto, es priorizar bajo presión sin perder contexto técnico.

‍

El Platform Engineer necesita mentalidad de producto interno

‍

Aquí la diferencia es más fina. El platform engineer no solo debe saber construir, también debe pensar como quien diseña una herramienta que otros usarán cada día. Hace falta empatía con el desarrollador, criterio de estandarización, capacidad para decir no a excepciones innecesarias y una obsesión sana por la adopción.

‍

Un buen filtro de entrevista es preguntar qué harían con un equipo que pide un atajo distinto para cada despliegue. Un DevOps suele responder con automatización puntual o con una solución de integración. Un Platform Engineer debería hablar de estándares, guardrails, reutilización y experiencia de consumo.

‍

Lo que no debes confundir al leer CVs

‍

• Saber Kubernetes no te convierte en Platform Engineer. Si solo ha operado clusters, puede ser DevOps, SRE o cloud engineer.
• Saber Terraform tampoco basta. Lo importante es si diseña componentes reutilizables o solo despliega infra.
• Hablar de colaboración no prueba mentalidad de plataforma. Busca evidencias de producto interno, no frases bonitas.
• Haber trabajado con incidentes no te hace DevOps automáticamente. Pregunta por automatización, rollback y recuperación.

‍

La mejor entrevista técnica aquí no busca palabras clave, busca decisiones. Si el candidato explica por qué una política debería vivir en la plataforma y no en cada squad, vas por buen camino. Si se queda en “yo lo configuraba todo”, estás delante de un perfil más orientado a operación que a plataforma.

‍

Herramientas y stacks típicos de cada perfil

‍

Las herramientas no definen el rol, pero sí delatan el enfoque. Un DevOps suele moverse en el terreno de la automatización y la operación directa, mientras que un Platform Engineer añade una capa de producto interno encima de ese mismo terreno. Por eso verás mucho solapamiento en la base, pero no en la forma de usarla.

‍

El stack que suele dominar DevOps

‍

Lo normal es encontrar Jenkins, GitHub Actions, GitLab CI, Terraform, Kubernetes, Prometheus, Grafana, Loki, Datadog o Splunk en manos de un DevOps. No porque todas sean exclusivas de ese rol, sino porque encajan con su misión, desplegar, observar, corregir y repetir. La pregunta importante no es qué herramienta conoce, sino si la usa para estabilizar un servicio concreto o para diseñar una base común.

‍

El stack que empuja a Platform Engineering

‍

Un Platform Engineer suele añadir herramientas como Backstage, Crossplane, Argo CD, portales internos, plantillas, políticas y flujos de autoservicio. Ahí aparece la idea de IDP como producto, no como repositorio de scripts. Si la plataforma está bien pensada, el equipo de desarrollo consume una interfaz simple y no necesita tocar la complejidad de infraestructura cada vez.

‍

El criterio útil es este. Si la herramienta sirve para entregar un producto mejor, estás en territorio DevOps. Si la herramienta sirve para reducir el coste cognitivo de muchos equipos a la vez, ya estás en platform engineering.

‍

Cómo leer una propuesta de stack sin dejarte engañar

‍

Mira si el equipo habla de ownership, guardrails y adopción, o si solo enumera tecnologías. Un catálogo de herramientas no dice nada sobre madurez. En cambio, un stack que une templates, políticas, observabilidad y autoservicio suele indicar que la organización ya está intentando operar como plataforma.

Cuándo contratar un DevOps y cuándo un Platform Engineer

‍

Aquí es donde mucha gente se equivoca, porque decide por título y no por señales. Si tu empresa todavía necesita estabilizar despliegues, reducir errores operativos y poner orden en CI/CD, contrata DevOps. Si ya tienes varios squads repitiendo los mismos flujos, acumulando tickets y pidiendo excepciones constantes, contrata Platform Engineering.

‍

Señales de que necesitas un DevOps

‍

Empieza por lo básico. Si cada release exige intervención manual, si la infraestructura aún no está bien automatizada, o si los incidentes se resuelven a costa de héroes internos, lo que te falta es músculo DevOps. Ese perfil te ayuda a ordenar entrega, observabilidad y operación sin crear una capa extra antes de tiempo.

‍

Señales de que necesitas un Platform Engineer

‍

La pista más clara es el sprawl de herramientas. Si cada squad usa una forma distinta de desplegar, monitorizar o provisionar, ya no estás resolviendo un problema local, estás pagando una ineficiencia estructural. También deberías pensar en platform engineering cuando el volumen de tickets a infra deja de ser ruido y pasa a ser parte del proceso diario.

‍

Cómo decidir sin autoengañarte

‍

• Pocos equipos y mucha fricción operativa: contrata DevOps.
• Muchos squads repitiendo el mismo trabajo: contrata Platform Engineering.
• Demasiados tickets a infra y poco autoservicio: contrata Platform Engineering.
• Pipelines rotos, despliegues frágiles y poca observabilidad: contrata DevOps.
• Necesidad clara de estandarizar rutas de despliegue: contrata Platform Engineering.
• Un producto todavía pequeño con operación inmadura: contrata DevOps primero.

‍

No mezcles la solución con el problema. Un platform engineer en una organización inmadura suele acabar diseñando una plataforma para muy poca gente. Un DevOps en una organización ya fragmentada puede convertirse en un cuello de botella si no existe una capa común. La secuencia correcta importa, primero estabilidad y automatización útil, después plataforma interna reusable.

‍

Señal organizativaPerfil recomendadoPor quéNecesitas automatizar despliegues y reducir erroresDevOpsEl problema principal está en la entrega y la operación diariaHay demasiados tickets a infraestructuraPlatform EngineerHace falta autoservicio y una capa reutilizableCada squad trabaja con flujos distintosPlatform EngineerEl coste de mantener excepciones ya es demasiado altoLos incidentes te consumen demasiado tiempoDevOpsFalta músculo operativo y respuesta tácticaQuieres estandarizar rutas de desplieguePlatform EngineerEl equipo necesita golden paths y guardrailsTu stack aún es pequeño y cambianteDevOpsNo merece la pena productizar antes de estabilizar

‍

La evolución hacia plataformas AI-ready

‍

La discusión ya no se gana comparando etiquetas. Se gana mirando qué cambia cuando la empresa empieza a meter IA, automatización asistida y cargas más pesadas en la misma base operativa. En ese punto, DevOps y platform engineering dejan de ser títulos y pasan a ser capas distintas de una misma respuesta. Tanium explica que la automatización con IA puede acelerar la autoprovvisión y también borrar controles que antes ponía un operador con experiencia, y eso obliga a rediseñar responsabilidades. Tanium sobre platform engineering y DevOps

‍

DevOps se mueve hacia automatización asistida

‍

El DevOps de hoy ya no se puede quedar en montar pipelines y revisar alertas. Tiene que entrar en automatización de incidentes, validaciones asistidas por LLM y observabilidad que detecte antes los problemas y reduzca la carga manual del equipo. Eso no mata el rol, lo endurece. El perfil que siga operando a mano se queda atrás en cuanto la operación crece.

‍

Platform Engineering absorbe la capa AI-ready

‍

El otro cambio es más estructural. Cuando entran flujos Dev+ML, inferencia o GPU, la plataforma deja de ser una simple capa de despliegue y pasa a sostener cargas mixtas con reglas propias. Si una empresa ya está metiendo IA en producto o en operaciones, el equipo de plataforma tiene que construir servicios reutilizables para esa realidad, no una infraestructura genérica que luego se parchea a toda prisa.

‍

En España, el uso de IA en pymes y medianas va más rápido de lo que muchas organizaciones reflejan en su organigrama técnico. Si el roadmap incluye IA aplicada, hay que revisar también cómo encajan estos perfiles con talento especializado en programadores de IA, porque la frontera entre plataforma, datos y ejecución de modelos se está difuminando.

‍

Mi lectura: el futuro no pasa por elegir entre DevOps y Platform Engineering. Pasa por construir una plataforma que soporte IA sin rehacerla cada poco tiempo.

‍

Para hiring, la conclusión es directa. Si el equipo solo contrata para apagar incendios, se quedará corto cuando cambie la carga. Si contrata plataforma sin pensar en el uso de IA, acabará diseñando algo elegante pero incompleto. Para aterrizar estas decisiones en entrevistas, conviene apoyarse en una guía práctica como las preguntas de una entrevista y comprobar si el candidato entiende la operación real, no solo la teoría.

‍

Checklist de contratación y preguntas de entrevista

Empieza por revisar el problema, no el CV. Si el candidato encaja en el rol equivocado, da igual lo brillante que parezca en papel. Un proceso serio separa experiencia técnica, mentalidad operativa y forma de pensar el escalado.

‍

Checklist rápido antes de abrir la vacante

‍

• Número de squads activos: si ya hay muchos equipos chocando con la misma fricción, mira platform engineering.
• Volumen de tickets a infra: si el equipo vive respondiendo peticiones repetidas, necesitas estandarización.
• Frecuencia de cambios: si el ritmo de entrega exige automatización más fiable, busca DevOps.
• Sprawl de herramientas: si cada equipo usa su propio camino, ya hay deuda de plataforma.
• Nivel de autoservicio actual: si los desarrolladores dependen demasiado de operaciones, hay trabajo para ambos perfiles, pero en distinto orden.
• Madurez de observabilidad: si no hay visibilidad consistente, DevOps suele ser el primer paso.

‍

Preguntas que sí separan perfiles

‍

Para DevOps:

• ¿Cómo diseñarías un pipeline que reduzca errores sin ralentizar el equipo?
• Cuéntame un incidente real que hayas estabilizado y qué automatizaste después.
• ¿Qué parte de la operación no debería seguir siendo manual?

‍

Para Platform Engineer:

• ¿Cómo decidirías si una petición de un squad merece convertirse en un golden path?
• ¿Qué harías para evitar que la plataforma se convierta en un cuello de botella?
• ¿Cómo medirías si tu plataforma está reduciendo fricción de verdad?

‍

Qué escuchar en las respuestas

‍

Busca decisiones, no slogans. Un buen DevOps habla de recuperación, automatización y control operativo. Un buen Platform Engineer habla de reutilización, experiencia interna, gobernanza y adopción. Si el candidato no distingue entre resolver un problema puntual y construir una capacidad interna reusable, no está listo para el rol que estás intentando cubrir.

‍

Si estás contratando en España y no quieres perder semanas filtrando perfiles que no encajan con la madurez real de tu equipo, en Kulturo trabajamos justo ese tipo de hiring técnico, con foco en el perfil correcto para cada fase de crecimiento. Trae el contexto de tu equipo, no solo el título de la vacante, y te ayudarán a acertar más rápido.