#98 El CTO: el Arquitecto (1)
Hola, soy @samuelgil, Partner en JME Ventures.
Bienvenido a mi newsletter semanal, un lugar donde nos reunimos aquellos que creemos que la tecnología transforma juegos de suma cero en juegos de Suma Positiva.
Bienvenidos al tercer episodio de la serie “roles clave en startups”. En anteriores ediciones hemos hablado del COO como complemento del equipo fundador y del CFO como “cartógrafo” del negocio.
Como ya sabéis, el propósito de esta serie es, para cada rol, ayudarnos a responder las siguientes preguntas:
Si fuera un fundador nuevo, ¿cómo sabría si necesito un CxO y/o cuándo?
Como CxO, ¿cómo sé si estoy haciendo bien mi trabajo?
Como CEO, ¿cómo podría medir el desempeño de mi CxO?
Como profesional del área, ¿cómo podría convertirme en CxO?
Hoy nos toca hablar del responsable técnico, al que nos referiremos—muchas veces desacertadamente, como veremos—como Chief Technology Officer o CTO.
Para ello, como viene siendo costumbre en esta serie, me voy a rodear de una serie de enormes profesionales y amigos, que nos van a transmitir diferentes puntos de vista en función de sus sensibilidades y experiencias únicas. Esta vez tengo el absoluto privilegio de contar con:
Javi Santana, cofundador de Tinybird y ex CTO de CARTO
Felipe Talavera, VP of Engineering en Flywire (NASDAQ: $FLYW)
Angélica Lozano, cofundadora y CTO de MLEAN
Miguel Carranza, cofundador y CTO de Revenue Cat (YC S18)
Chema Roldán, cofundador y CTO de Genial.ly
Sergio Gago, ex CTO de Rakuten España y Zinio y mi persona de referencia para temas relacionados con la computación cuántica
Aunque su amplísima experiencia en el rol es el denominador común entre ellos, tenemos la suerte de que las compañías en las que trabajan o han trabajado son muy diferentes en cuanto a sector (fintech, SaaS, contenido, mobile apps…), etapa de desarrollo (desde seed hasta una cotizada) o geografía (España y Silicon Valley). La mayor parte de ellos son cofundadores de sus empresas, pero otros no. Por tanto, la visión que nos van a dar es muy completa. Y es que, además, se lo han currado una barbaridad. Tanto que me veo obligado a dividir sus contribuciones en dos entregas, para que la extensión de esta no se nos vaya de las manos.
Como siempre mi más absoluta gratitud a todos ellos por compartir con nosotros su conocimiento.
Esta edición de Suma Positiva ha sido patrocinada por:
Incapto ofrece una alternativa de verdad a las cápsulas de café con una cafetera superautomática compacta que prepara una taza de café recién molido en 30 segundos, sólo presionando un botón. Un café de especialidad, fresco, tostado semanalmente de manera artesanal y sin residuos innecesarios (al contrario de las cápsulas).
Bea, una de nuestras fundadoras, es catadora profesional y ha elegido cuidadosamente cafés extraordinarios de 12 países de alrededor del mundo para que puedas disfrutar de diferentes sabores y aromas. Viaja con los sentidos por todo el cinturón del café desde la región de Sidamo en Etiopía hasta la comunidad de la Soledad en México, o visitando a las familias de Cajamarca en Perú.
Incapto es la solución ideal para amantes del café que quieren vivir en casa, la experiencia de un café más auténtico con toda la calidad, el aroma y sabor natural que solo el grano encierra.
Disponemos también de la solución perfecta para empresas que quieren impulsar un consumo más sostenible en sus equipos. Facilitamos diferentes máquinas de café superautomáticas que están conectadas a través de un chip, lo que nos permite registrar y enviar a la nube el consumo de cada taza. Gracias a esto, podemos saber y controlar el stock y así reponer el café por ti, sin que nadie tenga que pedirlo. Y lo mejor, es que solo se factura el café consumido, ya sea directamente a la empresa o sus empleados. Una solución más sostenible, más saludable y más cómoda. Y que termina con la recogida de los posos del café para cerrar el círculo.
Únete al nuevo movimiento de los amantes del café sin cápsulas, libre, sin ataduras.
Únete a la revolución del café.
❤️ ¿Quieres patrocinar Suma Positiva? Toda la información aquí.
El CTO: el Arquitecto (1)
Cuando a Nathan Myhrvold, primera persona en ostentar el cargo de CTO de Microsoft (posición que ocupó desde 1996 hasta 2000), le preguntaron “¿Qué es un CTO?”, respondió:
“Hell if I know. You know, when Bill and I were discussing my taking this job, at one point he said, Okay, what are the great examples of successful CTO's. After about five minutes we decided that, well, there must be some, but we didn't have on the tip of our tongues exactly who was a great CTO, because many of the people who actually were great CTO's didn't have that title, and at least some of the people who have that title arguably aren't great at it.
My job at Microsoft is to worry about technology in the future. If you want to have a great future you have to start thinking about it in the present, because when the future's here you won't have the time. “
Por su parte, Werner Vogels, CTO de Amazon, nos cuenta que los primeros CTO entraron en escena a finales de los ochenta. Varias empresas empezaron a capitalizar los resultados que les ofrecían sus laboratorios de I+D y los directores de estos laboratorios se trasladaron a puestos en los que podían utilizar la tecnología para proporcionar a la empresa ventajas estratégicas. Con el tiempo, el rol se fue desarrollando en posiciones muy diferentes.
Una forma interesante de categorizar estas posiciones es la que Tom Berray propone en forma de cuadrantes de una matriz:
Como podemos observar, el contenido del rol cambia en función de cómo de importante sea la información en el producto/servicio que vende la empresa y de la velocidad a la que cambia el negocio.
En nuestro caso, el de las startups tecnológicas, el cuadrante que nos interesa es el de la parte superior derecha: Visionary and Operations Manager. En este caso, el CTO es responsable de determinar cómo se puede utilizar la tecnología para implementar la estrategia de negocio. Este es el aspecto "visionario de la tecnología" del puesto. Pero, además, el CTO es responsable de integrar y emplear la tecnología, es decir, el rol del "gerente de operaciones". En esta categoría, el CTO es a menudo un cofundador de la empresa o una de las primeras contrataciones.
Evolución del rol con el desarrollo de la empresa
Dice Meetesh Karia en The evolving role of a startup CTO que, cuando una empresa tecnológica está en sus primera etapas, el CTO, además de traducir la estrategia de negocio en una arquitectura, una tecnología y un roadmap, suele ser responsable de crear y gestionar el equipo de ingeniería, al mismo tiempo que él mismo sigue contribuyendo en la construcción del producto como programador.
A medida que la empresa crece, es posible que esta persona comience a sentir la tensión de gestionar la ejecución, liderar un equipo y colaborar en la definición de la estrategia. Es momento de, si se quiere, dejar de programar y de dividir el rol.
Cuando la empresa tiene un cierto tamaño, la ejecución y el delivery suele ser responsabilidad del VP of Engineering. Eso permite al CTO centrarse en ser una persona del negocio en primer lugar y un tecnólogo en segundo. El ceder la porción de “gerente de operaciones” al VP de Ingeniería permite al CTO estar más alineado con el resto del C-level. En ese momento, el primer equipo del CTO son el resto de los CXOs, convirtiéndose el equipo de ingeniería en el segundo.
Evolución del rol con el desarrollo de la industria tech
“CTOs are being stretched in completely new ways. They are expected to be more flexible and better informed on the latest trends and technologies, while also being a business-savvy visionary capable of bringing the company along a transformation journey. The best CTOs are achieving greater strategic and ‘front-to-back’ impact, creating or enabling new revenue streams, simplifying ways of working, and increasing resilience and reducing risk.” — Tristan Jervis
A medida que la industria de la tecnología continúa creciendo, la función del CTO actual está madurando para supervisar—normalmente en grandes empresas—áreas como datos, seguridad, privacidad e IT. No es raro que el CTO asuma los roles de Director de Datos (CDO), Director de Seguridad de la Información (CISO) o Director de Sistemas de Información (CIO).
En startups, no es raro (aunque no sé si recomendable) que el CTO asuma también la responsabilidad de producto y actúe también como CPO, al menos en las primeras fases.
Veamos ahora qué opinan nuestros expertos.
El CTO según Javi Santana (Tinybird)
Con los CTOs—y en general con cualquier CXO—lo complicado es que necesitas uno diferente para cada fase de la empresa.
Cuando arrancas, necesitas alguien todo terreno, que sea capaz de programar, entender producto etc. La mayoría de empresas lo llaman CTO pero en realidad no es más que un desarrollador con sentido común y capacidad de entregar y negociar con perfiles de negocio para no plantear castillos en el aire.
A medida que la empresa crece, necesitas alguien con una mezcla de técnico, recruiter, gestor y ciudador de patio de colegio. En esta fase es cuando a los perfiles técnicos se les suele olvidar que la tecnología es un medio y no un fin. (Bueno, para ser justos, se nos olvida siempre). La mezcla de cualidades aquí es muy interesante:
Por un lado tienes que ser capaz de definir procesos para hacer delivery y mantenimiento. Y repetirlo hasta la saciedad. Aunque lo habitual es que el foco siempre sea el delivery, la realidad es que el mantenimiento del producto sano es el 80%, especialmente en B2B. Por poner un símil, si tu producto crece en base a anabolizantes/esteroides en vez de en base a una alimentación sana y ejercicio (con sus fases de entrenamiento duro, claro) terminas teniendo algo desproporcionado y enfermo.
Ser capaz de tomar decisiones tecnológicas con el negocio y sus limitaciones en mente. Está muy bien leerse el blogpost de algún ingeniero de Uber (que incluso tienen KPIs para incentivarles a escribir blogposts de este tipo) e implementar una versión mala, pero mejor está pensar por uno mismo, ser capaz de influir al equipo e implementarlo con lo que tienes, que habitualmente no es un equipo como el de Uber.
Mantener el contacto con soporte, ventas y marketing, y que éste no sea unidireccional, es decir, que el equipo técnico y de producto no estén al servicio de otros departamentos. En una empresa o todos colocan las piezas del tetris o al final el equipo de producto/tecnología termina siendo el cuello de botella por una falta de estrategia general. Es fundamental que 1) el CTO esté en el equipo ejecutivo 2) tenga unos KPIs y métricas que expliquen bien la situación a gente no técnica y 3) tenga sus propias métricas y roadmap (y explicarlo adecuadamente, claro)
Ser capaz de hacer recruiting con el equipo en mente, y no perfiles individuales.
Saber gestionar personas: hay que empujar al equipo cuando toca, hay semanas malas, hay momentos que toca apretar o hacer cosas con la calidad que no toca, gestionar presión y saber encauzar las diferentes vertientes tecnologicas de cada uno.
En fases posteriores, por lo menos en B2B, el CTO empieza a ser un comodín de ventas y es el que está para apagar los fuegos :)
Los fallos más típicos relacionados con el puesto de CTO:
Dejarte influir por el "tú ya no tienes que programar". Es obvio que tienes que quitarte del camino crítico, pero cada uno tiene su estilo e influye y toma decisiones como quiere. Programar es, de largo, la mejor forma de eliminar "unknows unknows". Yo desconfío de CTOs que no saben programar.
Pensar que poner tecnologías una detrás de otra es hacer tecnología. He visto cosas que no creeríais, empresas con 3 programadores usando 40 servicios de Amazon (y buscando VP Eng.), siguiendo patrones de empresas varios millones de veces más grandes. Es como si contratas a un arquitecto de rascacielos para hacer la caseta del jardín, literalmente.
Pensar que producto y tecnología no son la misma cosa.
No saber dar un paso a un lado cuando tu fase ha terminado (o ser capaz de reconvertirte). En Tinybird ni soy CTO ni tengo ningún puesto CXO, tengo claro que soy útil en una primera fase, mucho menos en las siguientes, donde hay gente que va a hacerlo mucho mejor que yo. Creo que este fue uno de mis errores en CARTO.
Contratar un CTO en fase preseed/MVP. Necesitas a alguien que tire del carro, no un CTO.
Pensar que para el puesto del CTO tienes que poner al mejor técnico. Necesitas un mix de “caraboli”1 y “manzanillo”2, esto es, de tecnología y saber hablar con gente y explicar las cosas a alto nivel.
Mis referentes en el rol de CTO son:
Por tener opiniones fuertes y mostrar liderazgo técnico: DHH y Charity Majors
Adam Wiggins, por su laboratorio de investigación inkandswitch
Bryan Cantryl, por su trayectoria
Evan Wallace, (Figma) porque creo que ha sentado el principio de lo que debería ser en mundo web real time
El CTO y el VP of Engineering según Felipe Talavera (Flywire)
Definir el CTO ideal es muy complicado. Es un rol que se cubre de muchas maneras distintas y que cambia mucho dependiendo de a lo que se dedique la empresa, la etapa y su cultura. Hay empresas que necesitan perfiles más visionarios, si están redefiniendo una industria, o más técnicos, si van a solucionar problemas muy complejos o que lleven la tecnología al límite, o más gestores, si están ya en una fase de escalado haciendo adquisiciones como locos.
Si se trata de una empresa de tecnología/producto, creo que es fundamental que esté entre los fundadores o que se contrate la figura bastante pronto, para que pueda definir y liderar una estrategia desde el principio y se cree un cultura adecuada para los tecnólogos desde el principio.
El CTO no tiene porque ser el mejor técnico del equipo ni saberlo todo. De hecho, lo más normal es que no tenga tiempo de estar ni en todo el detalle técnico ni muy metido en el día a día. Eso sí: tiene que tener un background en construcción de tecnología y diseño de procesos para entender en profundidad el impacto de sus decisiones.
A todos los efectos se tiene que entender que es una posición ejecutiva y de gestión, por lo que los soft skills tienen mucho peso.
El CTO debe entender el negocio y moldear la estrategia de la empresa para que la tecnología se integre de manera correcta y eso va a implicar que tenga mucha flexibilidad para ir adaptando su rol a lo que la empresa necesita cada momento. Habrá veces que lo más importante sea trabajar en mejorar la retención del equipo, o entender el negocio para poder plantear una arquitectura u otra. Otras, hacer due diligence para una adquisición, ayudar en la contratación de perfiles senior, preparar los presupuestos para ver la contratación del año próximo, o salir a ayudar a cerrar un cliente con ventas. Incluso presentar en la reunión del consejo a inversores. Por todo ello, se requiere mucha capacidad de adaptación, de aprender rápido y facilidad para colaborar con gente de otros departamentos.
El VP of Engineering (VPE) es el encargado de asegurarse “que los trenes lleguen siempre puntuales a su destino”. Debe ser capaz de desbloquear cualquier problema que surja. Es un rol que se suele hacer más necesario cuando el CTO no llega a todo, generalmente cuando los equipos empiezan a aumentar de tamaño y hay que estandarizar procesos y metodologías de trabajo. Suele enfocarse tanto a la contratación y gestión del equipo, como a la creación y evolución de la estructura organizativa necesaria que va a permitir un crecimiento sano perdiendo la mínima productividad. Sin olvidarse, claro, de la gestión de cualquier riesgo o problemática que pueda surgir en la construcción y entrega del producto o servicio.
Otro rol importante a tener desde muy temprano es el CPO. Al igual que el CTO, depende del tipo de empresa, pero tener un perfil encargado de orquestar las necesidades internas de los diferentes equipos, e identificar y priorizar los problemas a solucionar de los clientes es fundamental para crear un buena cultura de construcción desde el principio y poder escalar posteriormente. A nosotros en Flywire fue una de las claves que nos permitió mantener el foco claro durante los primeros años.
Un buen libro para profundizar y entender las diferencia entre los distintos roles de gestión en la parte de ingeniería es el de The Manager's Path, de Camille Fournier.
El CTO según Angélica Lozano (MLEAN)
Creo que no es posible definir un CTO ideal en valor absoluto (igual que cualquier otro CxO), porque depende enormemente tanto de la empresa de la que forma parte, como del momento histórico de la misma. No es lo mismo un CTO de una empresa en la que el core del negocio es tecnológico (i.e. que venda tecnología), que una compañía en la que la tecnología sea un mal necesario para poder operar. Y no es lo mismo un equipo de 3-5 personas que hacen lo que haga falta, que un equipo de 50 con perfiles especializados.
Un primer momento de la empresa requiere un enfoque más hands-on, en el que las hard-skills (programación, automatización, calidad, devops, ...) son fundamentales, para dar paso a las soft-skills (comunicación, gestión de personas, resolución abstracta de problemas ...) conforme la empresa va creciendo. Creo que es un camino que es necesario recorrer, veo muy difícil saltar de otro perfil a CTO simplemente porque cumplas con las soft-skills. Es necesario tener un background técnico suficiente para que el equipo valore y respete tus opiniones como tal.
En cualquier caso, diría que el papel de CTO debería encargarse de:
Definir y evolucionar la marca tecnológica de la casa: qué tecnologías usar y por qué.
Definir y evolucionar los procesos del equipo de ingeniería: cómo usar la tecnología y por qué.
Definir y evolucionar la organización del equipo de ingeniería: grupos de trabajo e interacciones entre los miembros del equipo.
Traducir necesidades de negocio a soluciones técnicas: cuál es la mejor opción para convertir en realidad tangible los “deseos” de los equipos de ventas y producto.
Transmitir la visión de negocio al equipo de ingeniería: por qué es importante nuestro trabajo, cómo impacta en nuestros usuarios finales, en la monetización, por qué las prioridades son las que son en cada momento….
Traducir los esfuerzos técnicos a impacto en negocio: por qué no podemos asumir deuda técnica infinitamente, cuándo es necesario parar para revisar procesos, qué cosas no se pueden comprometer con cliente...
Transmitir el punto de vista de ingeniería al equipo de negocio: qué limitaciones tiene el producto actual, qué riesgos se van asumiendo conforme avanza el desarrollo, qué decisiones son limitantes o inhabilitantes de cara a opciones futuras...
Evitar la sobre-ingeniería: aunque pueda parecer contraintuitivo. Es fácil que el equipo de ingeniería caiga en el “onanismo tecnológico”. Por eso, creo que es función del CTO aterrizar lo que realmente necesita negocio, limitando la magnitud de las soluciones técnicas a lo imprescindible en cada momento histórico (con un ojo puesto en el siguiente salto, pero no más allá).
Contratar a los integrantes del equipo de ingeniería. A nivel individual en una primera fase (e.g. primeras 10-15 personas) y establecer un plan de crecimiento del equipo (número de personas, perfiles, roles, planes de crecimiento...) alineado con la estrategia general de la compañía más adelante.
Hacer la vida del equipo de ingeniería más fácil: asegurar que tienen una hoja de ruta clara y que pueden centrarse en su trabajo, sin interrupciones ni mensajes contradictorios o bandazos de prioridades.
Lo más relevante para mi es esa “función bisagra” o de traducción e interpretación entre negocio e ingeniería, aunque probablemente estoy sesgada por la realidad de MLEAN, en la que desempeño también de alguna manera el rol de Product Manager (en ausencia de otra persona específica que lo haga).
Intencionadamente no he incluido ningún ítem relacionado con ser el mega crack técnico del equipo. No creo que sea la función del CTO. Es más, entre sus funciones debe estar la de contratar gente mejor que él/ella.
Creo que es muy importante para una persona que quiera desempeñar este rol estar preparado para trabajar en entornos de alta incertidumbre. Es fundamental estar preparado para generar alternativas y resolver problemas. Tener un plan, pero estar listo para saltárselo.
Yo tengo siempre a mano este corte de Silicon Valley. Sé que en la serie se refería al rol de CEO, pero yo tiendo a sentirme así el 80% del tiempo:
Contratando
No tengo experiencia contratando CTOs, pero estoy plenamente de acuerdo con la tendencia a “guardarse las Cs” para cuando sea necesario. Si el CTO no es fundador (es decir, hay que contratarlo), no creo que se deba atribuir ese título al primer desarrollador que se une al barco.
En función del tipo de empresa, si tu core es tecnológico, lo lógico es que forme parte del equipo fundador.
Si tu core no es tecnológico, pero tu negocio depende de la tecnología para tener éxito, necesitarás un líder técnico desde el primer día, pero probablemente no será necesario un CTO hasta que el equipo empiece a crecer (e.g. 10 personas) y/o la empresa empiece a tener tracción (número de usuarios creciente, número de clientes creciente, complejidad organizativa interna creciente...).
En caso de valorar un CTO externo, siempre debe estar apoyado por un rol de líder técnico interno, con vocación de desarrollar ese papel en la casa eventualmente (aunque se mantenga algún tipo de coaching futuro). No lo veo como una solución a largo plazo.
Consejos: haz
Toma decisiones basadas en datos (no en impresiones personales o corazonadas).
Ten unos KPIs alineados con los de la empresa.
Trabaja en equipo. Siempre. Cualquiera de los puntos de la primera lista no pueden decidirse unilateralmente.
Aplica fases “convergentes y divergentes”. Primero ayuda a tu equipo a centrarse para ser lo más eficaz y eficiente posible en su día a día. Una vez conseguido, propón el siguiente reto (organizativo, técnico, de escalado...) que descoloque alguna de las piezas, para volver a centrarse en la eficacia/eficiencia en el nuevo escenario.
Consejos: no hagas
No seas un cuello de botella. Que ciertas decisiones sólo dependan de ti, o que sólo tú sepas hacer ciertas cosas, o que sólo tú tengas acceso o permisos para desbloquear ciertos procesos es un síntoma de egoísmo contraproducente. Estás impidiendo que el equipo crezca, y lo peor de todo: no podrás desconectar ni en vacaciones.
Cómo aprender
Recurriendo a la comunidad, escuchando muchísimas experiencias de diferentes CTOs en distintos tipos de empresa. Cogiendo ideas de todas partes, pero con la certeza de que ninguna aplicará tal cual a tu caso y debes adaptarla.
Creo que lo más difícil del rol está relacionado con la gestión de personas (equipo, fundadores, inversores, clientes, auditores...) y eso normalmente no se aprende en ningún “curso reglado”, sino que es fruto de la vivencia propia y el intercambio de experiencias.
En mi caso (pero esto es una opinión personalísima) prefiero los ejemplos nacionales a los grandes referentes internacionales. Me resulta mucho más fácil empatizar y me veo más reflejada en sus vivencias (contexto cultural, económico, financiero, social…), por lo que es más probable que encuentre ideas fácilmente extrapolables a mi caso.
Algunos ejemplos: Chema Roldán, Felipe Talavera, Miguel Carranza, Sergio Gago, Javi Santana 😬
Otros: Carlos Buenosvinos, Elisenda Bou, Pau Ramón.
La semana que viene continuamos con las visiones de Miguel Carranza, Chema Roldán y Sergio Gago. ¡No os lo perdáis!
Gracias por leer Suma Positiva.
Si te ha gustado esta edición, no te olvides de dar al ❤️ y de compartirla por email o redes sociales con otras personas a las que les pueda gustar.
Si quieres patrocinar una próxima edición, aquí tienes toda la información.
Técnico
Los que dicen “sinergia” 😆
Gracias Samuel, como siempre muy bien documentado y escrito. Podrías trazar un breve paralelismo del CTO que defines con lo que se necesita en las empresas establecidas? Aunque fueran unos pocos tips...