Las 6 habilidades que todo líder de tecnología (CTO) de una startup debe tener

Desde escribir código, resolver bugs, hasta liderar cientos de personas. ¿Qué habilidades debe tener un CTO?

Resumen: No existe una sola definición del rol del líder de tecnología de una startup (en adelante, CTO). Pasamos de ser los primeros desarrolladores y escribir el código de la primera versión del producto, a liderar equipos de cientos de ingenieros y planear estrategias de la mano de founders e inversionistas. Aunque nuestras responsabilidades cambien a lo largo de la vida de un startup, existen un conjunto de habilidades comunes que definen este rol.

En este post describo 6 habilidades que, en mi experiencia como CTO, son fundamentales para este rol en cualquier momento. Explico el por qué de cada una de ellas con ejemplos y menciono algunos tips y bibliografía sobre cómo mejorar dichas habilidades.

Mi objetivo es generar una discusión, saber sus opiniones y poder definir una visión común del rol de un líder de tecnología en conjunto con ustedes.

Espero que esto pueda contribuir en 3 formas: A quienes son CTOs darles una guía para enfocar sus esfuerzos y mejorar sus habilidades; a quienes están buscando un CTO, ofrecerles un framework para evaluar a sus candidatos; y a la comunidad de startups de tecnología en general en formar más personas que puedan liderar compañías de tecnología.

Ps. Este es el primero de varios artículos para construir una guía para quienes quieren convertirse en grandes líderes de equipos de tecnología. Si te gusta, no olvides inscribirte a mis publicaciones:

Todo empieza acá:

“Venga, usted que sabe programar, no quiere ser el CTO? Es que me dijeron que para hacer una startup siempre tiene que existir una persona técnica que haga el producto y, además, a los inversionistas no les gusta que no haya un CTO”

Para muchos de nosotros como desarrolladores, esta frase definió el inicio de nuestras carreras como CTOs. Muchos de nosotros nos nombramos a nosotros mismos. A veces, por ingenuidad; otras veces, porque todas las startups lo hacen; y otras, porque simplemente no hay nadie más disponible. No creo que esto esté mal, aclaro. Por el contrario, pienso que se debe a una situación natural por las que pasan otros roles como “product manager”, “data scientist”, “community manager”, “digital marketer”, entre otros; y es que todos ellos fueron creados recientemente. Hace 10 años nadie hablaba de ninguna de estas posiciones. Aún así, hoy en día son fundamentales para las principales compañías tecnológicas en el mundo. 

El hecho de ser un rol relativamente nuevo hace que sea difícil definirlo. Para algunas compañías un CTO escribe código, para otras solo lidera otros ingenieros, y para otras solo debe encargarse de la infraestructura. No existe una definición común que permita entender cómo medir el trabajo de un CTO, cómo interactuar con este rol, y mucho menos definir qué habilidades buscar en candidatos cuando se necesita uno. Así mismo, es difícil encontrar programas de entrenamiento de este tipo de roles. En las universidades hablamos de programas para líderes técnicos, arquitectos de software, programadores avanzados, y hasta de gerentes de IT (sí, todavía existe el término IT 😜) pero nunca se escucha la palabra CTO. 

De hecho, como ingenieros de software nos forman para hacer el mejor software posible, pero como CTO he entendido que no siempre se necesita hacer software 🤯. Nos forman en metodologías ágiles y nos sentimos orgullosos de desplegar código cada 2 semanas, pero en las FAANG (Facebook, Amazon, Apple, Netflix, Google) despliegan código a producción miles de veces por día. Nos forman analizando arquitecturas de sistemas de software que soportan miles de transacciones al día, pero las startups manejan millones de transacciones por hora. Nos forman para construir software, no para convencer a la compañía completa de reescribir el código o seguir con nuestro monolito por unos meses más. Nos hablan de cómo resolver algoritmos en entrevistas de trabajo, pero nunca de cómo convencer a otros ingenieros de trabajar más horas a cambio de acciones de una compañía. Y ni qué decir de hablar o entender a clientes. Todos sabemos que el cliente siempre sabe lo que quiere y me lo especifica en una historia de usuario bien definida (sí obviooo!). 

