"Un ser humano debería ser capaz de cambiar un pañal, planear una invasión, carnear un cerdo, gobernar un barco, diseñar un edificio, escribir un soneto, llevar las cuentas, levantar una pared, entablillar un hueso, consolar a un moribundo, recibir órdenes, dar órdenes, cooperar, actuar solo, resolver ecuaciones, analizar un problema nuevo, palear estiércol, programar una computadora, cocinar una buena comida, pelear eficientemente, morir con gallardía.
La especialización es para los insectos." — Robert A. Heinlein
Aprendí lo básico de programación cuando estaba en el colegio, rompiendo la Wang 286 del laburo que mi viejo trajo a casa en el 87. Era la primera computadora en Lobos, el pueblo en el que vivíamos. Nunca se me ocurrió que podía vivir de algo relacionado.
A los catorce empecé a tocar el piano. Terminé tocando en un grupo de folklore que, después de unos años de medallas de diferentes colores, ganó los Torneos Juveniles Bonaerenses y un viaje a Europa (aparentemente todavía quedaba algo en las arcas de la provincia en los '90). Como parte del premio, tocamos para el papa Juan Pablo II. Nunca más volví a tocar después de eso.
A los diecisiete me mudé a Buenos Aires a estudiar economía con tres pibes a los que apenas conocía: mi viejo habló con cuanto padre con hijos de la misma edad se cruzó para repartir el costo del alquiler.
Conseguí mi primer trabajo haciendo soporte e implementando ERPs, hasta que me aburrí de customizarlos y me metí a ver cómo estaban construidos. Terminé cambiando de carrera para estudiar sistemas.
A los veinticinco había pasado por múltiples roles e industrias. Lideraba proyectos tech en toda LatAm, y por necesidad había aprendido lo suficiente de cada rol a mi alrededor (ingenieros, sysadmins, analistas de negocio, project managers) como para mantener todo funcionando cuando alguien se iba de vacaciones, renunciaba, o le pasaba el bondi proverbial por encima.
También había aprendido a cambiar los pañales de mi hija recién nacida.
Dos tipos de carrera
Me encanta obsesionarme con temas. Desde siempre. Me gusta tirar del hilo hasta que la mayor parte del día se me va en eso. En algún momento lo suelto (algo inconsciente sobre el costo marginal de mejorar un 1%, supongo). Queda ahí, en segundo plano, hasta que años después resurge porque combina bien con algo nuevo que estoy aprendiendo, o me ayuda a entender algo más complejo.
En mis primeros trabajos entendí que las corporaciones no tienen una buena cajita para esto. No caía bien que codeara cuando era manager, o que hablara con ventas cuando era tech lead. A nadie le cae bien la persona que se saltea el organigrama. Por eso terminé pivoteando a startups. Podía pasar de arquitectura a una llamada con un cliente, o de hiring a producto, según el incendio de turno.
Pero ojo, este tipo de carrera rara vez va hacia arriba y a la derecha. La mía a veces fue de costado, o incluso directamente hacia abajo. Acepté trabajos que pagaban menos porque me daban acceso a cosas que todavía no entendía. FinTech, InsurTech, AgTech, BioTech, lo que se te ocurra.
Si hubiera seguido un camino de especialista, las cosas habrían sido obviamente diferentes. La especialización me habría empujado a profundizar en una única área. Y, en un mundo estable, ese expertise paga: retornos seguros, un path de carrera, un aumento de sueldo cada año.
Pero la parte que pasa desapercibida es que es una apuesta cóncava. Cuando toda la ventaja es conocer un dominio mejor que nadie, cualquier disrupción en ese dominio es una amenaza existencial. Imaginate dedicar toda tu vida a manejar un carruaje tirado por caballos, o a operar un ascensor.
Una carrera generalista es la apuesta opuesta. Es convexa. Te equivocás mucho. Algunos saltos no llevan a nada, aceptás cobrar menos para cambiar de trabajo y abandonás habilidades para empezar de cero infinidad de veces.
Durante la pandemia noté que crecía la demanda de vino, así que contacté por LinkedIn al fundador de una empresa que organizaba eventos de vinos. Me respondió y terminé armando algo con Next.js, Node.js y PostGIS que permitía buscar vinos cercanos, algo parecido a Drizly. El proyecto no prosperó.
Pero el stack y la arquitectura no fueron a la basura. Reconvertí el proyecto para buscar autos cercanos y terminó siendo la primera versión del marketplace de prendo.ar.
Esa es la forma de la apuesta convexa del gráfico de abajo: el proyecto de vinos falló, pero la inversión de tiempo terminó pagando en una dirección que no había planeado.
La amplitud también necesita profundidad
Ojo, no estoy argumentando a favor de saber un poco de todo. Ser superficial tiene muy poco upside. Lo que describo se parece más a lo que Kent Beck llama un "paint drip": movés el pincel por el lienzo siguiendo tu curiosidad y la profundidad se forma donde te quedás el tiempo suficiente. Terminás siendo bueno en varias cosas, y la combinación se convierte en tu ventaja.
Cuando empecé a manejar equipos más grandes, extrañaba entender los problemas técnicos. Extrañaba compartir el dolor con el equipo. Recuerdo tener que respaldar sus estimaciones para una tecnología oscura del ecosistema SAP con la que nunca había trabajado. Me resultaba imposible discutir los trade-offs entre riesgo de entrega, fechas y comprometerme con algo que implicaba darles mi palabra a clientes y líderes.
Así que pasé noches larguísimas aprendiendo lo suficiente como para debatir con las personas técnicamente más fuertes de mis equipos. Eso me ayudó a ajustar alcance, negociar fechas y explicar riesgos. No intentaba equiparar su conocimiento, necesitaba la profundidad suficiente como para hacer preguntas útiles y respaldar la respuesta.
Y si estás construyendo un compilador, diseñando un avión u operando un cerebro, no necesitás un renacentista. Querés a la persona que hizo esa única cosa diez mil veces.
En Magoya contraté a alguien que había trabajado específicamente con Apache Camel integrando y orquestando datos de campo de John Deere, FieldView y maquinaria similar. Ya conocía los formatos de cada proveedor, los problemas de conexión en el campo y las particularidades de esos sistemas. Contratar a alguien con esa experiencia acortó muchísimo los tiempos de entrega.
Entonces, ¿cuándo conviene valorar la especialización por encima de la generalización?
David Epstein plantea una distinción útil en Range: algunos entornos son "amables" y otros son "wicked".
Malcolm Gladwell popularizó la idea de que dominar algo requiere 10.000 horas de práctica en un único dominio. En el debate que aparece abajo, Gladwell concedió que el principio funciona en entornos amables, donde las reglas son claras, el feedback es inmediato y los patrones se repiten. Ajedrez. Cirugía. Tenis.
Pero la mayor parte de la vida no transcurre en entornos amables. Transcurre en lo que Epstein llama un entorno wicked. Las reglas no son claras, el feedback llega tarde o engaña, y podés hacer lo correcto y aun así obtener el resultado equivocado. Los negocios son wicked. La estrategia es wicked. La innovación es wicked.
La ventaja menos expuesta
La profundidad no es el problema. El problema es tener una sola área de profundidad. El conocimiento profundo queda expuesto cuando solo se puede aplicar a problemas con reglas estables y respuestas conocidas. La AI se está volviendo muy buena en eso. Pero todavía necesitamos decidir qué problema resolver cuando las reglas no son claras.
¿A quién premiará más un mundo cada vez más exponencial y dominado por AI: al especialista o al "generalista experto"?
Daniel Rabinovich, COO y ex CTO de Mercado Libre, dice que nada es más riesgoso hoy que ser un superespecialista. Además de gestionar 140.000 personas, es mago, ajedrecista, speedcuber y músico.
Este estudio de Harvard publicó 166 problemas de I+D que equipos de especialistas no habían podido resolver. Alrededor de un tercio fueron resueltos por gente de afuera, y cuanto más alejado estaba el campo de quien resolvía del dominio del problema, más probable era que lo resolviera. Químicos resolviendo problemas de biología. Físicos resolviendo problemas de química.
Los de afuera no eran necesariamente mejores para resolver el problema original. La distancia con el campo les facilitaba otra perspectiva. La amplitud te da más que conocimiento adicional; te da más lugares desde donde mirar un problema.
En una empresa, mi equipo de ingeniería veía picos extraños en las operaciones al comienzo de cada mes. Como podían afectar el capacity planning, el equipo estaba buscando una explicación técnica. Yo ya había trabajado con equipos de ventas y sabía que cobraban contra objetivos mensuales. Cuando alguien llegaba al objetivo, retenía operaciones hasta el período siguiente. No había nada que arreglar (técnicamente, al menos).
Cuanto más trivial vuelve AI la ejecución técnica, más relevante se vuelve decidir qué problema vale la pena resolver.
Cuando salió Opus 4.5, cerca de diciembre de 2025, lo probé contra nuestro take-home para entrevistas técnicas: construir un orquestador de cotizaciones de seguros con Node.js y React. El modelo resolvió la solución de una. El código terminado ya no me decía nada de cómo pensaba el candidato.
Ahora entrego el ejercicio unos minutos antes de la prueba en vivo y lo construimos juntos durante la llamada (el candidato puede usar AI). No necesito averiguar si puede producir el código. Necesito entender cómo piensa mientras lo produce.
Como generalista, trabajé toda mi vida para ser tan bueno como los especialistas en cada tema. La AI no cambió eso. Solo me permite entrar más rápido en un tema. Todavía necesito saber lo suficiente para notar cuándo la respuesta no cierra, y sigue habiendo momentos en los que necesito especialistas de verdad. La ventaja no es saber todo. Es reconocer qué tipo de problema tengo adelante y a quién o qué necesito para resolverlo.
Nadie busca a un generalista
Pero hay un problema con el enfoque del generalista experto: explicar qué hago. Nadie busca a un generalista. Un recruiter busca un rol específico. Un founder busca ayuda con un problema específico. "Hice muchas cosas distintas" no es una respuesta útil para ninguno de los dos.
"CTO Fraccional" por sí solo sigue siendo demasiado amplio. Una de mis landings es CTO Fraccional para startups de Estados Unidos entre pre-seed y Serie A. Un rol, una etapa de empresa, un mercado. Un founder que necesita lanzar un producto, armar un equipo o prepararse para una due diligence técnica puede saber si esa página es para él.
Una vez que estoy trabajando con ellos, el título importa menos. Un día puedo revisar una arquitectura y al siguiente ayudar con hiring o sumarme a una llamada con un cliente.
El título les dice dónde encontrarme. No me restringe a qué puedo aprender después.
Así que, si llegaste hasta acá, me gustaría que volvieras al principio del artículo y leyeras la cita de Heinlein. Quizás sea hora de cambiar un pañal, planear una invasión, escribir un soneto, programar una computadora y cocinar una buena comida.
Después de todo, para eso estamos los humanos.
La especialización es para los insectos.
