Justo hace un año, me embarcaba en una aventura que a la mayoría de perfiles técnicos nos hace mucha ilusión (qué leches, a cualquiera perfil vocacional, ¿no?), que es arrancar un producto desde cero. La ilusión pero también la responsabilidad de sentar los principios culturales y tecnológicos de una organización, sin heredar decisiones previas.
En este caso, además, con una misión bastante bonita, ayudando a salir adelante a gente muy currante de un sector con unos márgenes de beneficio bastante estrechos.
No era mi primera experiencia liderando equipos: venía de ser team lead en Unlimiteck para Mineo y Claridae, ¡que eran plataformas que no eran moco de pavo precisamente! pero tener a un CTO como Diego, pues no es que tengas una red de seguridad, es que tienes a la Legión ahí, si es que necesitaras algo. Unlimiteck es una fantasía de sitio para trabajar:
Pero necesitaba abandonar el nido y probarme en esas responsabilidades y sin red, iniciar un pilgrimage. Otro día hablaremos de si este tipo de movimientos son una buena idea... que hay bastante tela que cortar.
En esta nueva aventura, un año después y con el MVP completado, no he continuado por diferencias en cuanto a la dirección a seguir con el producto (creo en el "disagree and commit", pero no si se extiende mucho en el tiempo). Eso sí, sigo creyendo en la idea, en los cimientos que construimos y en el equipo que allí dejo. La única razón para no enlazarlos en este artículo es que esto es una introspección personal que no quisiera que les afectara en lo más mínimo (que de todas maneras veréis que no tiene por qué). En cualquier caso, quería hacer introspección de esta primera experiencia que he tenido como responsable técnico de una startup, con sus luces, sus sombras, y algún claroscuro.
Como se me da especialmente bien autoflagelarme, empiezo con mis cagadas, pero me he obligado a escribir una continuación con los aciertos y así acabar bien arriba 🚀.
Sombra #1: dar una fecha “de entrega”.
Una de las cosas que más me ha sorprendido al hacer este ejercicio de introspección es comprobar como "saberte la lección" no implica para nada que luego la vayas a aplicar correctamente. En realidad, ninguno de los errores que os cuento aquí es nada nuevo (ni para mí, ni a bien seguro para ninguno de los que lo váis a leer). Y aún así...
El caso es que dije que el MVP estaría listo a finales de marzo. No lo estuvo hasta tres meses después. ¿Cómo se me ocurre dar una fecha de final, estando al inicio, sabiendo que SIEMPRE hay unknown unknowns? En mi defensa diré que no nació de mi el dar la fecha y que es difícil no empatizar con los stakeholders, que querían tener por lo menos un marco de referencia. En defensa de los stakeholders diré también que tampoco rodó mi cabeza por ahí al ir pasando de la fecha. Pero lo cierto es que nos puso a todos bastante presión encima.
¿Qué podría haber hecho mejor?
Debería haber resistido esa tentación y haber dado muchísimo más la turra con que es muy difícil predecir el tiempo que va a llevar resolver un problema con software. Estimar es timar. Como casi siempre cito del Rapid Development:
"The basic software-estimation story is that software development is a process of gradual refinement. You begin with a fuzzy picture of what you want to build and then spend the rest of the project trying to bring that picture into clear focus. Because the picture of the software you're trying to build is fuzzy, the estimate of the time and effort need to build it is fuzzy too." (p. 165)
Por intentar ponerle un matiz positivo, esto me empujó más a poner énfasis en la comunicación de progreso: a dar transparencia con frecuencia sobre en qué punto estábamos, de manera que al menos todos pudimos ir reaccionando en consecuencia.
Sombra #2: reaccionar tarde a un no cultural fit.
Eramos una startup, sí, y estábamos haciendo un MVP, también. Pero por el dominio del problema, teníamos unos requerimientos más parecidos a una fintech en cuanto a robustez y credibilidad se refiere. Aquí tener errores era causarle un problema de reputación al usuario para con sus clientes. No nos podíamos permitir sloppy code. Tampoco íbamos a rehacer (al menos en un futuro cercano) el MVP.
Seguro que os suena la historia de los tres tipos de trabajadores en tech: Commandos, Infantry, and Police. Lo que necesitábamos más que probablemente era infantería, sin embargo, teníamos un miembro del equipo con una mentalidad más comando, no muy dispuesto a cambiar de estilo. Hablé mas sobre esto en "Ask HN: How bad should the code be in a startup?". Tardé bastante en tomar acciones sobre algo que ya se veía que no iba a cambiar y nos costó un tiempo precioso.
¿Qué podría haber hecho mejor?
Este es probablemente otro viejo conocido: Hire Slow, Fire Fast (aunque ojo con este artículo en concreto, que huele regular, como a naftalina). En realidad sería más un "hire smart, fire when you know you have to".
"Hire smart" porque no se trata de que sea corto o largo el proceso, sino de obtener la información que necesitas (que casi siempre suele ser si hay cierta competencia básica y sobre todo, si el carácter y la motivación intrínseca de una persona es la adecuada, para colaborar con otros en general y para el contexto de ese proyecto en particular).
"Fire when you know you have to": si ya han habido un par de conversaciones honestas con esa persona y no hay brotes verdes (un compromiso, una intención al menos), ¿a qué esperamos? Cuando me he tenido que enfrentar a la situación de tener que despedir a alguien, realmente intuía desde tiempo atrás que ese iba a ser el final, por más que luchara para evitarlo. ¿Por qué alargar esas agonías, que son agonías para todos los implicados?
Sombra #3: customer feedback muy tardío.
Otro clásico, cero unidades de sorpresa. Hay terabytes de información en artículos, libros, teorías... sobre la importancia de involucrar al cliente / usuario cuanto antes, sobre iterar sobre el producto y tener así múltiples feedback loops... Es que de verdad que en este párrafo podría citar casi cualquier libro de ingeniería de software, diseño, negocio o producto.
Pero, como siempre, una cosa es saberse la receta y otra muy distinta el conseguir persuadir a tu organización para que la aplique. Avanzamos durante meses en el desarrollo de la plataforma sin que nadie la usara. En esta situación, me obsesioné con que tuviéramos test de todo tipo, porque era lo que podía accionar por mi parte: units, de integración, exploratorios, test beds con las plataformas de delivery... Pero es que esto no te salva de los casos de la vida real (por no hablar del diseño, de cómo creíamos que se usaría nuestra app).
A todos nos ocurría en mayor o menor medida algo que describe a la perfección, por ejemplo, Extreme Programming Explained:
The objection I hear to customer involvement is that someone will get exactly the system he wants, but the system won't be suitable for anyone else. It's easier to generalize a successful system that to specialize a system that doesn't solve anyone's problem (p. 62)
The sausage factory (…) 'if the customer knew how messed up software development was, they'd never trust us'. Are you sure they trust you now?. Software reflects the organization that builds it. The customers are already using the software so they already know a lot about how you develop. (…) When you act trustworthy and have nothing to hide, you are more productive." (p. 62)
En este caso, además, lo de la fábrica de salchichas ni siquiera nos aplicaba. Creo que todos estábamos (¡y yo sigo estando!) bastante orgullosos de lo que nos estábamos trayendo entre manos, a pesar de las dificultades del producto, que no estaban tampoco nada mal: las dificultades propias de integrarte con muchos servicios externos, a los que además no necesariamente agradas.
¿Qué podría haber hecho mejor?
Aquí me faltó valor. Podría haberme esforzado más por persuadir de la importancia de esto. Incluso si no conseguía convencer a la organización de la importancia del customer feedback desde los inicios, tendría que haberme echado esta responsabilidad a la espalda y haberme dado vueltas por los negocios que eran nuestros usuarios portenciales, desde el principio, validando con ellos que todo tenía sentido. No tenía muy claro cómo compensarles ese tiempo, pero ya podría haber pensado algo (aunque hubiera sido fregarles los platos).
De hecho, al final, me pudo más el miedo a que estuviéramos errando, que la timidez, y empecé a tener live demos yo mismo. Afortunadamente, no descubrimos nada que nos hubiera tirado el producto abajo, pero sí que empezamos a enriquecerlo con las ideas que nos iban aportando, y ganamos bastante en seguridad.
Sombra #4. Overcommitment. Compensar la sensación de falta de control con muchas horas.
Yo me llevo muy mal con la incertidumbre. La parte buena es que me hace de motor para esforzarme a eliminarla. La parte mala es que mi mecanismo normalmente es echarle horas encima a la semana y es muy fácil que me pase de rosca.
Soy plenamente consciente de que me ocurre y me tengo más o menos monitorizado. Pero eso no me impidió auto infringirme estas horas de trabajo:
No solo estaba mi curro principal ahí, sino que seguí siendo profe de MIOTI (con algún extra como esta webinar sobre el Data Science vs COVID19), y por otro lado también cursé el programa de Dirección de producto en Instituto Tramontana (otro modo más de ver si ejercía control sobre esta nueva situación).
Creo que no hice ni una semana de 40 horas en todo el año, salvo agosto, que me pillé dos semanas de vacaciones con un burnout terrorífico: de estos en los que empiezas a no verle el sentido a absolutamente nada (y en realidad, lo que te pasa es que estás agotado):
¿Qué debería haber hecho mejor?
¿Echar menos horas?
Aquí la salvación me llegó en forma de ponerse en manos de un psicólogo y lidiar con estos sentimientos de hiperresponsabilidad, vergüenza, culpa, prisa... El impacto que tuvieron las consultas durante ese período fue… brutal, mucho mayor que el que me hubiera imaginado. Mi psicólogo me proporcionó unos conceptos a los que agarrarme que fueron auténticas burbujas de aire.
Precisamente estar en una startup e intentar ir de lean por la vida es eso, exponerte a una serie de emociones y aceptarlas... Van de la mano con el curro, son gajes del oficio. Escribí también sobre esto en aquel momento, cuando mi psicólogo me recomendó leerme el Daring Greatly de Brné Brown, que es verdaderamente liberador.
Lo ideal hubiera sido haber reaccionado antes (again) y haber pedido ayuda en ese momento. No esperar a haber acumulado las paladas de ansiedad que llegué a acumular. Aparte, en algún momento tendré que asumir que uno tiene que ser más selectivo, que no puede hacer todo lo que quiere hacer, que un día solo tiene 24h. Pero esto, esto va a llevar mucho más tiempo. Un gran work in progress.