Durante la última década he vivido la adrenalina de montar y escalar equipos de ingeniería en startups y scale-ups de hipercrecimiento. He tenido la fortuna de liderar equipos de tecnología en RD Station , Creditas y FARFETCH , entrevistando a más de 500 personas y contratando decenas de ellas. Si algo me queda claro después de tantas conversaciones, pruebas técnicas y cafés virtuales es que existe una dicotomía que todo líder técnico tarde o temprano debe resolver:
A continuación comparto mis aprendizajes para que sirvan de guía tanto a quienes toman decisiones de contratación como a quienes buscan crecer en su carrera.
1. Lo que aprendí construyendo equipos de cero
La tecnología es un medio, no un fin. En compañías de crecimiento exponencial, el core nunca es “ser maestros de React” o “dominar Kubernetes”, sino resolver problemas de negocio al ritmo que exige el mercado. Los procesos importan tanto como el código. Verificar cobertura de tests, orquestar pipelines de CI/CD, automatizar despliegues y monitorear métricas son prácticas que dan velocidad y confianza. Sorprendentemente, muchos “expertos” en una stack carecen de estos fundamentos. La diversidad de backgrounds eleva el listón. Cuando juntas a una persona que vivió años en PHP con otra que viene de Go y otra de Ruby, el intercambio de buenas prácticas es brutal. Esa mezcla forja equipos resilientes.
2. El mito del “experto monocorde”
Fui testigo de la fiebre por contratar a “las personas que más saben de nuestra stack”. ¿Por qué seduce tanto?
Sensación de seguridad inmediata. Creemos que alguien con 10 años en Java solucionará cualquier incidencia en minutos. Menor curva de aprendizaje en el corto plazo. Ese especialista ya habla el “idioma” del proyecto. Validez social. En la pizarra del comité suena mejor “ex-Microsoft, 12 años de C#” que “generalista curioso”.
Sin embargo, la realidad suele ser menos glamorosa:
Bloqueo al cambio. He entrevistado seniors incapaces de hacer un test unitario fuera de su framework de confort. El status quo se convierte en dogma. Silos de conocimiento. Cuando sólo una persona conoce los entresijos de un sistema crítico, la dependencia es peligrosa. Falsa sensación de seniority. Ser veterano en una herramienta no implica madurez en arquitectura, cultura DevOps o metodologías ágiles.
Lo decía Chad Fowler tras su paso por Microsoft antes de ir a GitHub: “Muchos expertos aquí no son expertos en C#, sólo han pasado años en la misma stack”.
3. El poder del profesional en T (T-shape)
Un profesional en T (T-shape) es aquel que combina una profunda especialización en un área concreta (la barra vertical de la T) con una amplia base de conocimientos generales y capacidad de colaboración interdisciplinar (la barra horizontal).
Define a un profesional “en T” como alguien que:
Aprende con rapidez, porque domina fundamentos (estructura de datos, patrones, arquitectura de sistemas). Se siente cómodo en la incomodidad, disfruta enfrentar un repo desconocido o documentación escasa. Tiene mentalidad de producto, entiende el “por qué” antes que el “cómo”. Comparte conocimiento, creando puentes entre lenguajes, infra y procesos.
Estos perfiles generan valor donde otros ven fricción:
Onboarding veloz a nuevas tecnologías. Pasar de Node a Elixir en semanas. Adaptación a pivotes estratégicos. Cuando la compañía decide migrar a microservicios, no hay drama. Innovación transversal. Introducen buenas prácticas de un ecosistema en otro (por ejemplo, testing property-based de la comunidad funcional llevado a un proyecto Python).
4. Startups vs. empresas tradicionales: ritmos distintos, prioridades distintas
En entornos donde el backlog y la estrategia pivotan cada trimestre, el generalista adaptativo brilla. En empresas de crecimiento lineal, con ciclos de release estables y sistemas legacy que perdurarán años, el especialista es indispensable para maximizar eficiencia.
5. Cómo equilibrar el equipo: la estrategia 70/30
Después de muchos intentos, y enfocado en negocios con escalabilidad, llegué a una proporción que me funciona:
70 % profesionales en T (T-shape): Políglotas digitales con profundidad en su área, hambre de aprender y compartir. 30 % especialistas: Guardianes de la excelencia técnica en las piezas más críticas.
Beneficios del mix
Aprendizaje acelerado: Los profesionales en T importan prácticas de otras áreas o tecnologías, los especialistas profundizan. Reducción de bus factor: El conocimiento ya no es un cuello de botella. Innovación con pies en la tierra: Nuevas soluciones pasan el filtro de quienes conocen la stack al detalle.
6. Recomendaciones para líderes de contratación
Entrevistas basadas en principios, no en sintaxis. Pregunta cómo resolverían un problema con pseudocódigo o diagramas. Observa su razonamiento. Pruebas prácticas con nuevas herramientas. Dame una hora para probar que esa persona puede leer documentación y entregar un “Hello World” funcional en un stack que NO domine. Explora historias de cambio. “Cuéntame la última vez que migraste de lenguaje / base de datos / cloud”. Quien no tenga ejemplos quizá sea reacio a salir de su zona de confort. Cultura de pairing y rotación. Una vez dentro, rota a la gente por repos y microservicios. La adaptabilidad se entrena.
7. Consejos para desarrolladores que quieren destacar
Invierte en fundamentos. Algoritmos, redes, bases de datos, diseño orientado a dominio. Eso trasciende modas. Haz side-projects en stacks que te reten. ¿Eres fuerte en Java? Crea un servicio en Rust. ¿Vienes de Ruby? Juega con Kotlin. Participa en comunidades cruzadas. Meetups, blogs y repos open-source donde converjan distintos lenguajes. Comunica tu capacidad de aprendizaje rápido. En tu CV y entrevistas destaca cómo subiste a producción con una tecnología que no conocías semanas antes.
8. Mirada al futuro: el “polímata digital” como estándar
Si algo he visto en RD Station, Creditas y Farfetch es que la velocidad del cambio se acelera. Hoy triunfan startups que hace cinco años ni existían; mañana un LLM reescribirá parte de nuestro stack. En ese escenario:
Las tecnologías pasan, la adaptabilidad queda. Los expertos seguirán siendo clave, pero su rol muta hacia mentores-evangelistas de calidad interna. El aprendizaje continuo será la nueva “experiencia”. No importará tanto el número de años en X, sino cuántas veces te has reinventado.
Reflexión final
Cuando contrato un developer no busco a la persona que más sabe de la herramienta de moda; busco a un profesional en T (T-shape) que pueda profundizar cuando sea necesario y adaptarse a nuevos entornos cuando las herramientas queden obsoletas. Ese perfil en T—respaldado por especialistas que aseguren la excelencia en los componentes nucleares—es lo que ha permitido a los equipos que construí liberar producto tras producto sin perder el alma innovadora que caracteriza a las startups.
Si eres líder, abre la puerta a perfiles adaptativos y construye una cultura que premie el aprendizaje continuo.
Si eres desarrollador, invierte en tu capacidad de cambiar de piel; tu valor en el mercado crecerá con cada nuevo desafío que abraces.
⭐ Te leo en comentarios: ¿cómo equilibras tú la profundidad y la amplitud en tu equipo? ¿Qué prácticas te han funcionado mejor? ¡A construir equipos más flexibles y audaces!
