¿Cuál es la cosa más impresionante que has hecho?

Durante la selección de personal de Naijm, Samuel y yo hicimos a los candidatos una pregunta un poco extraña: ¿cuál es la cosa más impresionante que hiciste de niño? ¿Y en el colegio? ¿Y en la universidad? ¿Y en el trabajo? Lo que nos sorprendió no fue tanto la calidad de las respuestas. Fue la cantidad de gente que no tenía realmente ninguna.

Más de 1.000 personas se presentaron a Naijm. Había 213 candidaturas serias y finalmente contratamos a doce personas. Había muchos buenos currículos, buenas escuelas, buenas empresas, gente que había hecho todo lo que normalmente se espera de ella. Pero cuando llegaba esa pregunta, a veces no pasaba gran cosa. Y de vez en cuando nos encontrábamos con alguien a quien Samuel y yo queríamos conocer de inmediato.

Uno ya construía cosas a los nueve años y a los catorce había vendido un producto que utilizaba IA para ayudar a personas ciegas. Años después contribuía a Chromium, construía sus propios sistemas de memoria para IA y reescribía una base de datos en Rust. Otro tenía veintidós años, había representado a Francia en la HackerOne World Cup y había dedicado una parte bastante significativa de su corta vida a entrar legalmente en los sistemas informáticos de otros. Otro había ganado un concurso nacional de matemáticas en Francia, estudiado matemáticas en Israel y pasado después cinco años en inteligencia militar antes de construir sistemas de IA. Otro había trabajado con varios grandes grupos farmacéuticos y cosméticos, automatizado procesos de análisis en LVMH Recherche, publicado investigación en IA y construido, por diversión, un sistema que permitía codificar un archivo en ADN sintético.

Cada vez, la reacción era más o menos la misma: queríamos saber más. No necesariamente contratar a la persona, porque en esa fase aún no sabíamos si encajaba en Naijm, sino conocerla y seguir conversando. Todavía no sé si esta pregunta predice algo. El equipo acaba de empezar, así que sería un poco pronto para explicarles que hemos descubierto una nueva ciencia de la selección de personal. Quizá dentro de seis meses algunas personas que nos fascinaron durante una hora de entrevista nos vuelvan completamente locos. Por ahora, solo sé que en cuanto aparecía una trayectoria realmente singular, despertaba mucha curiosidad en Samuel y en mí.

Doce personas que probablemente nunca deberían haber acabado juntas

Así se formó finalmente este primer equipo, y es bastante raro. Algunos tienen más de veinte años de experiencia, mientras otros apenas tienen veinte años de edad. Hay un hacker, ingenieros, gente que ha trabajado en la industria farmacéutica, el lujo o la inteligencia, personas que saben vender, dos hermanos que hacen películas juntos y Samuel Cardillo, que dirigía la tecnología de RTFKT antes de su adquisición por Nike y cuyo título oficial con nosotros es ahora CTO & Open Source Tsar. Asumo esta última elección con una serenidad razonable.

Hemos organizado a todo este pequeño grupo en cuatro crews: Navigators, Builders, Outriders y Firekeepers. Los Builders construyen, los Outriders entran directamente en las operaciones de nuestros clientes, los Navigators marcan el rumbo y asumen compromisos, y los Firekeepers cuidan, entre otras cosas, el relato y la señal en torno a lo que construimos. Dicho así, podría parecer que la empresa lleva mucho tiempo existiendo y que simplemente hemos documentado una organización perfectamente engrasada. En realidad, el equipo empieza mañana y ya tenemos más RFP que personas disponibles para responderlas.

Probablemente es ahí donde Naijm empieza a resultar interesante.

Hacer mucho con poco

Hemos construido la empresa alrededor de una hipótesis bastante agresiva: algunas operaciones que hoy cuestan 100 millones quizá puedan acabar costando 20 o 30. Evidentemente, no porque la gente vaya a trabajar cinco veces más deprisa, sino porque probablemente no construyes la misma operación cuando puedes utilizar software y agentes desde el principio que cuando los añades quince años después a una organización existente.