Sin una definición ni un programa para formarnos, el camino para muchos de nosotros es aprender a ser CTOs desde la experiencia. En este camino de más de 10 años en mi caso, he cometido muchos errores que han llevado incluso a la quiebra de algunas compañías, así como muchos aciertos que me han permitido formar a equipos de cientos de ingenieros. En este artículo, les propongo una primera definición de las habilidades que un CTO debe tener. Esta definición está enmarcada en 6 dominios de conocimiento en los que debemos generar habilidades específicas para ser mejores líderes de tecnología.

1. Habilidades de Negocio

Antes de poder tomar cualquier decisión, como CTOs debemos poder entender los elementos básicos de un negocio. Si la tecnología que hacemos no está generando valor en términos de negocio (usualmente usuarios, ventas o rentabilidad) estamos desperdiciando el impacto que podemos lograr con lo que construimos. Podemos diseñar el software más seguro, o la aplicación más rápida y usable, pero si el negocio no percibe valor de esto estamos desperdiciando el tiempo que nuestros ingenieros dedicaron a construirlo. 

En la práctica, al hacer software nos enfocamos en la cantidad de features, en qué tan rápido responde, en qué lenguaje usar, en cuánto tiempo subir a producción, entre otras cosas, pero en la mayoría de casos no somos conscientes realmente del valor que tienen estos elementos en el marco de un negocio.

En algunos casos dejamos esta responsabilidad a los que “saben de negocio” ignorando la gran ventaja que puede tener entender por nosotros mismos el impacto que tiene el software que hacemos.  

El negocio no solo define el qué software construimos. También el cómo lo hacemos; es decir, define cuándo se debe desarrollar más rápido, cuándo se debe desarrollar con más calidad, cuándo enfocarse en performance, seguridad, etc… Es por esto, que la primera habilidad que debe tener un CTO es la de entender los principales elementos de un negocio para poder abstraer qué tecnología construir, cuándo y cómo construirla. 

No entender lo anterior puede llevar a desperdiciar mucho dinero pues se hace software que no se necesita o que no es prioritario para el momento del negocio. Un ejemplo muy común es el MVP perfecto que nunca sale a producción; o la aplicación que tarda meses en ser construida y cuando sale a producción no cumple el objetivo para el que fue pensada; o el software que compramos o pagamos mensualmente que nadie usa; entre otros casos. 

Libros que recomiendo para entender el negocio como CTOs:

• “Business Model Generation” de Alexander Osterwalder - Resume muy bien los elementos de un negocio de una manera práctica y concisa. 

• “Blitzscaling” de Reid Hoffman - Permite entender el ciclo de vida de las startups y entender las palancas que mueven a un negocio digital en sus diferentes etapas

• “The secrets of sand hill road” de Scott Kupor - Permite entender el por qué las startups deben crecer tan aceleradamente desde el punto de vista de los inversionistas (VC’s). Me ayudó a entender qué significa el término “10x” y su relación con la tecnología que construimos. 

2. Habilidades en Producto

En su versión más básica, un negocio genera valor a sus clientes y, a cambio de eso, percibe valor de ellos en términos de dinero. En teoría, entre más valor generemos a nuestros clientes, más valor podremos percibir y construir un negocio rentable y exitoso. Un producto es el conjunto de ítems físicos o digitales a través de los cuales generamos valor a los clientes. Es una abstracción entre el negocio y el área de ingeniería cuyo principal objetivo es entender las necesidades de los clientes para que nuestro equipo pueda satisfacerlas usando tecnología. Por ejemplo, un producto es el que permite a un usuario pedir un mercado desde la comodidad de su casa en menos de 3 clics a través de su teléfono móvil. Esto, en términos de negocio, aumenta las ventas y me baja los costos de conseguir nuevos usuarios. En términos de tecnología, usamos una app. móvil construida en Swift y una base de datos en Firebase.

En la práctica, un CTO es usualmente la primera persona que toma decisiones en el producto de una startup. Es el que construye el MVP, lidera o subcontrata algunos diseñadores, y habla con clientes para poder iterar el producto. Al crecer la compañía, se crean áreas de producto que abstraen el conocimiento del cliente en roadmaps que un equipo más grande de ingenieros implementa. 

Aunque existen CTOs que lideran áreas de producto, esto no es la regla. Sin embargo, como mínimo debe entender el impacto de las iniciativas de producto y diseñar mecanismos para que el equipo de ingenieros pueda implementar estas iniciativas de manera eficiente. 

