La mayoría del contenido sobre a players empieza mal. Parte de una fantasía importada de Silicon Valley: una persona brillante, incansable, con criterio perfecto, que eleva cualquier empresa solo con entrar por la puerta.
En el mercado español, ese marco sirve de poco. No porque no exista talento excepcional, sino porque una startup no gana por fichar currículums espectaculares. Gana cuando pone a gente muy buena en un sistema donde pueden ejecutar, decidir y multiplicar al resto sin quedar atrapados entre procesos rotos, prioridades cambiantes y managers ausentes.
He visto CTOs perder meses buscando “el mejor perfil del mercado” para descubrir después que el problema no era el nivel técnico del equipo. Era otro: rol mal definido, proceso de evaluación flojo, compensación mal explicada, onboarding improvisado y una cultura que castigaba la autonomía mientras decía valorarla. Ahí no rinde nadie. Ni un perfil medio, ni uno excelente.
Si quieres contratar a players de verdad en España, tienes que cambiar la pregunta. No es “¿cómo encuentro a alguien top?”. Es “¿qué tipo de persona puede generar impacto aquí, en esta fase, con estas limitaciones, y qué contexto necesita para hacerlo?”.
Por qué la definición de 'A Player' no te sirve
El problema de la etiqueta A Player es que casi siempre significa algo vago. Para algunos CTOs es “alguien más listo que la media”. Para otros, “alguien de una gran marca”. Para otros, “alguien que puede con todo”. Ninguna de esas definiciones ayuda a contratar bien.
En una startup española, el contexto importa más que el mito. No necesitas al mejor ingeniero abstracto posible. Necesitas a la persona que pueda rendir en tu fase actual. Eso cambia mucho si estás construyendo producto, escalando arquitectura, levantando un equipo desde cero o intentando ordenar una plataforma que ya va tarde en casi todo.
El error de copiar arquetipos ajenos
El arquetipo del supuesto 10x developer hace daño por dos motivos. Primero, porque simplifica demasiado el rendimiento. Segundo, porque empuja a evaluar señales muy pobres: marcas conocidas, discurso brillante, velocidad en entrevistas o confianza excesiva.
Un perfil puede ser fortísimo en una empresa con producto maduro, capas de soporte, tooling excelente y managers sólidos. Ese mismo perfil puede fracasar en una startup con ambigüedad, deuda técnica y prioridades cambiantes. Lo contrario también pasa. Hay perfiles que no deslumbran en una entrevista tradicional y luego son decisivos cuando hay que poner orden, tomar decisiones con información incompleta y entregar sin dramatismo.
Un a player fuera de contexto no es un acierto. Es una contratación cara con expectativas equivocadas.
Lo que de verdad deberías cuestionar
Si defines a tu a player solo por excelencia técnica, te dejas fuera media ecuación. En startups, el rendimiento depende de cómo una persona opera bajo restricciones reales: equipo pequeño, producto en movimiento, dependencia de negocio, presión por entregar y ausencia de manual.
Antes de abrir una vacante, un CTO debería responder tres preguntas:
- Qué problema exacto debe resolver esta persona. No el puesto genérico, sino el cuello de botella real.
- Qué nivel de autonomía puede soportar el equipo. Hay empresas que dicen buscar seniority, pero luego bloquean cualquier decisión.
- Qué fricciones del contexto van a frenar a alguien bueno. Falta de ownership, backlog caótico, roadmap errático, salarios fuera de mercado o entrevistas eternas.
Si no aclaras eso, acabarás buscando un personaje ficticio. Y los personajes ficticios no se fichan.
El verdadero significado de un 'A Player' en una startup
Un a player no es el perfil más impresionante sobre el papel. Es la persona que combina alto rendimiento individual , alineación con el momento de la empresa y capacidad de elevar el nivel del equipo. Si falta una de las tres, el impacto real cae mucho.
Alto rendimiento no basta
Hay ingenieros técnicamente brillantes que crean dependencia, discuten cada decisión menor o desprecian el ritmo que necesita negocio. Eso no es talento de categoría A. Eso es una fuente de fricción.
En una startup, el rendimiento bueno tiene forma operativa. Significa resolver problemas relevantes, elegir compromisos razonables y mantener calidad sin convertir cada entrega en una tesis doctoral. Un senior que sabe cuándo simplificar suele aportar más que otro que siempre persigue la solución más elegante.
La alineación con la fase cambia el valor
No todos los perfiles excelentes valen para todas las fases. Un especialista de infra muy profundo puede ser una contratación brillante para una scaleup que ya sufre complejidad operativa. Puede ser una mala decisión en una empresa que aún necesita validar producto y moverse rápido con un stack sencillo.
Por eso, cuando hablo con CTOs, insisto en separar “perfil fuerte” de “perfil adecuado”. Un a player para una startup seed no es el mismo que para una empresa con varias squads, compliance encima y capas claras de ownership. La pregunta útil no es si la persona es buena. Es si va a generar impacto en este sistema concreto.
El efecto multiplicador distingue a los mejores
El rasgo más infravalorado es éste. Los mejores no solo ejecutan bien. Mejoran cómo decide y cómo trabaja el resto. Suben el estándar de code review, aclaran prioridades, documentan lo suficiente, detectan riesgos antes de que exploten y ayudan a que otros entreguen mejor.
Eso es densidad de talento bien entendida. No una colección de egos fuertes, sino un equipo donde una persona muy buena hace mejores a los demás. Si alguien rinde mucho pero baja el rendimiento colectivo, no has fichado un a player. Has fichado un problema sofisticado.
Regla práctica: si una persona necesita que toda la empresa se adapte a sus manías para rendir, no estás ante un perfil A. Estás ante una dependencia peligrosa.
Mira más allá de las credenciales tradicionales
Otra mala costumbre del mercado es confundir pedigree con potencial. La conversación sobre a players tiene que ir más allá de “contratar a los mejores” entendidos como quienes vienen validados por las redes de siempre. La evidencia sobre founders subrepresentados muestra que el acceso desigual a capital y relaciones distorsiona quién recibe oportunidades visibles. En startups financiadas, los founders blancos representan el 77,1% , frente al 1,8% de latinos y el 1% de negros, y las mujeres reciben solo el 9% de la inversión, como explica el análisis de McKinsey sobre founders infraestimados.
La lectura útil para recruiting técnico es obvia. Mucho talento de alto impacto no viene envuelto en credenciales tradicionales. No siempre trabaja en la marca famosa. No siempre habla mejor en entrevista. No siempre tiene la red adecuada para llegar primero a tu proceso.
Un CTO fino detecta otra cosa: aprendizaje rápido, criterio bajo ambigüedad y capacidad de producir valor sin necesitar un entorno perfecto.
Rasgos concretos de 'A Players' por rol técnico
La teoría sirve hasta que abres una vacante. Ahí lo importante es bajar la etiqueta a comportamientos observables. No hablo de listas de tecnologías. Hablo de cómo piensa y cómo decide una persona cuando el trabajo se complica.
Senior Backend
En backend, un a player no es quien nombra más patrones de diseño. Es quien sabe construir sistemas útiles para el negocio sin hipotecar al equipo.
Yo buscaría estos rasgos en conversación técnica:
- Equilibra velocidad y deuda técnica. No vende reescrituras innecesarias, pero tampoco parchea todo eternamente. Sabe explicar qué deuda merece atención y cuál puede esperar.
- Diseña para operar, no solo para compilar. Piensa en observabilidad, fallos, degradación y mantenibilidad. Habla de cómo vivir con el sistema después del deploy.
- Reduce complejidad. Si una persona responde a cada problema con más capas, más servicios o más abstracción, desconfía. El backend senior bueno simplifica.
Un buen ejercicio en entrevista es plantear una API o flujo crítico que hoy sufre picos, incidencias o requisitos cambiantes. Escucha cómo prioriza. Si se lanza a rediseñar todo desde cero, probablemente no entiende bien el contexto startup.
ML Engineer
Aquí se contrata mal con frecuencia. Muchas empresas se enamoran de perfiles que optimizan notebooks, afinan modelos y hablan bien de investigación, pero no aterrizan nada en producción.
Un a player de ML en startup suele mostrar otra mezcla:
- Piensa en producción desde el principio. Versionado, inferencia, monitorización, datos, coste operativo y mantenimiento.
- Conecta la solución con una decisión de negocio. No persigue mejoras marginales de laboratorio si no cambian nada relevante en producto o revenue.
- Acepta compromisos feos pero útiles. A veces un enfoque más simple llega antes y resuelve mejor el problema real.
En deporte profesional, los equipos que trabajan carga y rendimiento no se quedan solo con una métrica obvia. Priorizan volumen, intensidad y densidad para entender cuánto se entrenó, cuán exigente fue el estímulo y con qué frecuencia se repitió. Además, con sensores IMU usan métricas como Accumulated Acceleration Load , Mechanical Load y Jump Load para captar componentes que el GPS puro no detecta, según explica Kinexon en su análisis sobre analítica deportiva. En ML pasa algo parecido. Si evalúas solo la precisión aparente del modelo, te pierdes parte de la carga real del sistema: mantenimiento, deriva, latencia y dependencia del equipo.
Un ML engineer fuerte no te vende un modelo mejor. Te explica cómo ese modelo vivirá en producción sin convertirse en un problema recurrente.
DevOps y Platform
Muchos CTOs describen este rol como “alguien que lleve la infraestructura”. Esa definición se queda corta. El a player de DevOps o Platform no administra piezas. Diseña un entorno donde otros equipos puedan entregar mejor.
Se nota en tres comportamientos:
- Construye para acelerar a otros. Su trabajo no termina en Terraform, Kubernetes, GitHub Actions o AWS. Piensa en developer experience, tiempos de espera y fricción operativa.
- Automatiza lo repetitivo con criterio. No automatiza por deporte. Elige bien qué merece estandarización y qué puede seguir manual mientras el equipo aprende.
- Convierte incidentes en mejoras sistémicas. No solo apaga fuegos. Deja al equipo menos expuesto al siguiente.
Data y analítica de producto
En data, un a player no es quien hace dashboards elegantes en Looker, Power BI o Metabase. Es quien convierte eventos y datos dispersos en decisiones mejores.
Un paralelismo útil viene del fútbol profesional. En academias, los practicantes monitorizan mucho más las métricas técnicas y tácticas en partido que en entrenamiento: 89% y 91% en match frente a 80% y 64% en training, y el propio estudio concluye que automatizar con tecnologías como IMU montadas en el pie ayudaría a convertir ese seguimiento en feedback accionable. También observa que el tiempo medio sobre el balón se considera 20% más importante en partido y las posesiones medias del equipo 15% más relevantes en match, como recoge este estudio en PMC sobre monitorización en academias de fútbol. En startups tech, la lección es clara: la ventaja rara vez está en recolectar más datos. Está en montar pipelines útiles y devolver señales accionables a producto, ingeniería y negocio.
Por eso, en perfiles de data, busca gente que ordene eventos, defina métricas con precisión y pelee por instrumentación útil. No solo por reporting bonito.
El proceso de evaluación para detectar el talento real
Si tu proceso depende de algoritmia de pizarra para roles senior, estás filtrando por una habilidad que casi nunca coincide con el trabajo diario. Eso no significa eliminar exigencia. Significa moverla a pruebas con señal real.
Paso uno y dos con señal alta
Empieza por un filtrado serio. No busques años de experiencia como proxy universal. Lee trayectoria, tipo de problemas resueltos, contexto de equipo, cambios de responsabilidad y calidad aparente de las decisiones tomadas.
Después, pasa rápido a una conversación técnica útil. Nada de trivia. Mejor un problema parecido al que viviría en el rol.
Dos formatos suelen funcionar bien:
- System design aterrizado. No “diseña YouTube”. Mejor “tenemos este servicio, este cuello de botella y estas restricciones”.
- Code review o debugging colaborativo. Ves criterio, comunicación y capacidad de priorizar defectos reales.
Entrevista conductual con evidencia
Aquí es donde muchos procesos se vuelven blandos. Preguntan por fortalezas, debilidades y preferencias. Eso da respuestas preparadas y poca información.
Haz preguntas de comportamiento pasado. Si quieres evaluar ownership, conflicto o criterio, pide situaciones concretas. Para estructurarlas bien, conviene trabajar con un marco claro de entrevistas por competencias aplicado a hiring técnico.
Ejemplos de preguntas con señal:
- Cuéntame una decisión técnica impopular que defendiste. Qué contexto había, qué riesgo viste y qué pasó después.
- Háblame de una vez que entregaste algo con información incompleta. Cómo elegiste y qué sacrificaste.
- Describe un conflicto fuerte con producto, negocio o un peer técnico. Qué hiciste para resolverlo.
Si la persona solo habla en abstracto, no has llegado al comportamiento real. Sigue preguntando hasta entender qué hizo, qué decidió y qué aprendió.
El take-home bien usado
No estoy en contra del take-home. Estoy en contra del take-home largo, ambiguo y gratuito. Si pides trabajo fuera de entrevista, debe respetar el tiempo del candidato y parecerse al trabajo de verdad.
Qué sí evaluaría:
- Claridad del código. No solo si funciona.
- Decisiones de arquitectura. Qué simplifica, qué deja fuera y por qué.
- Capacidad de explicar trade-offs. Un comentario bien razonado vale mucho.
Qué evitaría:
- Mini productos completos.
- Pruebas sin feedback.
- Ejercicios desconectados del rol.
Cómo decidir sin autoengañarte
La última parte del proceso falla más por sesgo que por falta de datos. Después de varias entrevistas, el riesgo es premiar a quien “ha gustado” más, no a quien encaja mejor con el problema real.
Haz una reunión de decisión con criterios escritos antes de hablar. Tres o cuatro, no doce. Por ejemplo: capacidad de ejecución, criterio técnico, autonomía y efecto sobre el equipo. Si cada entrevistador llega con notas libres y opiniones vagas, gana la intuición del más influyente.
Cómo atraer y fichar a quien no está buscando trabajo
Los mejores perfiles no suelen aparecer porque publiques una oferta correcta en LinkedIn. Aparecen cuando alguien de tu empresa les hace pensar: “ese problema me interesa” o “ahí sí podría hacer buen trabajo”.
Por eso, atraer a players no es una tarea exclusiva de RR. HH. Es una mezcla de recruiting, ingeniería y posicionamiento técnico. El mejor activo de employer branding de una startup no es un vídeo bonito de cultura. Es un equipo capaz de explicar con honestidad qué está construyendo y por qué merece atención.
Tu equipo técnico debe salir al frente
Si un CTO quiere fichar perfiles fuertes, tiene que hacerse visible. No hablo de postureo. Hablo de enseñar problemas reales, decisiones técnicas y aprendizajes de ejecución.
Tres tácticas funcionan mejor que mil mensajes fríos genéricos:
- Publicar retos técnicos concretos. Un post corto sobre una migración, un cuello de botella, una arquitectura o un sistema de ML aporta más que una oferta llena de adjetivos.
- Participar en comunidades nicho. Meetups locales, Slack, Discord, GitHub, foros especializados. No para vender vacantes de entrada, sino para formar parte de la conversación.
- Hacer sourcing con contexto. Si escribes a alguien, menciona por qué su experiencia encaja con un problema específico de tu empresa.
Para inspirarte, merece la pena mirar cómo equipos de producto e ingeniería cuentan su trabajo en los blogs técnicos de Netflix o Shopify. No porque tengas que copiarlos, sino porque entienden algo básico: el talento técnico responde a problemas interesantes y a equipos serios, no a slogans.
La oferta debe vender contexto, no solo salario
En España, muchos procesos pierden candidatos buenos por una razón simple. La empresa presenta compensación y proyecto de forma poco clara. Hablan de “impacto” y “crecimiento”, pero no explican ownership, roadmap, stack, equipo, reporting line ni cómo se toman decisiones.
Cuando presentas la oferta, aterriza esto:
- Qué podrá decidir la persona en los primeros meses.
- Qué problema importante tendrá entre manos.
- Qué soporte real tendrá del manager y del equipo.
- Cómo funciona el variable o las stock options, si existen. Sin jerga y sin inflarlas.
Si necesitas ayuda para mapear talento pasivo y construir un approach más fino en el mercado local, una opción es trabajar con especialistas en headhunting tech en España que entiendan bien el tipo de rol y la fase de la empresa.
La atracción mejora cuando el candidato ve un sistema serio. No cuando recibe un pitch más optimista.
Lo que no funciona
No funciona mandar mensajes masivos con la misma plantilla. No funciona ocultar el rango y esperar entusiasmo. No funciona vender flexibilidad si luego todo requiere aprobación. Y no funciona esperar que una marca pequeña compita solo con dinero contra empresas más conocidas.
Una startup española puede ganar fichajes difíciles si ofrece otra cosa: autonomía real, problemas interesantes, acceso directo a decisión y un entorno donde se nota el trabajo bien hecho.
El trabajo empieza de verdad tras la firma del contrato
Fichar bien sirve de poco si el aterrizaje es mediocre. Un a player necesita contexto rápido, prioridades claras y un entorno que no le haga perder semanas descifrando cómo funciona todo.
Los primeros noventa días
El onboarding técnico no debería consistir en “ya irás viendo”. Eso retrasa impacto y genera frustración innecesaria. Funciona mejor un plan simple de 30-60-90 días, con objetivos visibles y feedback frecuente.
Elementos mínimos:
- Antes del primer día. Accesos, equipo, documentación útil y agenda básica.
- Primera semana. Entender producto, arquitectura, personas clave y formas de trabajo.
- Primer mes. Una contribución real, acotada y visible. Nada de tareas irrelevantes solo para “calentar”.
- Hasta el tercer mes. Más autonomía, decisiones propias y exposición progresiva a temas importantes.
Un buddy técnico ayuda mucho. También un manager que esté presente de verdad, no solo disponible en teoría.
El contexto manda también en la retención
Un perfil fuerte se queda donde puede seguir creciendo sin pelear cada día contra el sistema. Si quieres retenerlo, dale retos nuevos, claridad sobre carrera y protección frente a burocracia absurda.
La carrera no tiene por qué pasar por management. Muchas personas muy valiosas quieren crecer como individual contributors. Si tu empresa aún no ha ordenado esto, conviene definir cuanto antes un plan de carrera para perfiles técnicos con expectativas, impacto esperado y formas de progresión.
Cómo medir el impacto sin caer en métricas pobres
No midas a un perfil fuerte por ruido, visibilidad o cantidad de horas. Mídelo por su capacidad de mejorar flujo, calidad de decisión y entrega del equipo.
En fútbol español, los hitos históricos que mejor contextualizan rendimiento combinan producción y durabilidad. Lionel Messi sigue siendo el máximo goleador histórico de LaLiga con 474 goles y el jugador con más Pichichis, 8 , mientras Andoni Zubizarreta lidera los partidos disputados en Primera División con 622 durante 17 temporadas. Además, Messi firmó en 2012 un año natural récord de 91 goles , con 79 en el Barça y 12 con Argentina, como recoge Esquire en su repaso de récords del fútbol español. En equipos técnicos pasa algo parecido. No basta con un pico de brillantez. Importa la capacidad de sostener impacto útil en el tiempo.
Por eso prefiero métricas operativas y de equipo, como frecuencia de despliegue o tiempo desde cambio hasta producción, antes que indicadores vanidosos de actividad individual.
Conclusión: Tu misión es construir el entorno no el equipo
El error no está en querer fichar a players. El error está en pensar que existen como una propiedad aislada de la persona, independiente del contexto. No existen así.
Un a player en una startup española es una combinación entre talento, encaje con la fase y un sistema que le permita trabajar bien. Si contratas a alguien muy fuerte y lo metes en un entorno confuso, lento o políticamente torpe, no verás su mejor versión. Verás frustración, fricción y, muchas veces, salida prematura.
La responsabilidad real del CTO no termina con la firma. Empieza ahí. Definir bien el rol, evaluar con señal, vender el contexto correcto y construir un onboarding serio son partes del mismo trabajo. También lo es proteger al equipo de procesos que castigan la autonomía y premian el ruido.
Revisa tu última contratación técnica. No si era buena sobre el papel. Si no le diste el contexto para rendir a nivel A, el problema quizá no estuvo en el fichaje.
Si estás contratando ingenieros, perfiles de AI/ML, data o DevOps en España y quieres estructurar mejor el proceso, en Kulturo trabajamos con startups y scaleups para definir el rol, evaluar con más señal y llegar a talento técnico que encaje con el contexto real de la empresa.