Y si de verdad creemos que un equipo pequeño puede conseguir lo que antes requería una organización mucho más pesada, hay una consecuencia bastante incómoda: deberíamos empezar por ser capaces de hacerlo en nuestra propia casa. Nuestro primer problema ya es exactamente ese. Tenemos demasiado trabajo para doce personas. La respuesta clásica sería bastante sencilla: seguir contratando hasta que la capacidad alcance a la demanda.

En Naijm, al menos queremos que antes llegue otra serie de preguntas. ¿Este trabajo tiene realmente que existir? ¿Podemos eliminar un paso, cambiar el proceso, programarlo, construir un agente, darle más capacidad a alguien que ya está aquí? Y a veces, después de todo eso, la mejor respuesta será evidentemente una persona, en cuyo caso contrataremos a una persona. El objetivo no es convertir el número de empleados en una puntuación de golf. Una empresa de siete personas no es moralmente superior a una de setecientas. Simplemente quiero ver hasta dónde podemos llegar antes de que cada nueva cantidad de trabajo produzca automáticamente una nueva descripción de puesto.

Contratar sin construir un ejército de reclutadores

La selección nos dio una primera muestra de este problema. Tratar seriamente más de 1.000 candidaturas con un equipo pequeño puede convertirse muy rápido en el trabajo de varias personas, así que construimos Al-Battani, la IA que acompaña nuestro proceso de selección. Lee las candidaturas, analiza las respuestas y produce una valoración. Cuando un expediente es ambiguo, puede reevaluarse varias veces, y los desacuerdos hacen que el candidato llegue a una persona.

Pero Al-Battani no rechaza a nadie. Cada rechazo sigue requiriendo que una persona tome la decisión. Me parece interesante esta distinción porque en las conversaciones sobre IA solemos mezclar dos cosas: delegar el trabajo y delegar la responsabilidad. Queremos delegar muchísimo de lo primero, y lo segundo nos cuesta bastante más. Una máquina puede leer más deprisa, comparar más cosas y volver a empezar veinte veces sin cansarse. Eso no significa necesariamente que debamos confiarle el momento en que alguien deja de ser candidato.

En cambio, permitimos a los candidatos utilizar IA durante las pruebas. De hecho, queríamos verlos utilizarla. No tiene demasiado sentido que alguien que va a trabajar diariamente con agentes nos muestre lo que sabe hacer después de quitárselos. Lo interesante es precisamente cómo los utiliza: qué delega, qué verifica, cómo formula el problema y, sobre todo, en qué momento entiende que la máquina acaba de tomar una dirección equivocada. Antes de empezar a confiar en las puntuaciones de Al-Battani, las primeras evaluaciones también fueron revisadas por personas. Sería una pena crear una máquina para evaluar el criterio de los demás sin comprobar primero el criterio de la propia máquina.

Cuando el software empieza a contener la empresa

Esta lógica fue contagiando progresivamente al resto de Naijm. Construimos nuestro propio sistema interno, donde viven la selección, las personas, las RFP, las compras, la wiki, la incorporación de empleados, la marca y una parte de las operaciones cotidianas. Incluso el organigrama existe en el código: los roles, los crews, los accesos y los permisos están vinculados entre sí, hasta el punto de que un cambio real en la organización puede terminar exigiendo un cambio en el sistema que la representa.

Hace unos años, construir tanto software interno para una empresa de este tamaño probablemente habría sido una idea bastante absurda. ¿Para qué pagar a un equipo durante meses para recrear, peor, cinco SaaS de 49 dólares al mes? El SaaS ganó precisamente porque ese cálculo era evidente: comprabas el mismo software que otras diez mil empresas y adaptabas ligeramente tu forma de trabajar para encajar en él.

