00:00:00 Introducción a las auditorías técnicas de startups
00:01:42 Cómo los VCs llevaron a Joannes a las auditorías técnicas
00:03:24 Auditorías técnicas como fuente de ingresos
00:05:08 Evaluando software en startups
00:06:36 La experiencia de Joannes en machine learning
00:08:50 Aspectos clave de una auditoría técnica
00:10:02 Compensaciones entre seguridad y corrección
00:11:46 Redacción efectiva de reportes para inversionistas
00:14:57 Evaluando startups más allá de las listas de verificación
00:17:04 Adaptando las auditorías al contexto del negocio
00:20:24 Entrevistando a CTOs y revisando código en vivo
00:24:12 Evaluando la familiaridad y el liderazgo de los desarrolladores
00:28:22 Juzgando la competencia de los desarrolladores
00:30:49 Señales de alerta en la calidad del código
00:33:47 Percepciones del historial de commits
00:37:03 Sostenibilidad de los costos de computación en la nube
00:42:14 LLMs interrumpiendo startups de NLP
00:46:29 Encontrando nichos lucrativos de software
00:50:32 Riesgos de la deuda técnica
00:55:34 Invertir en exceso en escalabilidad
00:59:59 La escritura clara señala una buena ingeniería
01:04:08 Por qué las auditorías técnicas son raras en las inversiones
01:07:12 Comentarios finales
Resumen
En un reciente episodio de LokadTV, Conor Doherty entrevistó a Joannes Vermorel, CEO de Lokad, sobre su experiencia de una década realizando auditorías técnicas de startups. Las “lightning tech audits” de Vermorel ofrecen a los venture capitalists evaluaciones expertas de stacks tecnológicos, diferenciándose de los métodos tradicionales al centrarse en evaluaciones dinámicas y específicas del contexto. Su proceso implica evaluaciones intensivas de un día, incluyendo entrevistas con CTOs y equipos de ingeniería para medir la calidad del código y la funcionalidad del equipo. Vermorel enfatiza la importancia de la pasión, la documentación clara y el uso juicioso de los recursos en el desarrollo tecnológico. Sus aportes revelan importantes omisiones en la industria y destacan las mejores prácticas tanto para inversionistas como para emprendedores tecnológicos.
Resumen Extendido
En un reciente episodio de LokadTV, Conor Doherty, Director de Comunicación en Lokad, se reunió con Joannes Vermorel, el CEO y Fundador de Lokad, para profundizar en una de las actividades menos conocidas pero de gran impacto de Joannes: realizar auditorías técnicas de startups. Durante la última década, Joannes ha llevado a cabo estas auditorías, proporcionando a los venture capitalists opiniones expertas sobre los stacks tecnológicos de posibles inversiones. Esta práctica, a la que Joannes se refiere como “lightning tech audits,” le ha brindado un punto de vista único sobre las mejores y peores prácticas dentro de la industria tecnológica.
El camino de Joannes hacia las auditorías técnicas comenzó en los primeros años de Lokad cuando estaba considerando incorporar venture capitalists. Aunque finalmente decidió no aceptar inversiones formales, sus interacciones con inversionistas lo llevaron a ofrecer su experiencia en la evaluación de los aspectos tecnológicos de otras startups. Este cambio le permitió transformar lo que podrían haber sido reuniones que consumen tiempo en valiosas oportunidades de venta, ofreciendo sus servicios a venture capitalists que necesitaban una opinión experta sobre los stacks tecnológicos de las empresas que estaban considerando para inversión.
El núcleo del proceso de auditoría de Joannes es una evaluación intensiva de un día que se desvía significativamente de los métodos tradicionales de auditoría. A diferencia del enfoque estándar, que depende en gran medida de listas de verificación, el método de Joannes es dinámico y hecho a la medida del contexto específico de cada startup. Comienza con una entrevista de 20 minutos con el CTO para entender el panorama tecnológico de la empresa y luego dedica el resto del día a realizar entrevistas individuales con el equipo de ingeniería. Este enfoque práctico le permite evaluar no solo la calidad del código, sino también la fluidez y coherencia del equipo al manejar su propia tecnología.
Joannes enfatiza que su objetivo no es convertirse en un experto en la tecnología de la empresa, sino evaluar si el equipo es funcional y si la trayectoria tecnológica es coherente. Busca patrones en la base de código, en el historial de commits y en la calidad de la documentación. Por ejemplo, puede evaluar rápidamente la calidad de la base de código observando la consistencia de los estilos de codificación y la claridad de los mensajes de commit. Además, evalúa si el equipo está haciendo un uso juicioso de sus recursos limitados, un factor crítico para las startups.
Uno de los hallazgos más sorprendentes que compartió Joannes es la frecuencia con la que las empresas tecnológicas pueden pasar por múltiples rondas de inversión sin que nadie haya examinado en serio su tecnología. Le resulta desconcertante que, incluso en rondas de inversión posteriores, el stack tecnológico a menudo permanezca sin ser cuestionado. Esta falta de análisis detallado puede conducir a importantes omisiones, como ocurrió famosamente con Theranos.
Joannes también habló de la importancia de la pasión y el cuidado en el desarrollo tecnológico. Cree que la falta de cuidado es fatal para las empresas tecnológicas. Cuando el CTO y el equipo de ingeniería sienten genuina pasión por su tecnología, eso se refleja en la calidad y coherencia de su trabajo. Por el contrario, cuando las empresas externalizan su desarrollo a freelancers o carecen de un compromiso profundo con su tecnología, los resultados suelen ser desastrosos.
En cuanto a las mejores prácticas, Joannes destacó la importancia de una redacción y documentación claras. Ya sean comentarios en el código o la articulación de las problemáticas en los tickets, la claridad y concisión son indicadores clave de un equipo que funciona bien. También valora el uso de tecnologías inusuales pero bien adecuadas, que pueden indicar un profundo entendimiento del panorama tecnológico y un compromiso para encontrar las mejores soluciones.
El enfoque de Joannes para las auditorías técnicas es un cambio refrescante respecto a la norma, centrándose en las realidades prácticas y las necesidades específicas de cada startup. Sus ideas ofrecen lecciones valiosas tanto para los inversionistas como para los emprendedores tecnológicos, enfatizando la importancia de la pasión, la claridad y un enfoque hecho a la medida en el desarrollo tecnológico. A medida que la industria tecnológica sigue evolucionando, el método de “lightning tech audits” de Joannes proporciona un marco sólido para evaluar el verdadero potencial de las innovaciones tecnológicas.
Transcripción Completa
Conor Doherty: Bienvenidos de nuevo a LokadTV. Hoy me acompaña en el estudio Joannes Vermorel, fundador y CEO de Lokad. Discutiremos una de sus actividades secundarias únicas: realizar auditorías técnicas de startups. Poco se da cuenta de que, durante aproximadamente una década, Joannes ha estado evaluando compañías de software, revisando desde el código y la infraestructura hasta el personal y el liderazgo en sí. Él y yo discutiremos algunas de las mejores prácticas, así como lo que ha aprendido en el camino. Ahora, como siempre, si te gusta lo que escuchas y aprecias lo que hacemos, suscríbete al canal de YouTube y síguenos en LinkedIn. Y con eso, te presento la conversación de hoy con Joannes Vermorel. Joannes, bienvenido de nuevo. Como mencioné en la introducción, estamos aquí para hablar no necesariamente de nuestro tema habitual, sino de algo que creo que sigue siendo de gran interés. Realizas muchas auditorías técnicas, ¿es correcto?
Joannes Vermorel: Sí, y ha sido así durante más de una década, probablemente casi 14 años.
Conor Doherty: ¿Y cómo surgió exactamente esto? Porque, nuevamente, cualquiera que haya estado viendo LokadTV—¿ya es el séptimo o tal vez el octavo año, quizá Max fuera de cámara puede confirmarlo?—está familiarizado contigo hablando de supply chain y toda la tecnología involucrada en eso. Pero probablemente es la primera vez que alguien escucha sobre esto, y sin embargo acabas de decir que lo llevas haciendo 10 años. Así que, en cuanto a actividades secundarias, ha sido algo sutil. ¿Cómo surgió exactamente?
Joannes Vermorel: En los primeros años de Lokad, estaba considerando aceptar inversiones, ya sabes, traer venture capitalists. Resultó que nunca incorporé inversionistas formales a la empresa, pero en los primeros años de Lokad hablé con bastantes de ellos. Después de un tiempo, ya sabes, lo que suele pasar es que envías un email o ellos te envían uno diciendo: “Oh, tomemos un café o algo así.” Requiere tiempo reunirse con inversionistas para discutir tu empresa y ver si estarían interesados en invertir y demás. Requiere tiempo, y en algún momento pensé, “Okay, estoy pasando todo este tiempo reuniéndome con esos potenciales inversionistas, y ese es tiempo que no estoy dedicando a construir, a vender.” Así que pensé, “¿Qué tal si les vendo algo?” O sea, simplemente tratar esas reuniones con venture capitalists como reuniones de venta. Resultó que mencioné a esas personas que, si estaban interesados—no es que fuera un cliente super destacado para ellos, ya que no estaba desesperadamente buscando efectivo—pero les decía que Lokad podría no ser la startup ideal para ellos porque no buscaba dinero a toda costa. Pero si estaban buscando a alguien que forjara una opinión experta sobre otra inversión, podría ser su hombre. Mi especialidad no era mirar otra startup y juzgar si podrían ganar dinero—eso está fuera de mi expertise, es muy difícil. Pero lo que sí estaba dentro de mi expertise era tener una opinión educada sobre su stack tecnológico. Resultó que cuando eres un venture capitalist e inviertes en empresas tecnológicas, una gran parte de la valoración de muchas de esas compañías es la tecnología que están desarrollando. ¿Es la tecnología verdaderamente valiosa? ¿Vale la pena la valoración pre-money que los fundadores piden? Y así, he aquí, comencé a hacer esas auditorías técnicas. He estado haciendo alrededor de una, a veces dos por mes durante, nuevamente, creo que han pasado 12 o 13 años, así que ha sido bastante tiempo. Y he auditado muchas empresas, y el formato de esas auditorías es muy breve. Por cierto, preguntabas cómo encuentro el tiempo para hacer eso. Bueno, siempre he mantenido esas auditorías como lightning tech audits; todo se hace en un día.
Conor Doherty: Definitivamente volveremos a eso porque hay implicaciones en el enfoque. Hablaremos de cómo tu método difiere de lo que la mayoría consideraría el status quo de lo que esencialmente equivale a un servicio de consultoría. Sin embargo, solo para enmarcar esto correctamente, ya que has utilizado el término “expert opinion” y “expertise,” para aquellos que no estén familiarizados con lo que te califica para este cargo, siéntete libre de detallar tus numerosos logros.
Joannes Vermorel: Siempre he sido un apasionado de las tecnologías de software. Comencé a programar en la escuela primaria, pasé la mayor parte de la secundaria y bachillerato mejorando en la programación con cosas más sofisticadas, y siempre he estado extremadamente interesado en todo lo relacionado con el software. Cuando empecé a hacer esas auditorías, aún no tenía 30 años, pero estaba cerca de ello, y ya contaba con casi una década de experiencia profesional en software, tanto con mis propios proyectos como con otros proyectos que realicé en la universidad y en otras empresas.
Conor Doherty: Ahora, también trabajaste en Estados Unidos por un tiempo en AT&T Labs. Fue una época en la que realmente eran pioneros en machine learning. Comenzaron a trabajar en machine learning en los años 90.
Joannes Vermorel: Sí, estaban involucrados en esas cuestiones de machine learning mucho antes de que la inteligencia artificial se volviera moderna y de moda. Había gente trabajando en eso, pero, de nuevo, esa era solo una parte de mi interés. Cuando audito empresas, con mucha frecuencia el machine learning es solo una pequeña parte de los problemas. Con frecuencia, ni siquiera es parte del problema. Esas empresas pueden ser de todo tipo. Hay compañías de software, pero pueden ser desde una empresa biotecnológica que utiliza el software de manera extensa, hasta juegos de azar en línea, una aplicación de productividad B2B, o software embebido que se integra en un electrodoméstico situado en una sala de operaciones quirúrgicas en un hospital. El software aparece en una gama extremadamente amplia de situaciones, y las tecnologías que emplean esas startups varían enormemente de una empresa a otra, incluso si el núcleo siempre es el software. Ahí es donde realmente reside mi expertise.
Conor Doherty: Cuando hablas de realizar auditorías técnicas, creo que la gente probablemente tiene alguna idea de lo que es. Pero, ¿qué implica exactamente? ¿En qué áreas te enfocas? ¿Estás evaluando solo el software? ¿Estás evaluando a las personas? ¿Qué implica exactamente?
Joannes Vermorel: El entregable, porque tenemos que comenzar con lo que se está entregando, es un memo que le devuelvo al inversionista. Un capitalista de riesgo está a punto de invertir en una startup. Normalmente tienen una carta de intención ya firmada. Están a punto de invertir desde 2 millones hasta 20 millones, a veces más, de dólares o euros en una empresa. Una gran parte de la valoración es por las tecnologías en las que invierten. Están invirtiendo en un equipo que supuestamente ya ha desarrollado algo. Yo no realizo esas auditorías para la etapa semilla; estamos hablando de Series A, a veces Series B. Así que hablamos de personas que normalmente a esta etapa ya han desarrollado algo, lo que justifica una valoración más alta. Ahora, la pregunta es, ¿vale lo que esas personas están pidiendo? El valor no es solo lo que tienen, sino también las dinámicas tecnológicas dentro de la empresa para que, si obtienen el dinero del inversionista, puedan cumplir con los objetivos de su hoja de ruta. La gente invierte no solo en lo que es la empresa, sino, lo más importante, en lo que la empresa será mañana. No puedo evaluar si sus proyecciones financieras serán correctas. Mi experiencia no radica en el futuro de, digamos, los mercados de apuestas. No lo sé. Eso es para que lo evalúen otras personas. Pero si me muestran una aplicación para apuestas, tenemos que verificar si será segura, porque si hablamos de apuestas, por ejemplo, tiene que ser extremadamente segura. Ese es el tipo de pregunta que puedo responder. Si se trata de un dispositivo que se va a usar durante un procedimiento quirúrgico, entonces la corrección es absolutamente vital. Literalmente, si el dispositivo falla, potencialmente puede matar a un paciente. Los desafíos son muy diferentes.
Conor Doherty: Solo para retomar, cuando das ese ejemplo, entendí lo de seguridad y eso, obviamente, con tu chaqueta, pero la idea del equipo quirúrgico, ¿cuál es tu aporte en términos de evaluar esa corrección? ¿Va a hacer de forma fiable lo que se supone que debe hacer?
Joannes Vermorel: No es como un problema de seguridad, porque esas cosas van a estar aisladas de la red. Se operarán en un entorno que ya es muy seguro desde una perspectiva de TI—sin conexión a la red, ese tipo de cosas. Pero la pregunta es, ¿cómo aseguras que no sufras fallos, bugs o algo que literalmente pueda comprometer que el dispositivo vaya a funcionar? Muchas máquinas hoy en día son automáticas. Si opera una bomba que inyecta algún tipo de fluido en el paciente, ¿cómo te aseguras de que no esté fallando, de que haga exactamente lo que quieres que haga? Así que, en resumen, la forma en que abordo el entregable es formando una opinión. Ese sería un memo que le devuelvo al inversionista acerca de si creo que, ya sabes, cuál es mi opinión general sobre el valor de esta empresa en sus propios términos. Y eso es realmente lo importante. Estoy tratando de formar una opinión sobre lo que vale la empresa según lo que intenta lograr. Si estás desarrollando un videojuego, la pregunta es, ¿estás desarrollando algo que es muy adictivo, muy atractivo, divertido, etc.? Esos son tus términos de compromiso. Si estás desarrollando una biotecnología donde tienes una nueva tecnología diagnóstica que supuestamente te permite diagnosticar una patología de manera más temprana y rápida que un método alternativo, ¿funciona? ¿Es real? ¿Tienes algunas estadísticas que sean sólidas? ¿Tienes todos los procesos que parecen indicar que tus resultados empíricos son exactamente como deberían ser? Si tenemos una aplicación de productividad, la pregunta es, para una app B2B, ¿cómo manejas el hecho de que tienes cientos, potencialmente miles, de características o microcaracterísticas? Eso es lo de los apps empresariales; esas cosas pueden ser como un laberinto de características porque tienes tantos casos que atender. ¿Cómo maneja la empresa toda esta complejidad? ¿Se están ahogando bajo su propia complejidad o la gestionan bien? ¿Está bien organizada? Dependiendo del tipo de startup que termine auditando, los términos de compromiso—cuál es la propuesta de valor, cuál es la esencia del valor—son muy diferentes. Mi entregable es forjar y reflejar una opinión que le devuelvo al inversionista sobre lo que más importa. Si veo algo durante esta auditoría que comprometa que ese valor central sea entregado, lo señalo.
Conor Doherty: Nuevamente, dijiste que lo has estado haciendo por unos 10 o 12 años. Asumiendo de una a dos por mes, hablas de al menos más de 100 realizadas. Entonces, ¿cuál sería la mayor parte? Porque mencionaste, bueno, que podría estar revisando una aplicación para apuestas, podría estar revisando equipamiento médico. Obviamente, estos verticales son muy, muy diferentes. Así que, ¿la mayor parte de tu trabajo habría sido en, o cuál es la vibra típica cuando auditas?
Joannes Vermorel: Se trata realmente de empresas de software. Son personas que están desarrollando software. A veces hay un elemento físico, ya sabes, puede ser que sean personas que desarrollan software para un dispositivo. A veces hay más o menos software de terceros para integrar. ¿Es una app que es independiente, o está integrada en muchas otras cosas? Hay muchísimos casos. Quiero decir, obviamente, probablemente dos tercios de lo que he hecho es B2B o equipamiento profesional, y un tercio sería B2C. Pero esa es solo una clasificación; de lo contrario, es extremadamente diversa.
Conor Doherty: Bueno, nos has dado una visión de alto nivel efectiva de los entregables y tu experiencia. Pero en términos de los pasos principales, ¿cómo formas una opinión y reflexionas sobre cuáles son los pasos involucrados para llegar a ese memo y a esa opinión?
Joannes Vermorel: Ahí es donde mi enfoque difiere extensamente de lo que la gente usualmente considera como un proceso de auditoría. Solo para resumir para la audiencia, un auditor, diría que el 99% de las personas que realizan auditorías de cualquier tipo, tienen listas de verificación. Tienen sus largas listas con varios cientos de preguntas, y van a la empresa y preguntan, “¿Hacen esto o aquello?” Sí, no, sí, no, etc. El auditor simplemente recorre la lista como un dron. Mi opinión es que este proceso es completamente absurdo para auditorías tecnológicas, especialmente para startups.
El problema es que esta lista, sea lo que sea, nunca desafiará a la startup en sus propios términos. Es completamente irrelevante cuestionar, digamos, a una empresa de gaming sobre si es súper segura. Si desarrollas un videojuego, la seguridad es una preocupación secundaria. En una startup, tus recursos son escasos. ¿Tiene sentido que la mayoría de los videojuegos inviertan en tener un oficial de seguridad e inviertan fuertemente en características de seguridad que compliquen la vida de los usuarios? Si se trata de videojuegos casuales, por ejemplo, no tiene ningún sentido. A nadie le importa que estés jugando Farmville.
En resumen, tener listas de verificación es una receta para ser una pérdida masiva de tiempo para los fundadores y una distracción enorme para los propios inversionistas. Pueden decir, “Oh, la startup cumple con cientos de ítems irrelevantes,” y luego tú dirías, “Oh, pero no cumplen con estos 100 ítems,” los cuales también son completamente irrelevantes para el éxito de la empresa. Mi opinión es que ellos tienen un caso de negocio; dicen que quieren ir en una cierta dirección en cuanto a negocio se refiere. Yo dejo que otras personas evalúen si hay dinero que ganar. Yo no evalúo eso. Quiero decir, sí tengo mi propia opinión sobre si parece plausible, pero no cuestiono el tamaño del mercado. Mi postura es que, está bien, asumamos que hay un mercado y que si ejecutas esto excelentemente, habrá gente a la que servir, y esa gente estará dispuesta a pagarte.
Ahora la pregunta es realmente, ¿cumplirás con lo prometido? Estás desarrollando una tecnología que se supone debe hacer algo. ¿Entregarás lo que realmente estás prometiendo?
Conor Doherty: Y estás en posición de proporcionar ese nivel de análisis. Puedes especular sobre la tecnología y…
Joannes Vermorel: En comparación con un auditor, si vuelvo a la lista de verificación, mi postura es que cuando comienzo el día, durante los primeros 20 minutos, normalmente entrevisto al CTO. La idea es que en esos 20 minutos necesito mentalmente estructurar una serie de preguntas para guiar la conversación hacia lo que más interesa. Después de los 20 minutos de presentación, generalmente realizada mediante una conversación casual, conduzco el resto del día a través de una serie de entrevistas en las que hay alguien frente a una computadora mostrándome su codebase. Realizo una serie de entrevistas uno a uno en las que ambos miramos la misma pantalla, y un empleado de la empresa actúa como mi guía a través de su codebase.
Conor Doherty: Entonces, eres Virgil.
Joannes Vermorel: Sí, me están guiando a través de su codebase. No pido una copia del codebase porque eso podría crear muchos problemas y hacerme responsable de la propiedad intelectual. La idea es que quiero echar un vistazo al codebase, y esa es la forma en que analizo la tecnología. Pero los codebases pueden ser extremadamente extensos. Incluso una pequeña empresa con cinco ingenieros de software trabajando durante un par de años puede tener fácilmente 100,000 líneas de código o más. Si tuviese que navegar este codebase por mi cuenta, el 90% de mi tiempo se desperdiciaría tratando de orientarme. Así que, tengo a un ingeniero sentado a mi lado, le hago preguntas y él me muestra el código. Revisamos el código juntos, obviamente una muestra del mismo; no podemos revisar todo el codebase.
Conor Doherty: Dadas las posibles implicaciones financieras, ¿por qué no revisas esto junto con el CTO?
Joannes Vermorel: Primero, el CTO no necesariamente conoce todas las partes del codebase. Si es un equipo de cinco personas, incluyendo un CTO, entonces probablemente el CTO sea competente en todo el codebase. Pero, de manera más general, también es muy interesante para mí tener a otras personas de la empresa sentadas a mi lado, porque de ese modo puedo ver qué tan fluidos son con el codebase. ¿Están perdidos en su propia tecnología? Cuando hago una pregunta básica como, “¿Cómo accedes a tu capa persistente?” o “¿Cómo accedes a los datos que has registrado?” si la gente no tiene ni idea, no es bueno. Si les pregunto, “¿Cuál fue lo último que hiciste?” y dicen, “He estado desarrollando esta función,” y se quedan perdidos al intentar mostrarme en lo que están trabajando actualmente, eso no es bueno.
Entrevistar al CTO es bueno, pero también necesito evaluar si el equipo está al nivel del CTO. Esto puede ir en ambos sentidos. A veces el CTO es muy bueno, pero el resto del equipo no lo es tanto. A veces sucede lo contrario. A veces el CTO es muy débil, pero el resto del equipo es en realidad bastante fuerte. Varía, y eso también formará parte de las opiniones que le devuelvo al inversionista como parte de este memo de entregas. También tengo una opinión sobre si los contribuyentes que actualmente forman parte de la empresa están a la altura del desafío para la siguiente fase. Si ocurre la inversión, a veces cuando una empresa comienza, su presupuesto es extremadamente limitado, y optan por personas que no son súper talentosas en términos de tecnología. Esto sucede con frecuencia cuando el fundador no es un fundador técnico. Cuando el fundador es alguien que tenía conocimiento interno, que sabe que hay un problema específico que debe abordarse, y esta persona ve una necesidad y willingness to pay. Esto ocurre muy a menudo en los mercados B2B. Pero esta persona no es técnica, por lo que contratan al primer ingeniero de software que encuentran. Puede que no tengan un gran presupuesto, así que su primera contratación podría ser alguien cuya principal ventaja sea ser muy barato.
De nuevo, está bien, está bien. Quiero decir, comienzas con nada. Tienes, digamos, €20,000, que pones en la empresa. Para ti, eso ya es una inversión considerable. Gracias a esos €20,000, logras tener algo así como medio millón en semilla. Eso es bueno. Puedes tener tu equipo de, digamos, dos ingenieros de software para desarrollar el producto. Luego quieres pasar a la siguiente etapa y ahora tener la primera ronda de, digamos, €3 millones. Bueno, en esta etapa, si hablamos de una inversión de varios millones, es una etapa en la que ahora tienes el dinero para contar con talento real en términos de ingeniería de software. Entonces la pregunta es, ¿los jugadores que actualmente tienes están a la altura del desafío para el siguiente nivel, la siguiente etapa de la empresa? Así que esa también, no es la única pregunta, sino que es también una de las preguntas que se está evaluando.
Conor Doherty: Solo para aclarar, como parte del memorando, el entregable, ¿potencialmente harías recomendaciones sobre quién debería quedarse y quién no?
Joannes Vermorel: Sí, sí. Nuevamente, es lo que sea que ayude o comprometa el valor tecnológico de la empresa, su trayectoria tecnológica. A veces tienes los jugadores equivocados. Quiero decir, contabas con los jugadores que necesitabas para ganar un campeonato súper local, pero si quieres jugar a nivel nacional o incluso aspirar al campeonato mundial, entonces quizá necesites jugadores diferentes. Traer más dinero cambia la dinámica. De repente, potencialmente puedes permitirte personas que tienen mucha más experiencia, son mucho más talentosas. Varía. A veces las personas son muy talentosas, pero por alguna razón, la dinámica en la empresa es súper mala. A veces puede llegar a tener dos CTOs por alguna razón. Eso sí ocurrió en algunas auditorías. Así que tienes dos líderes tecnológicos, y esas dos personas están siguiendo hojas de ruta diferentes. Entonces, mi mensaje es: elige uno. No puedes permanecer completamente esquizofrénico; necesitas elegir. Esa sería una decisión empresarial, porque son distintos mercados a los que intentas acceder. Pero, en última instancia, ese es el tipo de problema en el que un inversionista necesita saber si hay algo mal con la tecnología o si habrá algo mal en el futuro con la tecnología. Porque a veces aún no hay problema, pero agregar dinero es como echarle leña al fuego. Si tienes algo que está ligeramente disfuncional, si comienzas a verter un par de millones sobre ello, lo que era un pequeño problema puede ampliarse enormemente debido a la inversión misma. Así que eso también puede ser un problema. De nuevo, para mí no hay una lista de verificación, no hay reglas. Es lo que veo que tiene sentido en términos de problemas a solucionar o recomendaciones para el inversionista. Eso es parte de mi alcance. La idea es que lo mantenga como una misión de un día porque no tengo tiempo para hacer mucho más. Pero también porque los mismos fundadores están muy ocupados. Creo que parte del problema con las auditorías clásicas es que esas cosas son una completa pérdida de tiempo. Toman semanas, paralizan completamente a la empresa, y no sale nada bueno de ello.
Conor Doherty: Bueno, en ese punto, en realidad, ¿estás diciendo que no usas una lista de verificación, que tu objetivo es entrar y salir en menos de un día? Cuando dices un día, refiriéndote a un día laboral. Así que, en lugar de un proceso de varias semanas, que son múltiples semanas de días de 8 horas, hablas de tal vez 8 a 10 horas, excluyendo taxis y vuelos, sin usar una lista de verificación, y luego hacer recomendaciones muy trascendentales sobre lo que se debería hacer en la empresa, cosas que impactarán a otras personas. Tengo que preguntar, dadas todas esas limitaciones, ¿eres simplemente tan brillante o cómo exactamente haces esas determinaciones en un solo día sin lista de verificación?
Joannes Vermorel: Sí, quiero decir, primero, la base de código. Si estás algo acostumbrado a leer muchas bases de código, esas cosas se vuelven extremadamente obvias. En solo unos minutos de revisar la base de código, ves si el código está bien escrito o es una porquería. Normalmente ya tengo una opinión en 5 minutos de explorar esa base de código. Si realmente estás acostumbrado a leer muchos lenguajes de programación y has visto muchas bases de código, no necesitas horas para formarte una opinión sobre si se trata de una ingeniería impecable, bien organizada y con sentido, o si es simplemente un caos puro e inconsistente. Por ejemplo, si recorro una base de código y veo estilos de codificación radicalmente diferentes, digo: “Oh, vale, entonces tenemos diferentes colaboradores que no tienen ningún acuerdo compartido sobre cómo debería lucir el código.” Es realmente malo. ¿Miro el historial de commits? Eso me dice muchas cosas. Por ejemplo, si veo que en el historial de commits tienes un commit por una funcionalidad y luego dos docenas de commits para arreglar bugs causados por la introducción de esa funcionalidad, eso es súper malo. Eso significa que cada vez que alguien introduce algo, luego pasará mucho tiempo arreglando lo que acaba de romper. Así que, con solo echar un vistazo superficial a los últimos, tal vez, 200 commits, puedes ver si existe un patrón. Puedes identificar muchos patrones. A veces, por ejemplo, tienes el historial de mensajes de commit. Esta es la evolución para la audiencia. Los commits son la forma en que modificas incrementalmente la base de código. Realizas cambios, y normalmente usas Git hoy en día. Nosotros lo usamos para la web, y en Lokad, lo usamos como todos los demás para nuestra pila tecnológica. La pregunta es, por ejemplo, cuando ves cambios aplicados a la base de código, ¿tienen sentido esos cambios? Por ejemplo, si tienes commits donde el título del commit es “más cosas”, literalmente, ¿qué es esta porquería? No, no tienes cambios que aporten mejoras sustanciales. Luego, por ejemplo, si tienes un bug que se está arreglando, ¿se está haciendo algo extra junto con la corrección para asegurarse de que el bug no se reintroduzca la próxima vez que modifiques la base de código? Hay muchas formas de garantizar que el bug no vuelva a aparecer. ¿Te ocupas de ello? Cuando observas las contribuciones, los commits, ¿la gente hace revisiones de código? ¿Discuten cómo debería diseñarse la ingeniería? De nuevo, la base de código cuenta una gran historia tanto sobre qué es la tecnología como sobre su historia. Puedes ver la trayectoria, cómo se ha desarrollado. Luego puedes profundizar en las partes centrales. Por ejemplo, si eres una startup de IA o de machine learning, se supone que tu valor principal es alguna receta numérica inteligente que hace algo muy difícil o lo que sea. ¿Cómo lo estás logrando? ¿Es solo un truco, o tienes una profunda experiencia? ¿Cuánto moat tienes? ¿Cuentas con una verdadera barrera (moat) en la que replicar lo que acabas de hacer será difícil, o es solo un truco ilusorio en el que simplemente estás usando algún tipo de biblioteca open-source y ¡bam!, en realidad nada es propio de tu producción? Simplemente has reciclado algo que está en la comunidad. De nuevo, esa es una pregunta muy crítica para el inversionista porque, si la gente dice, “Oh, hemos desarrollado una tecnología única de machine learning”, y lo que haces es esencialmente reutilizar una pieza de código open-source, cualquiera puede hacerlo. Así que, sí, es genial, sí, funciona, pero ¿debería el inversionista valorar tu empresa altamente solo porque tienes algo que funciona? Bueno, no realmente, porque si es open-source, significa que prácticamente cualquiera también puede hacerlo. Así que no hay moat. De nuevo, las cosas que observo realmente dependen de las especificaciones de la empresa.
Conor Doherty: También puedes, incluso tomando el ejemplo y combinándolo con un poco de anécdota, si tomas el ejemplo de revisar el historial de commits en Git o Bitbucket—nosotros usamos Bitbucket—puedes extrapolar bastante. Por ejemplo, incluso para nosotros en el equipo de marketing, cada vez que subimos algo al sitio web, insistes en un historial de commits muy limpio y ordenado. Puedes ver exactamente lo que sucedió, quién lo aprobó.
Joannes Vermorel: Exactamente. Y también, a veces, es simplemente la forma en que las personas interactúan conmigo. Estoy hablando con alguien, le hago una pregunta al azar, ¿es esta persona extremadamente rápida en llevarme justo al lugar correcto del código? Como, “Oh, hay esta funcionalidad que es bastante interesante, ¿puedes mostrarme el código que es relevante para ello?” Y luego el tipo dice, “Oh, sí, ningún problema,” ¡bam!, directamente al punto, justo en la implementación. Eso es muy bueno. Ese dominio completo de la base de código, de cómo se están haciendo las cosas, es muy, muy bueno. Así que, a veces, solo la facilidad que demuestran las personas al navegar por la base de código me dice mucho. Además, por ejemplo, cuando introducen funcionalidades, ¿tienen tickets bien redactados para justificarlas? ¿Los ingenieros de software actúan de manera desorganizada y hacen cosas arbitrariamente con el código, o cuentan con algo bien organizado donde, “Vale, quiero hacer eso, aquí está mi ticket que describe de manera clara por qué quiero hacerlo,” y luego se discuten las diferentes formas de abordarlo, etcétera? Depende, pero esa es típicamente la importancia de los tickets. Esto sería muy crítico para aplicaciones B2B, aplicaciones de productividad, ya que tienes una lista interminable de funcionalidades que son todas súper específicas del dominio. Si estás desarrollando una aplicación empresarial, realmente no deberías perderte en la cantidad infinita de funcionalidades que podrías agregar a tu aplicación. Eso sería muy importante para diferentes tipos de empresas. Ese sería un proceso completamente diferente. Pero lo que estoy diciendo es que, en términos de cómo puedo formarme una opinión en tan solo unas pocas horas, si simplemente te sientas junto a alguien que interactúa con la base de código, puedes observar realmente mucho. Si solo prestas atención a los patrones, a lo que la gente está haciendo, y sí, es reconocimiento de patrones. Hay un número finito de cosas en las que las personas pueden ser buenas o malas dado cierta vocación.
Hay un número finito de cosas en las que las personas pueden ser buenas o malas dado cierta vocación.
Conor Doherty: Sí, y también verificas la consistencia, ¿sabes? ¿La gente siquiera cuenta la misma historia en términos de tecnología? Por ejemplo, pregunto, “¿Qué crees que está haciendo este componente?” Y si recibo de varias personas historias completamente diferentes, digo, “Vale, está claro que en este equipo no resulta evidente que la gente realmente entienda lo que está pasando.”
Joannes Vermorel: No necesito la verdad para reconocer que las cosas son inconsistentes. De nuevo, mi objetivo no es convertirme en un experto en lo que están haciendo. Mi objetivo es simplemente evaluar si el equipo es funcional, si la trayectoria en el desarrollo de la tecnología es sensata. A veces, también se trata de comprobar, por ejemplo, que los recursos en términos de computación en la nube están bajo control. A veces encuentras empresas que están gestionando mal sus recursos en computación en la nube. La nube es fantástica, paga conforme a lo que usas, lo que significa que el cielo es el límite. Puedes desplegar toneladas de máquinas virtuales, toneladas de almacenamiento, toneladas de todo. Y a veces, ya sabes, algunas empresas se entusiasman demasiado con ello y terminan gastando mucho más de lo que deberían en recursos de computación en la nube.
Conor Doherty: Eso, nuevamente, depende de lo que estén haciendo. ¿Cuánto deberías pagar por los recursos de computación en la nube? Bueno, realmente depende de lo que estés tratando de lograr. Así que no hay una regla clara, pero parte de la experiencia es evaluar cuál es la carga de trabajo que intentas realizar en la nube y si tiene sentido que estés pagando tanto. ¿Es un logro, bien hecho, tu software es altamente performante, o es súper malo y simplemente estás quemando dinero? Probablemente, darte toneladas de dinero extra para quemar no sea lo correcto. Deberías, probablemente, solucionar esos problemas antes de que te concedan algunos millones extra.
Joannes Vermorel: Si te falta dinero, no puedes disciplinarte para no quemar dinero a través de gastos imprudentes en recursos computacionales. Las probabilidades de que te vuelvas sabio una vez que tengas mucho más dinero son muy escasas.
Conor Doherty: Siguiendo esa línea, de hecho tenemos otro video sobre el tema de los recursos computacionales, así que revisa la playlist para eso. Pero en el tema del dinero, cuando hablas de finanzas, sé que cuando hablamos de supply chain, hablas del impacto financiero en el resultado final de la elección que vas a hacer. ¿Adoptas el mismo enfoque al evaluar una empresa tecnológica? ¿Observas cuál es la orquestación financieramente más beneficiosa de la empresa tecnológica o simplemente cuál es la mejor tecnología sin importar el precio?
Joannes Vermorel: No, no, no. Cada startup tiene recursos limitados. La idea, y ese es el problema de nuevo con las listas de verificación, es que estas tienen una perspectiva absoluta. Dicen que necesitas hacer esto, esto, esto y esto. Mi perspectiva es siempre completamente relativa a la madurez de la empresa.
Conor Doherty: Sí, exactamente, en sus propios términos.
Joannes Vermorel: No quieres, por ejemplo, que sería pura locura que una empresa pequeña busque una certificación ISO. Es un completo desperdicio de recursos, a menos que se trate de un mercado hiperregulado en el que no puedas sobrevivir sin dicha certificación. Lo que estoy evaluando es qué tan bueno eres aprovechando tus recursos limitados para obtener el máximo rendimiento por tu inversión. Simplemente asumo que tu dirección es buena, que, en última instancia, si tienes éxito, vas a ganar dinero. Pero aún así, si doy por sentado tus lineamientos empresariales, digo: “Bien, admitamos que, si esto se implementa, serás competitivo en este mercado y habrá dinero por ganar.” Lo asumo. Ahora, cada dólar o euro que se gasta para convertirse en el jugador número uno en este mercado, ¿se gasta sabiamente?
Conor Doherty: Absolutamente. Eso puede significar, ¿tienes el talento adecuado? A veces se gasta muy poco. Ocurre que, en algunas ocasiones, la empresa logra cierto grado de éxito y no se desprende de personas que fueron contratadas originalmente simplemente porque eran súper baratas. Eso también sucede con bastante frecuencia en las startups tecnológicas.
Joannes Vermorel: Especialmente cuando el fundador no es un fundador tecnológico, sino un fundador de ventas, y luego tienes al CTO que fue originalmente el primer ingeniero de software contratado por la empresa. Esto ocurre con frecuencia, y esa persona no está al nivel. De nuevo, las excepciones varían; los resultados pueden variar.
Conor Doherty: Exactamente. Mi pregunta es, ¿ha habido situaciones en las que has ido a evaluar una empresa, estás allí para evaluar todas las cosas de las que has hablado: el código, la forma en que trabaja el equipo, si en teoría podrían lograr el objetivo utilizando los recursos que tienen, pero resulta que su meta final era simplemente un disparate? Por ejemplo, es 2008 y esta empresa está decidida a volver a sacar la cinta VHS, como si fuera algo absolutamente loco que consideras un enorme desperdicio de dinero, tiempo y recursos.
Joannes Vermorel: Oh sí, eso pasa. Siéntete libre de mencionarlo, pero no nombres a nadie.
Conor Doherty: No, la cuestión es que algunas tecnologías de software evolucionan bastante rápido. Por ejemplo, durante los últimos dos años, he auditado bastantes empresas que trabajaban con NLP. Estas empresas se iniciaron en 2018 o 2019, y se subieron a la ola de la IA desarrollando tecnologías de NLP, procesamiento de lenguaje natural, pero pre-LLM, pre-large language models. Existía una literatura enorme de modelos de NLP y machine learning, deep learning, que no eran LLMs. Los LLMs han sido un evento de extinción para todas esas tecnologías de NLP.
Joannes Vermorel: Sí, había muchas empresas en las que mi conclusión era: esta empresa había desarrollado 20 modelos de NLP bastante sofisticados, pero todos están completamente obsoletos. Los LLM están superando uniformemente todo eso. Puedes simplemente desechar todo el tech stack y reiniciar desde cero con un LLM como protagonista, y serás mejor. No hay nada que rescatar. Ocurre con bastante frecuencia, tal vez una de cada 10, una de cada 20, en las que la tecnología está simplemente obsoleta por alguna razón. A veces, la gente no ha visto exactamente cuál será la sustitución, pero sí, cuando veo que esto simplemente va a ser, estás resolviendo un problema que ya está resuelto.
Conor Doherty: Generalmente, lo que ocurre es que no es absurdo en el sentido de que esas personas sean idiotas. Existe un problema por resolver, y han desarrollado algo que es agradable, pero ya se ha encontrado algo mucho mejor y, posiblemente, gratis. Esta cosa aún no es popular, todavía no es muy conocida. Creo que LLM es realmente el caso extremo en el que esas empresas estaban algo desesperadas porque sabían que venían los LLM y que eran un evento de extinción. Pero eres el fundador de una empresa, ya has invertido el dinero que recaudaste en seed rounds para ello, y ahora te enfrentas a la perspectiva de que tu tecnología es, en cierto modo, sin valor. Intentas, tal vez, conseguir una inversión que te permita rediseñar la tecnología. Difícil.
Joannes Vermorel: Mi opinión en este tipo de situación no es decirles a los inversores, “No inviertan.” Mi mensaje es que el tech stack que poseen simplemente no vale nada. Si las personas son buenas, aún podría haber un caso para invertir en ellas, pero a una valoración mucho menor, porque lo que tienen es, este activo tecnológico está completamente desactualizado. Ya no es un activo, es un pasivo.
El equipo es funcional, y la trayectoria en cuanto al desarrollo de la tecnología es una locura. A veces, también se trata de verificar, por ejemplo, que los recursos en términos de computación en la nube estén bajo control. A veces, tienes empresas que están gestionando mal sus recursos en la nube. La nube es fantástica; el pay as you go significa que el cielo es el límite. Puedes poner en marcha toneladas de máquinas virtuales, toneladas de almacenamiento, toneladas de todo. A veces, las empresas se vuelven un poco locas con eso y terminan con una trayectoria en la que gastan muchísimo más en recursos de computación en la nube de lo que deberían. Depende de lo que estén haciendo. ¿Cuánto deberías pagar por los recursos de computación en la nube? Bueno, realmente depende de lo que intentas lograr. No hay una regla clara, pero parte de la experiencia es evaluar cuál es la carga de trabajo que intentas realizar en la nube y si tiene sentido que estés pagando tanto. ¿Es un logro bien realizado, tu software es altamente eficiente, o es súper malo y simplemente estás quemando dinero? Probablemente darte toneladas de dinero extra para gastar simplemente no es la opción correcta. Probablemente deberías arreglar esos problemas antes de recibir unos cuantos millones extra. Si te falta dinero, no puedes disciplinarte para no quemar dinero a través de gastos imprudentes en recursos computacionales. Las posibilidades de que te vuelvas sabio una vez que tengas mucho más dinero son muy remotas.
Conor Doherty: Se me ocurre, y en esa nota, que de hecho tenemos otro video sobre el tema de los recursos computacionales, así que revisa la lista de reproducción para eso. Pero en lo que respecta al dinero, cuando hablas de finanzas, sé que cuando hablamos de supply chain, se habla del impacto financiero neto de la elección que vayas a hacer. ¿Adoptas el mismo enfoque al evaluar una empresa tecnológica? ¿Miras cuál es la orquestación financieramente más beneficiosa, o cuál es simplemente la mejor tecnología sin importar el precio?
Joannes Vermorel: No, no, no. Cada startup tiene recursos limitados. El problema con las listas de verificación es que tienen una perspectiva absoluta, diciendo que necesitas hacer esto, esto y esto. Mi perspectiva siempre es completamente relativa a la madurez de la empresa.
Conor Doherty: Sí, exactamente, en sus propios términos.
Joannes Vermorel: No quieres, por ejemplo, que sería pura locura que una pequeña empresa intentara obtener una certificación ISO. Es un completo desperdicio de recursos, a menos que se trate de un mercado hiperregulado donde no puedas sobrevivir sin esa certificación. Lo que estoy evaluando es qué tan buena eres aprovechando tus recursos limitados para obtener el máximo rendimiento por tu inversión. Simplemente asumo que tu dirección es buena, que en última instancia, si tienes éxito, vas a ganar dinero. Pero aun así, si doy por sentadas tus direcciones empresariales, digo: está bien, admitamos que si esto se logra, entonces serás competitivo en este mercado y habrá dinero que ganar. Lo asumo. Ahora bien, cada dólar o euro que se gasta para convertirse en el jugador número uno en este mercado, ¿se gasta de manera inteligente? Absolutamente. Eso puede ser, ¿tienes el talento adecuado? A veces, se gasta muy poco. Sucede que en ocasiones la empresa alcanza un cierto grado de éxito, y no dejan ir a personas que inicialmente fueron contratadas solo porque eran súper baratas. Eso también ocurre con bastante frecuencia en las startups tecnológicas. Especialmente cuando el fundador no es un fundador tecnológico, sino uno de ventas, y luego tienes al CTO que fue originalmente el primer ingeniero de software contratado por la empresa. Esto sucede con frecuencia, y esta persona no está al nivel. Nuevamente, varían las excepciones, tu experiencia puede variar.
Conor Doherty: Exactamente. Mi pregunta es, ¿ha habido situaciones donde entras a evaluar una empresa y su objetivo final era simplemente una tontería? Por ejemplo, es 2008, y esta empresa está decidida a traer de vuelta la cinta VHS. Algo completamente insano, en lo que tienes una opinión fuerte de que es un desperdicio masivo de dinero, tiempo y recursos.
Joannes Vermorel: Oh, sí, eso sucede.
Conor Doherty: Siéntete libre de compartir, pero no menciones nombres.
Joannes Vermorel: Algunas tecnologías de software evolucionan bastante rápido. Por ejemplo, durante los últimos dos años, he auditado bastantes empresas dedicadas a NLP. Estas empresas se iniciaron en 2018 o 2019, y entraron en esta ola de IA desarrollando tecnologías de NLP (Procesamiento de Lenguaje Natural), pero pre-LLM (Large Language Models). Existía una enorme literatura de modelos de NLP y de machine learning, deep learning, pero no de LLMs. Los LLMs han sido un evento de extinción para todas esas tecnologías de NLP. Para esas empresas, mi conclusión fue que habían desarrollado 20 modelos de NLP bastante sofisticados, pero todos están completamente obsoletos. Los LLMs están superando uniformemente todo eso. Puedes simplemente desechar el tech stack y reiniciar desde cero con un LLM como protagonista. No hay nada que rescatar. Ocurre con bastante frecuencia, tal vez una de cada 10 o una de cada 20, donde la tecnología está simplemente obsoleta por alguna razón. A veces, la gente no ha visto exactamente cuál será la sustitución. Cuando veo que esto simplemente va a ser, estás resolviendo un problema que ya está resuelto. Generalmente, no es absurdo en el sentido de que esas personas sean idiotas. Hay un problema por resolver, y han desarrollado algo bueno, pero ya se ha encontrado algo mucho mejor y, posiblemente, gratis. Esta cosa aún no es popular, todavía no es súper conocida. Los LLMs son un caso extremo en el que las empresas estaban algo desesperadas porque sabían lo que venía, y era un evento de extinción. Siendo el fundador de una empresa, ya has invertido el dinero que recaudaste en seed rounds para ello, y ahora te enfrentas a la perspectiva de que tu tecnología es, en cierto modo, sin valor. Intentas, tal vez, conseguir una inversión que te permita rediseñar la tecnología. Difícil. Mi postura no es decirle a los inversores que no inviertan. Mi mensaje es que el tech stack que tienen simplemente no vale nada. Si las personas son buenas, aún podría haber un caso para invertir en ellas, pero a una valoración mucho menor, porque lo que tienen ya no es un activo, es un pasivo.
Conor Doherty: En el otro extremo de ese espectro, ¿alguna vez has entrado a una empresa y te has ido pensando, acabo de conocer al próximo Elon Musk? Como, ese tipo es un genio, están sobre un diamante.
Joannes Vermorel: En esa escala, no. Pero sí, a veces me sentía un poco celoso en comparación con mi propia empresa. Sobre todo cuando las personas tienen nichos tan hermosos. Hay tantos nichos hermosos. Los casos que más me generan celos son problemas hermosos que son súper nicho. Nadie sabe siquiera que existe este problema. Resulta que hay decenas de millones, posiblemente hasta mil millones en juego. Este es un mercado de nicho, y algunas personas traen una solución para este nicho, y es hermosa. Es muy simple, directa y al grano. En lugar de ir a por un mercado hipercompetitivo, por ejemplo, Lokad haciendo optimización de supply chain, tenemos más de mil competidores en todo el mundo. Es un mercado muy saturado. Tenemos algunos competidores que son empresas multimillonarias. El panorama competitivo es duro. A veces me encuentro con empresas donde literalmente no tienen competidores. Son los únicos. Sus clientes están felices, tienen una solución que está realmente hecha a la medida para un problema de nicho que nunca había escuchado antes.
Conor Doherty: ¿Ejemplos ahí o sería revelar demasiado?
Joannes Vermorel: No, eso sería, lamentablemente, demasiado revelador. Intento, pero la conclusión es: piensa en, digamos, cualquier cosa que sea súper especializada.
Piensa en el mantenimiento especializado de una plataforma petrolera en alta mar. Hay toneladas de cosas que deben hacerse, y algunas operaciones especiales necesitan software como apoyo. Hay empresas que hacen eso. Piensa en cada nicho que probablemente necesite soluciones muy dedicadas.
Tienes muchas situaciones en las que puedes imaginar cuánta equipación tecnológica utiliza un cirujano en una sala de operaciones. Toneladas de equipamiento, incluso si quieres medir algo. Por ejemplo, en este edificio, tenían un control para detectar si había amianto. Había un equipo con software para detectar amianto en este edificio. En algún lugar hay una empresa que hace eso. Estos pueden ser nichos muy específicos que pueden parecer pequeños, pero cuando miras el mercado global, no lo son tanto.
Estos nichos súper pequeños podrían valer unos pocos cientos de millones de dólares a nivel mundial, y una empresa tiene la oportunidad de tomar el 50% de la cuota de mercado porque no hay competidores. La alternativa es que la gente use métodos tradicionales de papel y lápiz.
Conor Doherty: A lo largo de esos 10 años y habiendo visto una gran variedad de ejemplos diferentes, ¿hay algunas mejores prácticas y peores prácticas generales que hayas notado en términos de software o startups? Empecemos con las cosas que se deben evitar y terminemos con una nota positiva. Entonces, ¿cuáles son las cosas que se deben evitar absolutamente?
Joannes Vermorel: Si no te importa tu tecnología, te va a salir el tiro por la culata. La falta de cuidado es mortal. Siempre que veo empresas en las que a la gente no le importa la tecnología, generalmente la tecnología es una completa porquería.
Conor Doherty: Define a qué te refieres con “no importa.” ¿Es que no están interesados en aprender sobre ella, o en algún momento lo estuvieron y ahora no, o es una falta de habilidad? ¿A qué te refieres con eso?
Joannes Vermorel: La mejor manera de describirlo es: cuando el CTO se ducha, ¿piensa en su tecnología o en el golf? Las personas que realmente se preocupan tienen una especie de intensidad. No se detiene a la hora de oficina; va más allá de eso. Son extremadamente curiosos, entusiastas y apasionados. Realmente quieren hacer lo correcto. Existe ese elemento de ligera locura en el que no se trata solo de hacer lo correcto para el cliente, sino también de hacer lo correcto para la propia tecnología.
¿Estás diseñando algo que sea realmente hermoso? Hubo una anécdota sobre Steve Jobs. Quería que el iPhone se viera bien incluso por dentro. Cuando lo desmontas, los componentes dentro del iPhone serían elegantes por sí mismos, con la elección correcta de colores y demás. Este grado de cuidado refleja que te importa profundamente, no solo en cómo se ve en la superficie, sino también en las partes tecnológicas que ningún cliente llegará a ver.
Cuando a la gente no le importa, realmente es malo. Lo peor es probablemente cuando las empresas tecnológicas subcontratan el desarrollo de sus tecnologías a colaboradores freelance. No importa lo buenos o malos que puedan ser esos freelancers; el resultado neto es que la tecnología suele ser un completo desastre.
Conor Doherty: Creo que la mayoría estaría de acuerdo en que la pasión inherente y el impulso de hacer algo bien es una cualidad fantástica. Dicho esto, si sólo tienes 20 minutos con el CTO, ¿cómo evalúas esos intangibles sin una lista de verificación?
Joannes Vermorel: Alguien con intensidad me dirá, “Elegimos esta tecnología por esta razón.” Ellos conocen el porqué. No es simplemente, “Necesitaba una interfaz web, así que elegí esta.” Tienen opiniones sobre sus elecciones tecnológicas. Las personas con pasión tienen tantas opiniones; se les derraman. No pueden evitarlo. Cada vez que toco una parte de la tecnología, dicen, “Lo hacemos de esta manera debido a estas razones.”
Conor Doherty: Es la pasión lo que les interesa.
Joannes Vermorel: Sí, y puedes ver la intensidad de su pensamiento. No se trata simplemente de una pieza de tecnología que hicieron porque había requisitos. Las personas que producen código por kilómetro tienen un enfoque muy pedestre, donde los requisitos provienen del equipo de ventas, y simplemente los implementan. Esa es una receta para un tech stack que es una completa porquería.
Conor Doherty: Por ejemplo, si hubieras auditado a Steve Jobs en el pasado y te hubiera dicho, “Mira el interior de este teléfono, lo he hecho hermoso,” tu informe diría que es apasionado, pero eso es una locura en la que gastar dinero.
Joannes Vermorel: No, no. La cuestión es, ¿da la impresión de que se están distrayendo, o simplemente añaden ese pulido extra? Esas cosas pueden no ser muy costosas. Es simplemente la intensidad. Haces un poco más, unos pocos por ciento, para que todo quede realmente ajustado y bien. Eso no es locura. Las personas que se exceden típicamente sufren el efecto del segundo sistema. Es cuando un equipo de ingenieros, en su segundo intento, invierte de más en cosas que no necesitan porque la primera vez falló debido a una tecnología pésima.
El caso más frecuente es cuando las personas sobreinvierten en escalabilidad que no necesitarán en el futuro cercano. Dicen, “Mira nuestra hermosa arquitectura; puede manejar 10 million usuarios.” ¿Cuántos usuarios tienes a este punto? “Oh, 200.” Hay una gran desconexión entre lo que se necesita y la sobreingeniería.
También, están las personas que son pacientes con las cosas equivocadas. ¿Tienes una paciencia por cierta elegancia y belleza de la tecnología por sí misma, o estás siguiendo algún tipo de dogma? En las industrias de software, hay todo tipo de dogmas flotando. Tenemos que hacerlo como Scrum, o tenemos que hacer desarrollo orientado al dominio, o desarrollo basado en tests, o microservicios. Existen muchas posturas de tipo gurú en la industria del software, y hay personas que son fanáticas de esto. Cuando hablo de intensidad, me refiero a personas que aman lo que están creando pero que no son fanáticas de una ideología específica. Los fanáticos hacen cosas que no coinciden en absoluto ni siquiera con sus propios requerimientos prácticos. Dicen, “Oh, pero tenemos que hacerlo de esa manera porque es diseño basado en tests.” El hecho de que sea diseño basado en tests no es una justificación para hacerlo de esa manera. ¿Tiene realmente sentido hacerlo de esa manera con respecto a los problemas que tengas?
Conor Doherty: Y en cuanto a las mejores prácticas, no digas simplemente lo opuesto a lo que acabas de decir. ¿Hay algo que, en el momento, al verlo, te haga pensar, “Oh, eso es una buena señal”?
Joannes Vermorel: Escritura clara. Lo dijiste antes. Escritura clara. Cada pieza necesita ser al grano, nítida y concisa. ¿Tienes páginas de comentarios en el código que sean simplemente burocráticos, como, “Oh, necesitamos comentar esto”? ¿Existe una plantilla, y tienes una página de comentarios que nadie va a leer? ¿O tienes comentarios súper concisos que resultan muy interesantes? Solo con leer un comentario se ilumina todo el archivo de código. Cuando miro los tickets, ¿está redactada la declaración del problema de forma muy clara, o es un caos incomprensible? Cuando tienes un desafío técnico, ¿existe una discusión muy articulada del problema y las posibilidades, o tienes una diapositiva de mala calidad con viñetas absurdas que no dicen nada? La calidad de la escritura es uno de los indicadores. Otro es cuando las personas utilizan tecnologías inusuales que, aún así, resultan ser excelentes elecciones. Si utilizan una pieza tecnológica inusual, muy frecuentemente es simplemente por ignorancia. No sabían que existía una solución mucho más convencional que sería mucho mejor. Usualmente, es algo negativo, pero cuando resulta que una pieza tecnológica relativamente rara es sorprendentemente adecuada para lo que están haciendo, eso es muy bueno. Significa que han explorado el panorama tecnológico, especialmente el panorama tecnológico de código abierto, de manera muy extensa. Eso es muy agradable. Hoy en día, a nadie le sorprendería si la gente dice, “Oh, estamos usando Python, PostgreSQL, Tailwind for CSS, React.” Esos son componentes que todo ingeniero de software medianamente competente conoce. Pero si conocen algo súper específico que realmente se adapta a su problema, eso también es muy interesante.
Conor Doherty: Genial. Bueno, llevamos aproximadamente una hora. Soy consciente del tiempo, así que para concluir, ¿hay algún pensamiento final que te gustaría compartir con todos?
Joannes Vermorel: Sí. Creo que lo que más me sorprende en esta década de auditorías es la frecuencia con la que las empresas tecnológicas pueden literalmente pasar años y, a veces, rondas sucesivas de inversión sin que nadie revise la tecnología. Uno pensaría que Theranos, ese gran fraude, era una excepción. Tal inversión masiva, y nadie realizó la debida diligencia de la tecnología. Pero lo curioso es que es la norma. Para mí, lo que resulta muy intrigante es lo raras que son estas auditorías tecnológicas. Cuando hablo con esos fundadores de startups, usualmente me dicen, “No teníamos idea de que harías ese tipo de preguntas.” Piensan que vendré con esta lista de verificación insana y estúpida. Solo imagina Theranos; la gente habría engañado fácilmente a la lista de verificación. Había muchas listas de verificación, como, “¿Cumples con esto y aquello?” Sí, sí, sí, sí. Pero la pregunta central, que era, “¿Es real tu tecnología de análisis de sangre?” Nadie hizo esas preguntas. Eran súper básicas.
Conor Doherty: Esto regresa al punto que mencionaste antes sobre skin in the game. Si los capitalistas de riesgo van a invertir millones en tu empresa, tienen skin in the game.
Joannes Vermorel: Lo que encuentro muy sorprendente es que, generalmente, incluso si entro en la tercera ronda, nadie ha echado un vistazo serio a la pila tecnológica. Es muy extraño. Tienes auditores que solo marcan casillas, pero en mi opinión, esos no cuentan. Solo fingen hacer el trabajo. No hacen nada sustancial. Es súper fácil engañar a esas personas porque lo único que tienes que hacer es mentir. Simplemente dices, “¿Hacen eso?” “Sí, lo hacemos.” “Muéstranos.” Muestras algo que no tiene ningún sentido. El auditor no es una persona técnica, por lo que podrías mostrarle cualquier cosa, y él simplemente diría, “De acuerdo, casilla marcada.” Al final de esas auditorías, es muy intrigante. En las auditorías clásicas, el auditor dirá, “Por favor, firma este papel que dice que no nos mentiste, y si mentiste, declinamos toda responsabilidad.” Mi opinión es que ciertamente no voy a hacer eso. No asumo que las personas me estén diciendo la verdad. Por eso quiero ver la base de código. Sí, puedes engañarme y decirme montones de cosas, pero cuando miramos la base de código, forjar una base de código, forjar miles de commits, forjar cientos de tickets, forjar todos los documentos de apoyo, eso es mucho más difícil. Lo que me sorprende es que el costo es de un día de auditorías. Sí, no soy precisamente barato, pero aún así, es un día. Incluso después de realizar estas auditorías por más de una década, todavía noto que cuando llego, incluso en la segunda o tercera ronda, nadie ha desafiado realmente la tecnología. La gente simplemente asume que es buena, que funciona, y que harán su hoja de ruta. No se realiza ningún chequeo. Para mí, eso es un poco desconcertante.
Conor Doherty: Bueno, con suerte, algo de lo que hemos discutido hoy hará la diferencia, y quizás incluso inspire a algunas personas a ponerse en contacto contigo. También estás disponible para bat mitzvahs y cumpleaños, creo.
Joannes Vermorel: Sí.
Conor Doherty: Bueno, Joannes, muchas gracias por tu tiempo y por responder todas mis preguntas. Muchas gracias, y gracias por ver. Nos vemos la próxima vez.