No tener la habilidad de entender y abstraer el producto como CTO usualmente lleva a que las áreas de producto e ingeniería no estén alineadas. Esto puede demorar nuevos features y generar reprocesos entre las dos áreas. Puede conducir hacia compañías lentas en donde la tecnología no guía la estrategia o donde el CEO tiene que interferir en el liderazgo de cada área para que puedan trabajar alineadas.

Libros que recomiendo para entender el producto como CTOs:

• Inspired y Empowered de Marty Cagan - Inspired describe los roles de un área de producto. Empowered describe un Framework para diseñar estrategias de producto en una compañía de tecnología.

• Reforge - Retention and Engagement - Provee un framework de crecimiento de compañías basadas en retención de usuarios durante el desarrollo de productos.

3. Habilidades en Liderazgo

No hay mejor consejo para asegurar el éxito de una compañía que iterar continuamente para satisfacer las necesidades de  nuestros clientes. Sin embargo, esto conlleva a mucha incertidumbre en el proceso de construir tecnología pues cada iteración puede contar con información diferente y, por ende, cambiar las prioridades. Como CTOs necesitamos un equipo que pueda construir tecnología de manera flexible. Con esto no me refiero a hacer tecnología mediocre como algunos piensan. Significa que estemos cómodos con tomar decisiones rápidas y con cambios repentinos de prioridad. 

Además de la incertidumbre que lo anterior nos genera, nos encontramos en una industria con alta rotación y costos elevados de cada ingeniero. Debemos plantear estrategias para contar con equipos comprometidos al mismo tiempo que se adapten a la realidad de una startup: A veces no tenemos el presupuesto para pagar salarios competitivos. 

En la práctica, liderar equipos es de las habilidades que más nos cuesta dominar como desarrolladores pues no fuimos formados para esto. Como desarrolladores somos buenos construyendo un MVP y liderando un equipo pequeño de 5 ingenieros, pero cuando el negocio empieza a crecer aceleradamente y debemos traer un equipo que soporte este crecimiento terminamos en un punto donde algunas veces no tenemos claro por dónde empezar o donde no es suficiente el tiempo para todo lo que requiere la compañía. 

Un buen CTO debe tener la habilidad de crear y liderar un equipo con roles lo suficientemente flexibles y medibles para ajustarse a una estrategia de producto cambiante. Así mismo, debe diseñar mecanismos ágiles de contratación que logren inspirar a las personas adecuadas y permitir que crezcan y estén con nosotros por el mayor tiempo posible. 

Cuando el equipo empieza a crecer, usualmente dejamos de programar para cambiar nuestro foco a liderar y diseñar estrategias. No entender cómo hacerlo de manera adecuada puede llevarnos a equipos que tienen altísima rotación y a desperdiciar muchos recursos en el camino. Debemos también entender que este representa un cambio gigante en nuestras carreras (como personas técnicas) ya que nuestra productividad deja de ser medida por la cantidad de código que escribimos.

Libros que recomiendo para mejorar nuestras habilidades de liderazgo:

• High Output Management de Andrew Grove - Provee un framework para administrar y liderar cualquier empresa de tecnología. Después de leer este libro entendí cómo medir a mis equipos.

• Drive: The Puzzle of Motivation - Daniel Pink - Framework para delegar tareas y responsabilidades en un equipo. Entender qué motiva a las personas desde un punto de vista estadístico es lo que más me gustó de este libro.

• What you do is who you are - Ben Horowitz - No hay libro más claro sobre la generación de la cultura de una compañía de tecnología. La comparación que hace con otros contextos en la historia es brillante.

• The hard thing about hard things - Ben Horowitz - Super práctico a la hora de saber cómo manejar equipos.

• Measure what matters de John Doerr - Para que por fin entendamos qué es OKR’s 😂

4. Habilidades en Tecnología

La tecnología con la que construimos el software (o hardware) que soporta nuestro producto es fundamental para lograr los objetivos de negocio de una compañía. Dependiendo de la etapa del negocio, usamos tecnologías diferentes que se adaptan a nuestras necesidades. Por ejemplo, cuando la compañía está en etapas tempranas usamos herramientas que nos permiten hacer prototipos rápidamente. Cuando estamos buscando fit del mercado, usamos frameworks que nos permitan modificar el producto continuamente y de manera ágil. Cuando la compañía crece, usamos tecnología que permita soportar este crecimiento optimizando el rendimiento de nuestro producto. 

