Sam Altman y la importancia de la velocidad de iteración

Las cosas que Sam Altam le hubiera gustado que le contaran, y por qué iterar rápidamente es clave para crear compañías y productos de éxito.

Sam Altman, ya antes de convertirse en el CEO de OpenAI, era una referencia en el ecosistema emprendedor de Silicon Valley. Fue la persona elegida por Paul Graham para liderar la aceleradora más famosa del planeta, YCombinator, y ha sido angel investor en múltiples empresas de la talla de AirBnB, Stripe o Reddit.

Graham, apuntó sobre Altman en uno de sus ensayos en 2008:

Sam Altman has it. You could parachute him into an island full of cannibals and come back in 5 years and he'd be the king. If you're Sam Altman, you don't have to be profitable to convey to investors that you'll succeed with or without them. (He wasn't, and he did.) Not everyone has Sam's deal-making ability. I myself don't. But if you don't, you can let the numbers speak for you. — A Fundraising Survival Guide, Paul Graham

Muchos le comparan con Steve Jobs, y, como Jobs, no está libre de sombras. Justo ayer el Washington Post aprovechaba la definición de Graham para hacer un perfil de Altman y sus contradicciones: “King of the cannibals”: How Sam Altman took over Silicon Valley.

Independientemente de la opinión que se pueda tener de él, es indudable que Altman lleva cerca de 20 años viviendo de primera mano el emprendimiento en Silicon Valley. Y de toda esa experiencia, hay mucho de lo que aprender.

El viernes, Altman escribía un post en su blog titulado "What I Wish Someone Had Told Me”, en el cual lista 17 ideas y/o aprendizajes que le hubiera gustado que alguien le hubiera contado de antemano.

Entre los temas principales de la lista, encontramos:

1. Temas de gestión de equipos y liderazgo

2. Temas de actitud y motivación

3. Temas estratégicos y de ejecución

4. Temas de comunicación e incentivos

Sin destriparos el artículo, el cuál os recomiendo encarecidamente que visitéis, sí me gustaría destacar uno de los puntos relacionados con la ejecución, porque personalmente creo que es la clave que distingue equipos y productos exitosos de los que no lo son:

11.- Fast iteration can make up for a lot; it’s usually ok to be wrong if you iterate quickly. Plans should be measured in decades, execution should be measured in weeks.

Altman no hace aquí si no expresar en este punto algo que ya me habéis leído en estas líneas, y es que la velocidad de iteración es una ventaja competitiva.

La importancia de la velocidad de iteración

Justo esta semana en mi trabajo me hacía esta misma reflexión. Como casi todas las semanas antes de un periodo festivo, como pueden ser las vacaciones de Navidad, había que apretar para dejar la mejor versión posible de nuestra aplicación disponible.

Para hacerlo, fácilmente habremos creado unas 30 builds distintas. También, diariamente, libérabamos la mejor a un segmento de usuarios para medir cómo rendía en el mundo real.

El martes se dio el caso de que la build que teníamos que subir estaba ligeramente rota. Uno de los cambios había afectado a un caso de uso concreto, y estábamos ante el dilema de publicarla o no hacerlo.

No hacerlo, hubiera supuesto perder una noche completa de datos, algo que ponía en riesgo nuestro plan de dejar la mejor build posible lista antes de Navidades.

Tomé la decisión de sacarla a producción, pero lo hice porque tenía algo muy presente: al día siguiente, a primera hora, podríamos corregir el fallo, preparar una build y publicarla.

Altman lo sintetiza bien. Cuando eres capaz de recuperarte de un error rápidamente, las consecuencias de equivocarte pueden ser aceptables.

Otra de mis reflexiones esta semana fue precisamente la importancia de sentar las bases técnicas para poder liberar cambios en tu producto de forma ágil.

Poder hacer deploys continuos de una aplicación no es una cuestión simplemente actitudinal. Necesitas tener una infraestructura detrás y haber hecho un trabajo previo que te permita tener garantías. Entre otras cosas:

• Necesitas aplicar prácticas y sistemas de integración contínua

• Necesitas tener una buena cobertura de tests automáticos

• Necesitas trabajar en incrementos pequeños que sean fáciles de validar

• Necesitas flujos de trabajo libres de complejas revisiones que puedan prevenir que el código llegue a producción

• Necesitas tener una excelente plataforma de instrumentación que te permita detectar errores lo antes posible

• Necesitas poder revertir los cambios con facilidad

Llevo más de 20 años trabajando en tecnología. He visto y vivido todas las experiencias imaginables. Creedme cuando os digo que absolutamente nada ha sido tan crítico en mis empresas y equipos como la facilidad para desplegar cambios de forma contínua.

Sin duda alguna, será la primera inversión que haré cuando vuelva a emprender. Y también sería el patrón en el que me apoyaría para elegir al CTO. Pocas preguntas te dan tanta información de la experiencia de un líder técnico como saber cuántas veces desplegaban código a producción en sus equipos anteriores.

Debo reconocer que el post de Altman me ha venido al pelo para reforzar mi obsesión por la entrega temprana. Pero creedme, la diferencia entre estar en un equipo en el que puedes tener datos de un día para otro respecto a otro donde lo haces cada dos semanas es abismal.

Incluso a nivel de carrera profesional. Aceptar un puesto de trabajo en una empresa que no es capaz de sacar código a producción diariamente, puede ser una pesada losa a superar.

Suficiente turra por hoy. Como siempre, espero que os haya gustado, os animo a compartirlo, y en estos días tan especiales, os deseo que paséis unas muy felices fiestas con vuestras familias y amigos 🎅. ¡Hasta el domingo que viene!