Stack vs. talento: qué contratar primero¶
6 minutos de lectura · 30 marzo 2026
La pregunta sale en cada arranque de equipo: "buscamos un senior de React" o "buscamos un buen ingeniero, da igual el stack". Las dos posturas tienen razones razonables. Y las dos, llevadas al extremo, fallan.
Contratar por stack escala mal. Contratar por talento abstracto sube el coste de onboarding.
He probado las dos en momentos distintos. Lo que sigue es lo que aprendí del coste real de cada una.
La trampa del puesto exacto¶
"Necesitamos a alguien que sepa React 18, Next.js, Tailwind, tRPC, Prisma y Postgres."
Suena específico, parece eficiente. En la práctica:
- El pool de candidatos con esa intersección exacta es diez veces más pequeño que el de candidatos con cuatro de los seis.
- Esa especificación se queda obsoleta en dieciocho meses. La persona contratada para "React 18 + tRPC" puede acabar manteniendo otra stack distinta en dos años.
- Quien encaja al 100% en el job description suele tener menos margen para aprender. Es un proxy de "ya sabe lo que va a tener que hacer", no de "puede crecer en lo que venga".
He visto equipos atascados durante meses buscando el perfil exacto. Cuando por fin contratan, han pagado tres meses de retraso para reducir el onboarding una semana.
La trampa del "buen ingeniero abstracto"¶
El extremo opuesto: "no nos importa el stack, contratamos cabeza".
Es lo que Google y compañía hicieron durante años. Algoritmos en la pizarra, candidatos brillantes que llegaban sin haber tocado el stack interno.
El coste oculto:
- Onboarding técnico real: seis a doce semanas hasta productividad neta. En equipos pequeños no te lo puedes permitir.
- Coste de oportunidad de los seniors actuales que dedican esas semanas a explicar la stack en lugar de ejecutar.
- Riesgo de mismatch cultural con el lenguaje: "voy a reescribirlo en Rust" después de tres semanas no es lo que necesitabas oír.
Y otro problema sutil: el "buen ingeniero abstracto" suele tener su propia opinión sobre arquitectura, tooling y procesos. Si tu equipo es chico y ya está formado, esa opinión es valiosa pero también potencialmente disruptiva.
La heurística que uso ahora¶
Para cada hire, antes de abrir el puesto, respondo dos preguntas:
- ¿En cuánto tiempo necesito contribución neta?
- ¿Cuánto va a cambiar la stack en dos años?
Y según las respuestas:
| Plazo / Cambio de stack | Stack cambia poco | Stack cambia mucho |
|---|---|---|
| Necesito ya (1-2 meses) | Por stack | Por stack adaptable (lenguajes próximos, ecosistema similar) |
| Tengo tiempo (3-6 meses) | Por talento + experiencia en problema parecido | Por talento puro |
Lo importante es que rara vez estoy en la diagonal cómoda. Casi siempre es un trade-off. La heurística obliga a hacerlo explícito.
Lo que importa más que el debate¶
En la mayoría de los hires que hice, ni "stack" ni "talento abstracto" eran el factor decisivo. Lo era:
- Comunicación escrita. Cómo escribe el candidato un email, una review, una propuesta. Predice 70% del trabajo que va a hacer en remoto.
- Capacidad de decir "no sé". Tres veces en una entrevista técnica. Si no aparece nunca, es bandera roja, especialmente en seniors.
- Curiosidad genuina por qué hacemos y no solo por cómo. Las mejores preguntas que me han hecho candidatos eran sobre el negocio, no sobre el stack.
Esos tres ejes correlacionan mejor con "esta persona va a funcionar aquí" que la suma del stack y el talento.
La regla práctica¶
Si tienes que escoger entre dos candidatos donde uno sabe el stack pero te incomoda algo de su forma de comunicar, y el otro no sabe el stack pero comunicarías con él sin esfuerzo:
Contrata al segundo. El stack se aprende en seis semanas. La forma de pensar y comunicar, no.
Esa regla ha sido la más cara de seguir y la más rentable de las que he aplicado.
Próxima entrada
Las primeras dos semanas de onboarding tienen un patrón que sí escala. En la siguiente parte cuento la plantilla que uso, escrito como si fuera para alguien que aún no llegó.
¿Comentarios o correcciones? info@encodigo.es.