Es muy importante diferenciar la Tecnología que utilizamos del Producto que construimos. Recuerden que a través de un producto hacemos que un usuario pida un mercado desde la comodidad de su casa en menos de 3 clics. Esto en términos de negocio aumenta las ventas y me baja los costos de conseguir nuevos usuarios. En términos de ingeniería, construimos una aplicación móvil en React Native conectada a un API REST en Node.js. 

En la práctica, un CTO es usualmente el que ha implementado las primeras versiones del producto como uno de los primeros desarrolladores. Cuando el equipo crece y dejamos de programar, sentimos que ya no somos productivos ya que no tomamos decisiones “técnicas”. Sin embargo, olvidamos que las decisiones técnicas no solo están en el código sino también en la manera como se construye su arquitectura. 

Independiente de ser técnico o no técnico, un buen CTO debe entender cuáles elementos de alto nivel en la arquitectura de un software o hardware (tales como patrones de diseño, lenguajes de programación, frameworks de desarrollo, entre otros) optimizan la construcción del producto. Así mismo, debemos guiar y dar los recursos necesarios (en términos de tiempo y dinero) a nuestro equipo para poder adoptarlos e implementarlos.

Es muy común encontrar decisiones técnicas que no necesariamente optimizan la construcción de un producto. Por ejemplo, al escoger un lenguaje porque es “cool” o porque “es lo que todos usan”. O cuando todos piensan que la solución es microservicios cuando ni siquiera saben cuál es el problema que tiene el producto. Independientemente si el CTO es el que programa o no, lo importante en este dominio es tomar las decisiones técnicas adecuadas para optimizar el desarrollo del producto (recuerden que el producto genera más valor a nuestros clientes, y por ende impacta nuestro negocio). 

Libros que recomiendo para mejorar nuestras habilidades de arquitectura de tecnología:

• Enterprise Architecture as Strategy de Jeanne Ross - Aunque fue difícil de leer, este libro me permitió entender cómo las decisiones arquitecturales en el software afectan el negocio.

• The Why, What and How of Microservices de Jeppe Cramon - Es una charla de una hora pero no he encontrado una versión más clara de por qué, qué, y cómo implementar Microservicios.

• De Monolitos a Microservicios por Mario Villamizar - Excelente curso de un colega que ha trabajado en este tema por más de 15 años.

5. Habilidades en Ingeniería

Construir tecnología (software o hardware) es un proceso iterativo e incremental. Más conocido como DevOps (Development Operations), este proceso se compone de una serie de operaciones que nos llevan desde escribir la primera línea de código hasta desplegar nuevas versiones de software continuamente y con la calidad adecuada. El nivel al que optimizamos el proceso de construir tecnología en nuestra compañía nos permite tener un producto que evoluciona más rápido que nuestra competencia y de mejor calidad. 

En la práctica, solo pensamos en ingeniería hasta cuando hay problemas de rendimiento en nuestros servidores. De manera superficial y sub-dimensionando el problema de infraestructura, usualmente delegamos esta responsabilidad en ingenieros que llamamos DevOps esperando que esto nos haga un equipo eficiente. Trabajar en una buena infraestructura y un proceso eficiente que nos haga iterar nuestros productos cada vez más rápido puede determinar el éxito de nuestra compañía. Sin embargo, somos más reactivos que proactivos en un aspecto tan importante como esto.

Un buen CTO debe identificar, diseñar, implementar y mejorar los procesos de despliegue e integración continua que aceleren el desarrollo de nuestro producto y mejoren su calidad. 

No tener una estrategia o ni siquiera procesos de DevOps puede llegar a limitar el crecimiento de una startup. Bien podríamos llegar a que nuestro producto se caiga constantemente cuando tenemos procesos deficientes de despliegue continuo o a que desperdiciemos recursos por sobre dimensionar la infraestructura.

Libros que recomiendo para entender cómo diseñar y optimizar los procesos de DevOps:

• Beyond CI/CD - El mayor referente para mi es GitLab. No solo el producto me parece increíble, sino que aprendo mucho de la visión de los fundadores sobre lo que debería ser integración y despliegue continuo.

6. Habilidades en Manejo de Información

