No existe una definición universal del rol del líder de tecnología o CTO de una startup. 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 los fundadores. Aunque nuestras responsabilidades cambien a lo largo de la vida de la startup, existe un conjunto de habilidades que nos ayudan a definir nuestro rol como CTO.
En este artículo, les propongo una definición del rol del CTO con base en las habilidades que debe tener y que, en mi experiencia como CTO, son fundamentales para este rol, ya que estos 6 grupos de habilidades nos ayudarán a ser mejores líderes de tecnología.
Explicaré el porqué con ejemplos y mencionaré algunos tips y recursos sobre cómo puedes mejorar dichas habilidades. Espero que esto pueda contribuir a:
“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 marcó el inicio de nuestras carreras como CTO. 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 eso esté mal.
El hecho de ser un rol relativamente nuevo hace que sea difícil definirlo. Para algunas startups, un CTO escribe código. Para otras, solo lidera a otros ingenieros o solo debe encargarse de la infraestructura. Aún 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.
Es difícil encontrar programas de entrenamiento para aprender las habilidades que debe tener un CTO. En las universidades, hablamos de programas para líderes técnicos, arquitectos de software, programadores avanzados, y hasta de gerentes de IT, pero no se escucha la palabra “CTO”.
Sin una definición ni un programa para formarnos, nuestro camino es aprender a ser CTO a través de la experiencia. En mi caso, llevo más de 10 años en este camino y he cometido muchos errores, que han llevado a la quiebra de algunas compañías, así como muchos aciertos, que me han permitido formar equipos de cientos de ingenieros.
Antes de poder tomar cualquier decisión, como CTO, debemos entender los elementos básicos de un negocio. Si la tecnología que hacemos no está generando valor para la startup (aumentando el número de usuarios, ventas o la rentabilidad), estamos desperdiciando el impacto que podemos tener con lo que construimos y el tiempo que nuestros ingenieros le dedicaron.
Al hacer software, nos enfocamos en la cantidad de features, qué tan rápido responde el sistema, qué lenguaje usar, en cuánto tiempo subir a producción, entre otras cosas. Y, en la mayoría de casos, no somos conscientes del valor que tienen estos elementos en el negocio.
El negocio no solo define qué software construimos: también cómo lo hacemos, es decir, cuándo se debe desarrollar más rápido, cuándo con más calidad, cuándo enfocarse en performance, seguridad, etc. Por ello, una de las habilidades 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.
Ya que no entender lo anterior puede llevarte a desperdiciar dinero y tiempo, algunos ejemplos de esto son los siguientes:
Puedes conocer más sobre los Retos de Emprender en SaaS y el Camino de un Founder Técnico revisando el episodio del podcast Startupeable de Alejandro Casas, CEO y cofundador de Simetrik.
Libros que recomiendo para entender el negocio como CTO:
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, es decir, es la herramienta que nos permite incorporar partes complejas de los programas a nuestros análisis, pero sin tener que comprender todos sus detalles. Su principal objetivo es entender las necesidades de los clientes para que nuestro equipo pueda satisfacerlas usando tecnología.
Por ejemplo, un producto es aquello que permite a un usuario pedir las compras del mercado desde la comodidad de su casa a través de su teléfono móvil, en menos de 3 clics. En términos de negocio, la rapidez del proceso de compra puede aumentar las ventas y reducir los costos de conseguir nuevos usuarios. En términos de tecnología, la app móvil fue construida en Swift y usamos una base de datos en Firebase.
Es así que el CTO suele ser la primera persona que toma decisiones sobre el producto. Es quien 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 luego un equipo más grande de ingenieros implementa.
Aunque existen CTO que lideran áreas de producto, esta no es la regla. Sin embargo, como mínimo, deben 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 las habilidades de entender y abstraer el producto como CTO hace que las áreas de producto e ingeniería no estén alineadas. Esto conlleva a:
Si estás pensando en crear tu MVP, te recomendamos revisar el artículo de 3 Lecciones de Fundadores Latinos para crear el Producto Mínimo Viable (MVP) de tu Startup.
Libros y programas que recomiendo para entender el producto como CTO:
No hay mejor consejo para asegurar el éxito de una compañía que iterar continuamente para satisfacer las necesidades de los clientes. Sin embargo, en el proceso de construir tecnología, esto conlleva mucha incertidumbre. Y cada iteración puede contar con información y prioridades diferentes.
Como CTO, necesitamos un equipo que pueda construir de manera flexible. Con esto no me refiero a hacer soluciones de baja calidad. Significa que estemos cómodos con tomar decisiones rápidas y con hacer cambios. Además, nos encontramos en una industria con alta rotación y costos de personal elevados. Debemos plantear estrategias para contar con equipos comprometidos y que se adapten a la realidad de una startup.
En la práctica, liderar equipos es de las habilidades que más nos cuesta dominar como desarrolladores, pues no fuimos formados para esto. Somos buenos construyendo un MVP y liderando un equipo pequeño. Pero, cuando el negocio empieza a crecer aceleradamente y debemos contratar más personas, terminamos en un punto en el que no tenemos claro por dónde empezar.
Otra de las habilidades de un buen CTO es la de crear y liderar un equipo con roles lo suficientemente flexibles y medibles para ajustarse a una estrategia de producto cambiante. Asimismo, 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. Si no entendemos cómo hacerlo de manera adecuada, tendremos equipos con alta rotación y desperdiciaremos recursos en el camino. Esta nueva etapa representa un gran cambio en nuestras carreras, ya que nuestra productividad deja de ser medida por la cantidad de código que escribimos.
Si quieres saber más sobre cómo armar y escalar un equipo técnico, escucha el episodio de Ruben Sosenke, ex CTO y cofundador de Pedidos Ya, sobre cómo lo logró desde cero hasta IPO.
Libros que recomiendo para mejorar las habilidades de liderazgo de CTO:
La tecnología con la que construimos el software, o hardware, que soporta nuestro producto es fundamental para lograr los objetivos de negocio de nuestra startup. 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, trabajamos con frameworks que nos permitan modificar el producto continuamente de manera ágil. Si la compañía crece, utilizamos tecnología que permita soportar este crecimiento optimizando el rendimiento de nuestro producto.
En la práctica, un CTO es 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, porque 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.
Independientemente 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. Debemos guiar y dar los recursos necesarios (tiempo y dinero) a nuestro equipo para poder implementarlos.
Es muy común encontrar decisiones técnicas que no necesariamente optimizan la construcción de un producto, como, por ejemplo, al escoger un lenguaje porque es “cool” o porque “todos lo usan”, o cuando todos piensan que la solución es crear microservicios cuando no se sabe cuál es el problema que tiene el producto. Por ello, independientemente de si el CTO es el que programa o no, lo importante es tomar las decisiones técnicas adecuadas para el desarrollo del producto.
Libros y recursos que recomiendo para mejorar nuestras habilidades de arquitectura de tecnología:
Construir tecnología es un proceso iterativo e incremental. Development Operations (DevOps) es el proceso que va desde escribir la primera línea de código hasta desplegar nuevas versiones de software con la calidad adecuada. El nivel al que optimizamos el proceso de construir tecnología nos permitirá tener un producto de mejor calidad que evoluciona más rápido que nuestra competencia.
En la práctica, solo pensamos en ingeniería cuando hay problemas de rendimiento en nuestros servidores. Y usualmente delegamos esta responsabilidad a ingenieros que llamamos DevOps, esperando que esto nos convierta en un equipo eficiente.
Trabajar en una buena infraestructura y un proceso que nos haga iterar nuestros productos cada vez más rápido puede determinar el éxito de nuestra startup. Sin embargo, en el aspecto tecnológico, somos más reactivos que proactivos.
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 la startup, ya sea porque el producto es deficiente o porque sobredimensionamos la infraestructura.
Libro que recomiendo a un CTO para entender cómo diseñar y optimizar los procesos de DevOps:
Al inicio de una startup, nos preocupamos por guardar y mantener información para poder responder:
Luego, si nuestras hipótesis se cumplen, comenzamos a preguntarnos:
Y, si el número de clientes crece, la cantidad de preguntas que debemos responder también:
Si las cosas siguen bien, la operación de tu startup empieza a crecer y con ello la necesidad de información. Es ahí cuando, como CTO, te comienzas a preguntar:
Estas preguntas aumentan y necesitan resolverse cada vez más rápido. Ahora, nuestra startup está consumiendo la información en el momento en que la necesita y vemos la oportunidad de usar la información pasada para optimizar procesos con modelos de predicción y automatización.
El valor de la información a lo largo de la vida de una startup puede ser medido por la cantidad y la calidad con la que debe estar disponible. Por ello, otra de las habilidades que debemos tener como CTO es entender y diseñar estrategias que permitan que la información se consuma en el momento en que se necesita, con la mayor integridad y calidad posible. Es importante entender cómo extraer el valor de la información que capturamos a través de los productos.
En la práctica, he encontrado muy pocos CTO que tienen una estrategia de manejo de datos establecida desde el inicio. Construimos productos y damos por hecho que, si queremos consumir información, nos conectamos a las bases de datos y hacemos consultas. Esto conlleva:
Recursos que recomiendo para que, como CTO, crees una estrategia de manejo de datos: