"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 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. Ni se me cruzaba por la cabeza que podía vivir de algo relacionado.
A los catorce empecé a tocar el piano. Toqué en actos del colegio, en una banda de rock y en un grupo de proyección folklórica que ganó medallas de todos los colores varios años seguidos en los Torneos Juveniles Bonaerenses. La de oro vino con un viaje a Europa (sí, increíble, la Argentina de los '90) y la posibilidad de tocar ante el Papa Juan Pablo II. Una experiencia surrealista. 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.
Mientras iba a la facu conseguí mi primer trabajo haciendo soporte e implementando ERPs. Luego de un par de años 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. No tengo mucho control realmente. Mi hija les dice "micro-obsesiones". 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). Pero 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 acomodar eso. No caía bien que codeara cuando era manager, o que hablara con ventas cuando era tech lead. A nadie le caía bien que me salteara el organigrama en pos de resolver algún problema. 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 si bien es entretenido, 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 sea que me llamara la atención.
Si hubiera seguido un camino de especialista, las cosas habrían sido muy diferentes. Sería extremadamente bueno en una sola cosa. Y, en un mundo estable, ese expertise paga: retornos seguros, un path de carrera, un aumento de sueldo cada año.
Pero lo que pocos ven es que es una apuesta cóncava. Imaginate dedicar toda tu vida a manejar un carruaje tirado por caballos, o a operar un ascensor. Si toda tu ventaja es conocer un dominio mejor que nadie, cualquier disrupción en ese dominio es una amenaza existencial.
Una carrera generalista es lo opuesto. 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 (había visto su nombre en una nota de diario sobre vinos). No sólo me respondió: consiguió sumar al presidente de la asociación argentina de sommeliers y a un socio más. Terminé armando algo con Next.js, Node.js y PostGIS que permitía buscar vinos cercanos, algo parecido a Drizly. Luego de unos meses el proyecto no prosperó. Los 4 teníamos incentivos y realidades laborales diferentes, nada del otro mundo.
Pero poco después reconvertí el proyecto para buscar autos cercanos en lugar de vinos, 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: un proyecto falló, pero hubo algo que quedó y 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 detalles de los problemas técnicos. Recuerdo tener que respaldar estimaciones del equipo 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, sin la visibilidad técnica que solía tener.
Así que pasé noches larguísimas aprendiendo lo suficiente como para debatir con las personas técnicamente más fuertes de mi equipo. Eso me ayudó a ajustar alcance, negociar fechas y explicar riesgos. Obviamente no podía equiparar su conocimiento, pero necesitaba la profundidad suficiente como para hacer preguntas útiles y respaldar la respuesta.
Y entiendo que hay otros momentos, digamos construir un compilador, diseñar un avión u operar un cerebro, en los que nadie quiere 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, ¿conviene especializarse o generalizar?
Hay grandes referentes de cada lado.
David Epstein, el autor de Range, habla por el lado de los generalistas: hay reglas que aplican en entornos "amables", pero no en los "wicked".
Malcolm Gladwell, del otro lado, 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 que propuso 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 definitivamente no es un problema. El problema es tener una sola área de profundidad. Que queda expuesta cuando solo se puede aplicar a problemas con reglas estables y respuestas conocidas. Es para lo que es buena la AI. Pero todavía necesitamos decidir qué problema resolver cuando las reglas no son claras.
¿Y 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 nos da más que conocimiento adicional; nos 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ía 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.
La AI también está bajando la barrera para entrar más rápido en un tema nuevo. Eso nos da amplitud, pero todavía necesitamos saber lo suficiente para notar cuándo la respuesta no cierra.
Y sigue habiendo momentos en los que necesitamos especialistas.
Nadie busca a un generalista
Pero hay un problema con el generalista experto: explicar qué hacés. Nadie busca un generalista. Un recruiter busca un rol específico. Un founder busca ayuda con un problema específico. "Hice de todo" no le abre puertas a nadie.
Cuando arranqué como CTO Fraccional armé un one-pager con todas las cosas que podía hacer (y que había estado haciendo por años). No me llamó nadie.
Después empecé a postear con constancia y a hablar con gente de mi red que tenía problemas concretos. Un founder quería evaluar técnicamente una plataforma que estaba por comprar. Otro quería entender cómo convertir una propuesta de valor más tradicional en una con AI. Terminé armando mis servicios alrededor de esos problemas, y me trajo más founders a mi página.
"CTO Fraccional" es 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 sentirse identificado con esa página.
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 lo que puedo hacer después.
Por eso me gustan las nuevas posibilidades que la AI abre para cualquiera que quiera perseguirlas. Nos permite subir un nivel de abstracción, y expandir nuestro conocimiento horizontalmente entre disciplinas.
Y 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.