Entender cómo extraer el valor que necesitamos de la información que fluye a través de nuestros productos es una habilidad clave como CTOs. Al inicio de una startup, nos preocupamos por guardar y mantener información para poder responder a ¿Qué pasó en nuestra startup? Buscamos entender si nuestras principales hipótesis iniciales se cumplen ¿Acaso el cliente usó mi producto? ¿compró o no? ¿se registró o no? ¿logramos nuestras primeras ventas?

Luego, si nuestras hipótesis se cumplen, comenzamos a preguntarnos ¿Cómo repetir lo que acabamos de hacer? El equipo crece y la cantidad de preguntas que debemos responder también ¿Por qué el cliente usa el producto? ¿Por qué nos compran? ¿Cómo puedo convencer a más clientes? etc.

Si las cosas siguen bien, la operación de tu startup empieza a crecer y con ello la necesidad de información. ¿Cuántos clientes están usando mi producto? ¿Cómo está la operación? ¿Tenemos los recursos suficientes? ¿Hay clientes insatifechos? Preguntas como estas aumentan en cantidad y necesitan resolverse cada vez más rápido. Finalmente, nuestra startup está consumiendo la información en el momento que la necesita y vemos la oportunidad de usar la información pasada para optimizar procesos a través de modelos de predicción y automatización.

El valor de la información a lo largo de la vida de un startup puede ser medido por la cantidad de información que se requiere y la rapidez con la que debe estar disponible. Esto sin mencionar la integridad y la calidad de la misma. Como CTOs debemos entender esto y diseñar estrategias que permitan que la información se consuma en el momento que se necesita y con la mayor integridad y calidad posible.

En la práctica, he encontrado muy pocos CTOs que tienen una estrategia de manejo datos establecida desde el inicio. Usualmente, iniciamos a construir productos y damos por hecho que si queremos consumir información nos conectamos a las bases de datos y hacemos consultas. Esto lleva a reducir el rendimiento del producto y son incontables los casos en los que una consulta de información hace que la aplicación se caiga. Otra situación muy común es ver cómo el equipo de ingeniería reduce su velocidad por el hecho de estar ayudando a otras áreas de la compañía a construir consultas o dashboards pues se necesita consumir información para poder operar.

Libros que recomiendo para crear una estrategia de manejo de datos:

• Scaling Data Strategy por Crystal Widjaja, ex VP de Business Intelligence en Gojek- Scaling: Super clara definición para construir una estrategia basada en datos de una startup que crece

• Data Science For All - Programa para poder entender el valor que se puede generar con información existente.

Conclusión

Aún cuando las responsabilidades de un líder de tecnología (CTO) cambian según la startup para la que trabaja, existen habilidades comunes que todo CTO debe tener. Estas habilidades se enmarcan dentro de 6 dominios de conocimiento:

1. Negocio:

   Entender los principales elementos de un negocio para poder abstraer qué tecnología construir, cuándo y cómo construirla. 

2. Producto:

   Entender el impacto de las iniciativas de producto y diseñar mecanismos para que el equipo de ingenieros pueda implementar estas iniciativas de manera eficiente

3. Liderazgo:

   Crear y liderar un equipo con roles lo suficientemente flexibles y medibles para ajustarse a una estrategia de producto cambiante.

   Diseñar mecanismos ágiles de contratación que logren inspirar a las personas adecuadas y permitir que crezcan y estén con nosotros por el mayor tiempo posible. 

4. Tecnología

   Entender cuáles elementos de alto nivel en la arquitectura de un software o hardware (tales como patrones de diseño, lenguajes de programación, frameworks de desarrollo, entre otros) optimizan la construcción del producto.

   Guiar y dar los recursos necesarios (en términos de tiempo y dinero) a nuestro equipo para poder adoptarlos e implementarlos.

5. Ingeniería

   Identificar, diseñar, implementar y mejorar los procesos de despliegue e integración continua que aceleren el desarrollo de nuestro producto y mejoren su calidad

6. Información

   Diseñar estrategias que permitan que la información se consuma en el momento que se necesita y con la mayor integridad y calidad posible.

Este es el primero de varios artículos para construir una guía para quienes quieren convertirse en grandes líderes de equipos de tecnología. Si te gustó, no olvides inscribirte a mis publicaciones y por favor deja un comentario 🙂