Pero el cálculo deja de ser tan evidente cuando fabricar una pequeña herramienta perfectamente adaptada a tu forma de trabajar empieza a llevar unas horas o unos días, en lugar de varios meses. De repente, el software puede volver a ser extremadamente específico. No necesita ser lo bastante genérico para satisfacer a diez mil empresas. Puede contener tus reglas, tus accesos, tus manías y esos nombres de crews un poco ridículos. Y, sobre todo, puede absorber parte de esas pequeñas reglas de coordinación que normalmente terminan viviendo en la cabeza de unas pocas personas.

Todas las empresas conocen las frases que aparecen en ese momento: «pregúntale a X», «Y sabe dónde está», «vuelve el lunes», «ni se te ocurra tocar esa hoja de cálculo». Una parte bastante extraña del crecimiento de una empresa consiste en fabricar seres humanos que se vuelven progresivamente imprescindibles para saber cómo funciona la empresa. Quiero ver cuánto tiempo podemos evitarlo cuando muchas de esas reglas pueden estar contenidas directamente en los sistemas.

También se puede automatizar el bullshit

Evidentemente, toda esta historia tiene un reverso bastante divertido: cuando construir software útil se abarata, construir software inútil se abarata exactamente igual. Y nosotros somos objetivamente candidatos excelentes para sufrir ese problema. Tenemos nuestro propio sistema interno, una IA de selección bautizada en honor a un astrónomo árabe que murió hace más de mil años, cuatro crews llamados Navigators, Builders, Outriders y Firekeepers, y un CTO cuyo título incluye oficialmente la palabra Tsar. Se puede llegar a ser muy bueno jugando a las empresas en muy poco tiempo.

Ya he visto suficientes empresas con una cultura magnífica, procesos magníficos, una presentación magnífica y pocos clientes como para saber que el peligro no es teórico. La IA incluso puede hacer este tipo de bullshit mucho más fácil: hoy podemos construir muy deprisa un agente, un dashboard o una automatización alrededor de un problema que quizá nunca debería haber existido. Así que poder programar algo en dos horas no significa necesariamente que debamos dedicar esas dos horas a programarlo.

Al final, hay que cambiar un número

Por suerte, nuestro modelo de negocio nos deja pocos lugares donde escondernos. Cuando Naijm trabaja con una empresa, entramos en sus operaciones, examinamos los procesos, las personas y los sistemas y, sobre todo, establecemos con ella cuánto cuesta todo eso hoy. Después intentamos reducir ese número. Hay una remuneración de base, pero una parte importante de lo que ganamos depende del ahorro realmente conseguido respecto a esa referencia inicial.

Me gusta mucho esta característica del modelo porque nos impide ganar solo por parecer inteligentes. Podemos desplegar cincuenta agentes, rehacer una arquitectura entera, automatizar doce procesos y explicar durante dos horas por qué la empresa ahora es AI-native. Si la operación costaba 100 antes de que llegáramos y sigue costando 100 después, probablemente ha ocurrido algo menos interesante de lo que cuenta el PowerPoint. El cliente no paga por nuestra religión, paga por el número.

Eso hace interesante nuestra hipótesis de los 100 millones que se convierten en 20 o 30. Por ahora, es precisamente eso: una hipótesis. Todavía no nos hemos ganado el derecho a contarla como una verdad, y de hecho prefiero escribir esta newsletter ahora, cuando tantas cosas siguen sin resolverse. Dentro de uno o dos años, si funciona, será muy fácil reconstruir la historia al revés. Cada contratación parecerá evidente, cada agente dará la impresión de haber sido pensado desde el primer día, los errores se convertirán en aprendizajes necesarios y los accidentes en decisiones estratégicas especialmente sutiles. A los emprendedores se nos da bastante bien eso.

Mañana empieza de verdad el experimento

Hoy la situación es bastante menos elegante. Tenemos doce personas que empiezan mañana, más RFP que capacidad disponible, mucho software, unos cuantos agentes y varias convicciones, algunas probablemente equivocadas. Si los agentes no permiten que este equipo haga mucho más con poco, sencillamente no lo conseguiremos.

Hace unos meses teníamos tres clientes y ningún empleado. Mañana tendremos a los empleados y ya demasiado trabajo para ellos.

Ahora hay que ver lo que pueden hacer doce.