
"La clave es que todo este proceso de “entender la historia del error” sea en equipo; que todas las personas involucradas entiendan cuál fue su rol en lo que pasó."
¿Qué habilidades necesitaste desarrollar al transicionar de líder de equipos a CTO?
A mí me costó entender/aceptar que el rol era mucho más que la tecnología pura y dura; que tenía que salir de mi zona de comfort (desarrollar software, resolver problemas, administrar equipos de desarrollo) y pasar a entender de temas que antes me resultaban ajenos: negocio, operaciones, marketing, growth, inversores, etc.
El rol de CTO tiene un problema: en ningún lado te enseñan cómo hacerlo (bienvenidos ads de universidades de dudoso prestigio con sus ofertas de “Become a CTO” 😂).
Y es difícil aprender copiando al/la CTO de tu trabajo actual porque en general, uno -como parte del equipo de tecnología- sólo ve una cara del rol (la que mira ‘hacia abajo’, al equipo).
En mi opinión, este rol es justamente hacer de nexo entre tecnología y TODO LO DEMÁS; ésta es la cara que no ven sus reportes, cómo es la interacción del/la CTO con sus pares (Finanzas, Growth/Marketing, Operaciones, etc).
En empresas chicas-medianas -que es lo que yo conozco- el CTO tiene que entender el negocio de punta a punta, los objetivos para el año (entenderlos, influenciarlos), estar al tanto de en qué están trabajando sus pares para apoyarlos.
También es importante que pueda representar los intereses y pedidos de sus equipos en las mesas chicas; por supuesto siempre calibrándolos con las necesidades del negocio.
Otra tarea importante del CTO es traer propuestas a sus pares (C-level), que puedan darles nuevas ideas, cosas que antes eran difíciles/caras/impracticables ahora se vuelvan posibles.
El ejemplo perfecto es GenAI: todo el mundo ve a las AI generando texto y todos escucharon que “las computadoras van a hacer el trabajo de los humanos”, pero es difícil pensar “¿exactamente cómo una AI va a hacer el trabajo de esta persona que hace X?”.
CTOs pueden dar charlas, armar demos con sus equipos para acercarles soluciones tecnológicas a sus pares y sus equipos.
¿Cuáles son las claves para liderar en una startup?
Para mí es muy importante mostrar el compromiso que lxs líderes tenemos con la idea/el problema que queremos resolver.
Mostrar compromiso y dedicación es contagioso; dar el ejemplo, mostrar que estamos dispuestos a hacer lo que haga falta para cumplir los objetivos; incluyendo tareas que por nuestra posición en la organización no se esperaría que hagamos.
Explicar todo el tiempo cómo las pequeñas tareas aportan a los grandes objetivos: POR QUÉ este pequeño bug es importante, PARA QUÉ se va a usar este mínimo feature nuevo; conectar todas las tareas con el sentido.
El ritmo en un startup es muy acelerado, pero es importante tomarse el tiempo de festejar los logros individuales y grupales; de ocuparse de que cada persona del equipo aprenda cosas, que se estire, gane responsabilidades nuevas y que disfrute la experiencia, que es intensa pero también una oportunidad de crecer mucho.
¿Cómo encarás los errores en tus equipos?
Yo divido los errores en dos grupos: los que ocurren por estar explorando cosas nuevas y son sorpresa para todos (digamos, los errores nuevos) y los que no tendrían que haber ocurrido.
Un startup es, por definición, algo que tiene riesgo: si no hay espacio para cometer errores, nadie se anima a tomar riesgos.
Para mí es muy importante entender de dónde vino el error, y poder reconstruir el camino que nos llevó a cometerlo, qué pasó exactamente y cómo lograr que ese tipo de errores no se repitan.
La clave es que todo este proceso de “entender la historia del error” sea en equipo; que todas las personas involucradas entiendan cuál fue su rol en lo que pasó: un stakeholder que apura al equipo de desarrollo, el/la manager que no puede/quiere explicar el riesgo que conlleva sacarlo antes, un/a desarrolladorx al/la que le falta tiempo para hacerlo más robusto y no lo dejó claro, etc.
El rol de los managers es clave en estas dinámicas: hay que evitar a toda costa los dedos que señalan y echan culpas; tiene que ser claro que la responsabilidad -casi nunca- es de una sola persona y tiene que haber un buen plan de cómo este error no se va a repetir nunca-jamás.
La velocidad que necesita un startup lleva a cometer errores y creo que es importante aprovechar los errores (sus diagnósticos, post-mortems, etc) para abonar una cultura de experimentación; donde para cada nuevo proyecto se entiendan bien los riesgos y se pueda armar un plan para experimentar controladamente; que los errores no sean tragedias.
Una vez hablaste de usar humanos donde hacen falta y computadoras en el resto (link). ¿Cuál creés que es el rol de los humanos ahora?
Cuando yo dije eso, era pre GenAI; lo tenía mucho más claro entonces que ahora 😂
Creo que la idea sigue siendo la misma: los humanos tienen que hacer el trabajo creativo, las máquinas el repetitivo y el aburrido.
Pero es interesante que cosas que hace 2 años eran claramente ‘de los humanos’ porque se sentían ‘creativas’ (ej, escribir código) ahora no resultan tan evidentemente ‘sólo de humanos’.
¡El mix de “humano dice lo que hay que programar, computadora escribe el código, humano lo retoca” funciona muy bien!
Y en esos casos la idea original se sostiene: lo creativo era entender “qué” había que hacer, no “cómo” hacerlo.
Obviamente esto no es así en todos los casos; muchas veces tenemos que desarrollar la solución a un problema nuevo y la parte creativa es entender ‘cómo’ hacerlo.
De cualquier manera, mientras aprendemos a pedirle precisamente a las GenAI que nos hagan cosas; todavía tenemos un rol de entender y evaluar las respuestas; no seas como esta persona que al pedirle a ChatGPT una sugerencia de como deployear algo, se salteó el requerimiento -obvio- de que el servicio esté online todo el tiempo.
El otro día alguien se reía que en una época se autodenominaba “code poet”; para mí los programadores siempre fuimos una especie de carpinteros o mecánicos.
¿Qué características buscás en tus pares y jefes en los equipos a los que te sumás?
Yo sólo quiero trabajar con team-players; personas que entienden que el equipo es el que va a sacar adelante el proyecto.
Me gusta trabajar con gente que sabe mucho de un tema y ese conocimiento puede servir para explorar algo nuevo, que es seguramente lo que estemos haciendo.
Pero entre estos expertos valoro especialmente a los que saben-lo-que-no-saben y que estos otros temas les interesen, les den curiosidad o, como mínimo, muestren respeto por lo que saben los demás.
Creo que a toda costa hay que evitar a la gente tóxica, gente que empeora el ambiente; no importa qué tan buenos sean en lo que hacen, es mejor no tenerlos cerca. Muchas veces los avisos de búsquedas laborales (job postings), involuntariamente/irresponsablemente, tienen señales que acercan gente tóxica (“rockstars”) y alejan a los team-players.
Respecto a los jefes, yo valoro muchísimo el compromiso: ¿por qué está haciendo lo que está haciendo? ¿Realmente cree en el proyecto/la misión?
A veces toca reportar a alguien con quien hay menos coincidencias; creo que ahí es importante hacer un buen managing up, explicar qué es lo que necesitamos para trabajar mejor pero también ser permeables a las ideas del jefe/a – al final es una oportunidad de aprender algo nuevo.
Yo siempre tengo claros mis límites, qué líneas no quiero cruzar, y si no hay manera de hacerlo andar, salir a tiempo para poder salir bien.
Martín es un builder (un constructor) y valora el trabajo en equipo. Co-Founder y CTO de RETCOUSA. Su trayectoria involucra roles técnicos y de producto en todo tipo de organizaciones. Co-fundador y CTO de Properati, adquirida luego por OLX. Cofundó Hacks hackers, una comunidad de programadores, periodistas y diseñadores; buscando nuevas maneras de contar historias. LinkedIn.
Suscríbete al newsletter mensual de www.sabinapeskincoach.com sobre Carrera y Liderazgo.