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.

Subscribe now

Esta semana vamos a continuar con la exploración del rol del CTO o responsable tecnológico de la startup que iniciamos la semana pasada, en la que, además de daros mi visión, compartí las de Javi Santana (Tinybird), Felipe Talavera (Flywire) y Angélica Lozano (MLEAN).

Hoy es el turno de leer a Miguel Carranza (RevenueCat) Sergio Gago (Moody’s) y Chema Roldán (Genially).

¡Disfrutad!

Esta edición de Suma Positiva ha sido patrocinada por:

Bitpanda es uno de los neobrokers más grandes de Europa y busca hacer accesible la inversión a todos. Desde su web y app puedes comprar desde 1 solo euro: 70 criptomonedas, más de 80 acciones fraccionadas las 24 horas de las empresas más importantes del mundo, metales como el oro y ETF. Se fundó en Austria en 2014 como exchange de criptomonedas y en 2021 ya cuenta con más de 3 millones de usuarios en toda Europa. Es una plataforma de inversión "todo en uno". También cuenta con su propia tarjeta de débito Visa, aceptada en todo el mundo con la que puedes pagar con cualquier activo de la plataforma (cripto, acciones, metales, ETF).
¿Por qué es diferente Bitpanda ? Cumple con todas las normativas europeas como la PSD2, MiFiD II y AML5 y respalda todos sus activos: cripto, acciones, e incluso los metales. Además, ofrece servicios y productos adicionales pensados para inversores que piensan en el largo plazo: Plan de Ahorro, que permite programar compras automáticas de cualquier activo de forma periódica (cada semana, quincena o mes) y Cripto Índices, que consisten en cestas de las 5, 10 o 25 cripto más importantes del momento. Cada mes se reajusta la composición de cada cesta según el mercado.
Regístrate gratis ahora y entérate de todas sus novedades desde Instagram y Twitter.

❤️ ¿Quieres patrocinar Suma Positiva? Toda la información aquí.

Arquitectura + Cine. Un Chispazo Ideológico / Andrés Angelero | arquitectura celeste

El CTO: el Arquitecto (2)

Miguel Carranza (RevenueCat)

Definir las responsabilidades del CTO perfecto es una tarea altamente compleja. Tras hablar con varios CTOs de compañías en diferentes etapas, una cosa me quedó clara: es un rol que está muy mal definido. Depende mucho de la etapa y del tipo de empresa, así como de si el cargo lo ejerce un fundador o si el CTO es un profesional contratado posteriormente. Existen una gran variedad de perfiles. Además, algunas veces la línea entre CTO y VP de Ingeniería (en inglés, VPE o VP of Engineering) es muy delgada. A medida que la empresa crece y las necesidades de la startup cambian, el rol va evolucionando. Esto puede ocurrir con una alta frecuencia (de 3 a 6 meses).

Algunas de las responsabilidades típicas que puede acabar teniendo un CTO son:

Gestionar y escalar el equipo técnico y sus procesos.
Gestionar un pequeño grupo de ingenieros con mucha experiencia (office of the CTO), dedicados a evaluar nuevas tecnologías y prototipado de futuros productos.
Ayudar a diferentes equipos resolviendo los problemas técnicos más complejos o contribuyendo en la arquitectura, ya que el CTO suele ser la persona con mayor contexto (tanto de negocio como técnico).
Incluso algunos tienen un puesto mucho más externo, dedicándose a tareas de ventas, marketing y, en definitiva, convirtiéndose en la imagen pública del equipo técnico.

Si el CTO es uno de los fundadores, generalmente suele acabar centrándose en lo que más le gusta o en aquello que pueda aportar más valor a la compañía. No obstante, en las primeras fases, no es extraño que realice o todas o un subconjunto de las tareas anteriormente mencionadas.

Además, en los inicios, yo diría que el CTO tiene como misión:

Sentar las bases de la cultura de ingeniería de la empresa.
Seleccionar las tecnologías adecuadas para el desarrollo del producto mínimo viable.
Ser capaz de inspirar, convencer y contratar a los 5-10 primeros ingenieros.
Gestionar la deuda técnica, balanceando por un lado la rapidez de desarrollo, y la escalabilidad y mantenimiento por el otro.

Para poder llevar a cabo estas tareas un CTO ideal debería tener las siguientes habilidades:

Dependiendo del producto, ser un excelente ingeniero generalista o un experto en el área técnica concreta de la empresa (domain). Idealmente, se cumplen ambos requisitos.
Ser un reclutador sobresaliente. Tener la capacidad de inspirar, convencer y liderar a ingenieros y managers que potencialmente tienen más nivel y experiencia que el mismo CTO.
Pragmatismo y adaptabilidad. En las etapas iniciales, el tiempo es el mayor enemigo. La capacidad de elegir la solución adecuada para cada etapa y no optimizar prematuramente es fundamental.
Conocimiento del negocio y empatía con los usuarios. Si no se solucionan los problemas de los clientes de manera óptima, la startup tendrá poco futuro.
Mínimas bases de gestión de proyectos, equipos y personas.
Curiosidad y pasión por la tecnología.

Si además el CTO es fundador, añadiría que una cualidad fundamental es la humildad. En muchos casos, la startup escalará más rápido de lo que podrá hacer el propio fundador. En estos casos es primordial saber reconocer cuales son sus limitaciones y buscar ayuda externa.

Contratarlo, cuándo

Aquí obviamente estoy altamente sesgado por mi carrera y experiencia en Silicon Valley. Pero, en mi opinión, el CTO de una startup con base tecnológica fuerte debería estar ahí desde el principio. Es más, creo que debería ser parte del equipo fundador. La razón fundamental es que si el producto que se está construyendo es innovador, es indispensable que la persona que toma las decisiones técnicas iniciales tenga un compromiso total a largo plazo. Además, llegar al product-market fit no es una tarea sencilla, por lo que disponer de alguien dentro de casa que sea capaz de iterar en el producto, puede resultar acabando mucho más económico. Finalmente, creo que siempre tiene mucha más fuerza que la tecnología sea desarrollada internamente a la hora de contratar a los mejores ingenieros. Contratar a los buenos es una tarea complicadísima y los buenos quieren trabajar con los mejores, resolviendo retos complejos.

Creo que contemplaría dos excepciones. La primera es cuando el negocio o producto no es puramente técnico (como podría ser un e-commerce, o algo enfocado en contenido y no puramente en la tecnología). La otra es cuando el fundador técnico no tiene la experiencia o las ganas de liderar el equipo, y prefiere mantenerse como ingeniero (IC, individual contributor).

Otra pregunta interesante relacionada con este último punto es si debería darse el título de CTO al fundador técnico si este no dispone de las habilidades o experiencia. Creo que la respuesta es más compleja y depende de varios factores. Hay beneficios de que exista la figura del CTO, ya que ayuda a asignar la responsabilidad última de las decisiones técnicas a una persona. Además, muchos clientes iniciales quieren hablar con alguien técnico en el equipo ejecutivo. Sin embargo, esto puede tener efectos muy negativos si el fundador no puede escalar suficientemente rápido y su ego no le permite pedir ayuda, delegar o buscar un reemplazo con más y mejor experiencia en el momento que más lo necesite la startup.

Consejos: Haz

Establece relaciones con otros CTOs en fases anteriores, similares y posteriores, creando una pequeña comunidad. Los inversores pueden ayudar con presentaciones.
Nunca pares de atraer y contratar a gente mejor que tú que te inspiren a crecer. Mejores managers, mejores técnicos, etc.
Ten buenas relaciones con el resto del equipo ejecutivo. Busca su apoyo, y cuando llegue el momento, encuentra a un VP de Ingeniería que te complemente y se convierta en tu mayor aliado en la organización.
Reevalúa constantemente lo que está empezando a fallar o puede fallar pronto, sobre todo después del product-market fit.
Identifica líderes naturales en el equipo técnico y ayúdalos a crecer. A medida que evolucione tu rol como CTO, delega las viejas responsabilidades. Busca continuamente tu reemplazo, ya sea interna o externamente.

Consejos: No hagas

No asumas que lo que ha funcionado para llegar de 0 a 1, seguirá funcionando en la siguiente etapa.
No tomes decisiones técnicas basadas en modas. Hay que estar al día, pero es necesario andar con cautela. La mayoría de las veces, las tecnologías probadas pero más aburridas tienen mayor soporte y comunidad.
No optimices prematuramente. Algunos problemas sólo existen en tu cabeza. Puede que incluso haya que desechar esa funcionalidad, producto, o proceso.
No tengas tu visión centrada únicamente en el ahora. Piensa constantemente en cómo evolucionará la organización y la tecnología en los próximos 18-24 meses.
No hagas más cosas de las que debes durante demasiado tiempo.
No ignores señales de regresión en nivel o cultura de ingeniería. La cultura tarda años en solidificarse, pero puede destrozarse muy rápidamente al escalar rápido.

Cómo aprender: Recursos y referentes

Creo que el rol de CTO es difícil de aprender, sobre todo para los fundadores primerizos. Otros roles, como el del CEO, tienen mucha más bibliografía, ejemplos y apoyo de inversores y consejeros. La mayoría de las lecciones se aprenden a base de errores pero creo que algunas cosas pueden ayudar a minimizarlos:

Si tienes la oportunidad, antes de emprender, trabaja en una startup en etapa temprana, reportando directamente a un CTO al que respetes.
Busca una red de apoyo en otros CTOs con los que compartir problemas transparentemente y con confianza.
Ofrece a CTOs que admires ser business angels en la empresa. La mayoría de los inversores no tiene un background técnico, pero muchos CTOs de éxito estarán felices de invertir, ayudar, y la posibilidad de tener skin in the game.
Contrata un VP de Ingeniería que te complemente y que ya disponga de la experiencia
Sé consciente de tus limitaciones. Llegado el momento, céntrate en lo que más impacto genera en la empresa y delega el resto.

Libros:

Referentes y recursos:

Developing Leadership (Jason Warner, VPE Heroku / CTO Github / Managing Director Redpoint VC )
The CTO Journey at a Small Startup (Bryan Helmig, Zapier)
Office of the CTO Playbook with Auth0 (Matias Woloski, Auth0)
#define CTO (Greg Brockman, Stripe)
How my role as CTO has changed as we've grown to 100 engineers (Edward Kim, Gusto)
Your first 90 days as CTO or VPE (Will Larson, Uber/Stripe/Calm)
What makes a bad CTO (Jason Lemkin)
Charity Majors (Honeycomb)
Evolution of my role as a founder CTO (un servidor)

Sergio Gago (Moody’s)

Responsabilidades

El CTO transforma necesidades de negocio en un producto, definido por un CPO que trabaja al lado, encima o debajo. Puede ser la misma persona, pero entonces tiene que tener una habilidad abismal para cambiar de sombrero, hasta el punto de ser bipolar. Nunca fue bueno tener un juez Dredd suelto por el mundo.

Pero, sobre todo, el CTO es un “C”. Hasta el punto de tener 25-30 ingenieros no eres CTO. Eres un tech lead, o un engineering manager. Pero realmente no eres un CTO como tal. Porque el CTO está más tiempo hablando hacia afuera que hacia adentro. Vende a su equipo y luego vende al equipo. Les compra cosas y vende lo que fabrican.

Por otro lado, hay tantas definiciones de CTOs como empresas en el planeta :) Por tanto tiene que ser una persona tremendamente flexible y adaptable. Tiene que saber de tecnología; mucho. Pero no tiene que ser el mejor programador de la sala (de hecho eso suele ser un red flag). Tiene que saber de finanzas, de producto, de marketing, de ventas… y empatizar con todos ellos. Tener capacidad de tener el foco en sí mismo y en su equipo pero a la vez ser flexible. Tiene que estar enamorado de la experimentación y de las nuevas tecnologías pero ser realista y buscar la aplicabilidad, mantenibilidad y gobernabilidad de los sistemas.

Vendemos agile como la forma de pilotar rápido y adaptarnos al mercado… pero luego estamos todo el rato diciendo que no y creando equipos de tecnología inflexibles.

El CTO entiende que la deuda técnica es más deuda que técnica y que empieza por el CFO.

Fases

Para mi hay 4 fases de CTOs, muy diferenciadas y que son claves tanto en la búsqueda como en los perfiles como a la hora de diferenciar en qué te pueden ayudar

Lidera equipos pequeños. Conoce el oficio técnico y, hasta cierto punto, es hands-on.
Lidera un equipo mucho más grande en el que ser práctico o incluso tomar decisiones directas sobre el código o la arquitectura es un sueño. Tu trabajo es capacitar a su equipo para que las tome. Es decir: eres un gerente de gerentes.
Tiene un asiento en el consejo. Hablas con inversores y eres un componente clave de la estrategia de la empresa. Hablas el lenguaje de los negocios.
Es una parte esencial del consejo y de los socios. Participas activamente (o incluso lideras) procesos de fusiones y adquisiciones, rondas de financiación, etc.

Habilidades

El CTO se dedica a una cosa: a hablar. Por voz, por chat, por email, por señas, por gestos y por slides (y por excel). Se dedica a comunicar. Por tanto, sus soft skills tienen que ser superiores. Si viene de tecnología—como creo que debería de ser—, llevará varios años de transformación; Desde que uno entra en la fase de tech lead va pilotando sus hard skills hacia las soft. Va saliendo de la trinchera para montarse en el helicóptero. Se va quitando los cascos y el “entrar en flow” para captar señales solo andando por el pasillo (o el equivalente, participando en los canales de slack generales de la compañía, o entrando en huddles rápidos).

Tiene que tener una gran capacidad para asimilar conceptos rápido, entender riesgos y tomar decisiones en entornos de alta incertidumbre. Parar debates interminables (debates eternos entre Kubernetes vs Serverless con arquitectos y senior developers), porque entiende que lo que importa no es tanto la decisión, sino el arrastrar, convencer y motivar al equipo después.

Tiene que tener ownership: Conocer lo que ocurre, procesarlo y explicarlo en el lenguaje de quien lo tiene que escuchar y defender a su equipo.

Contratando

¿Empresas de base pura tecnológica y de innovación? Desde el principio. ¿Qué es una base de innovación? Donde la propuesta única de valor está en la tecnología. Si vas a requerir infinitas iteraciones porque estás buscando el PMF: interno.

La cuestión no es en qué fase contratar, sino qué perfil. NUNCA contrates a un hardcore / rockstar developer como cofounder / CTO inicial. Porque querrá construir algo increíble, resiliente y a prueba de bombas. Salvo que probablemente no te ataquen con bombas sino con gas mostaza. En muchos casos necesitas construir algo sin saber lo que quieres. Por lo que salvo que estés montando un modelo comercial sobre una tecnología muy concreta (crypto, AI, quantum…) es muy probable que no necesites un CTO. Un developer junior, alguien que controle de no-code y de integraciones y que entienda de negocio queriendo mojarse puede ser muy productivo. Mejor eso que una macro estructura en Kubernetes o serverless que solo va a entender él/ella.

Cuando tu equipo técnico crezca y necesites 5+ personas, tu CTO se va pareciendo más a un tech lead y alguien tiene que traducir el idioma del CEO al idioma de Product & Tech. Cuando tu equipo crezca en > 10 personas, tu CTO se parecerá más a un engineering manager. Con más de 20 personas será un Director de Ingeniería. Con más de 50 personas ya tendrás a un CTO. Y por supuesto no se dedicará a programar.

Sobre el CTO externo

El CTO externo es útil cuándo:

Necesitas ayudar a tu equipo técnico con cosas que no saben hacer. Normalmente en organización y comunicación.
Necesitas auditar el trabajo que están haciendo
Un tercero necesita auditar el trabajo que están haciendo (e.g. en una due diligence). O preparar de antemano la DD.
Cuando un inversor te lo coloca para evaluar lo que estás haciendo. Sobre todo cuando la tecnología no está respondiendo adecuadamente.
Cuando vas a comprar una empresa y necesitas tener un proceso.
Cuando tienes un problema muy gordo y no sabes cómo arreglarlo, ni confías en tu equipo.
Cuando tu CTO / Cofounder no es la persona adecuada para el estado actual de la compañía. Bien para reemplazarlo, o para mentorizarlo.
Cuando quieres contratar a un CTO y no sabes lo que quieres (o crees que lo sabes pero no) y no sabes evaluar.
Cuando necesitas aplicar procesos de governance, hacer despidos, controlar riesgos o realizar alguna auditoría legal tricky.

Consejos

El mayor error que cometen muchos CTOs primerizos es pensar que es un rol técnico. O que es el siguiente nivel en el progreso de carrera tecnológica. Y está muy lejos de esto. El equipo del CTO son los otros C’s. Y su support, su familia, es el equipo de ingeniería. Es fundamental tener rapport con ellos. Saber de ingeniería, haber programado, entender los riesgos y poder tomar decisiones con muy poca información y mucha incertidumbre. Pero el CTO es al final un “inversor”. Inviertes el tiempo de tu equipo (que tiende a ser el más caro de la empresa). Generas activos y generas deuda (técnica). Una buena coordinación puede tener una máquina bien engrasada o un auténtico desbarajuste productivo.

Lidiar entre medidas de corto plazo y de largo plazo.

El CTO HABLA con la gente (y generalmente sólo hace eso) y hace las preguntas adecuadas. Debes ser un router de información: muchos inputs te dan datos, los procesas y los envías a quien toca, cuando toca, y de la manera que toca. Pero no un firewall (que en muchas ocasiones ocurre).

El CTO y el CPO deben ser uña y carne. Personalmente no me gusta que sean la misma persona, pero deben ser aliados frente al CEO o al board cuando las cosas se vuelven locas. Igual que el CFO es el mapa, el tándem CPO-CTO es el vehículo que lo recorre y debe ser adecuado al terreno (¿queremos una vespa, un lambo o un camión?)

Cómo aprender

Para formarse lamentablemente no hay muchas opciones o recursos. La única manera es aprender de tu jefe (lo bueno y lo no tan bueno). Pero hasta ahora no hay formación dedicada exclusivamente a CTOs (¡o no la había! Ahora estamos lanzando esto: https://barcelonatechnologyschool.com/executive/executive-master-in-digital-technology-management/) También hay otros programas con otro enfoque como el CTO Bootcamp que están bien.

Un MBA puede ayudar al CTO a tener un enfoque más global y conseguir el conocimiento de marketing, finanzas y en general el “business acumen” necesario. ¿Cómo te plantas delante de una junta de accionistas y les explicas el plan de ciberseguridad?

Es fundamental formarse en comunicación y persuasión. O bien con libros, workshops o formación ejecutiva. Recordemos: el CTO es un ejecutivo, no un geek techie encerrado en el garaje. Eso no significa que nos tengamos que poner traje y corbata, sino que nuestro trabajo va mucho más allá de la arquitectura. De hecho muchas veces necesitamos a un VP de Ingeniería para llevar el día a día de lo que ocurre.

Chema Roldán (Genially)

Muchas veces se habla del CTO ideal y creo que el enfoque en sí de este tema está mal. En mi opinión, se tiene que buscar al CTO ideal… pero para tu compañía. Por mucho que nos pese y leamos a otros CTOs de otras compañías sus consejos o metodologías, ni tenemos el mismo equipo, ni tenemos el mismo producto ni tenemos los mismos retos o problemas que resolver. Además que no tiene nada que ver lo que hace un CTO en las primeras fases cuando son 6 personas en la compañía a cuando solo tu equipo de tecnología son 40 personas.

Si tenemos que hablar de responsabilidades, en mi caso, debería mencionar algunas de las tareas más importantes que tengo en mi día a día.

La primera de todas sería la de no ser un stopper a la hora de entregar valor tan pronto como sea posible en el producto. Preparar todos los canales posibles para que algo llegue a producción ASAP y si esto no se puede hacer buscar soluciones a nivel de compañía para dar con la tecla. Detectar y levantar la mano, debe ser responsabilidad del CTO.

Otra de las cosas que deberíamos de tener en cuenta en un CTO es que es una persona que debe dar contexto. Si es un caso como en el mío, que soy el empleado número uno y cofundador de la compañía, eres por decirlo de alguna manera, el único que es capaz de entender y explicar qué ha pasado en tu producto a nivel tecnológico para llegar hasta dónde estás.

Es importante que un CTO sepa transmitir al equipo que lo que están haciendo va a impactar en algunas de las métricas que se trabajan en la compañía. Es mucho más fácil que las personas desarrollen su trabajo si entienden el objetivo final del mismo. En nuestro caso lo solemos explicar de una forma sencilla; por ejemplo, intento explicar que esta tarea va a mejorar, la conversión de usuarios de pago, la retención, la adquisición o el engagement.

Además, un CTO tiene que tener la habilidad de saber decidir qué tareas internas se deben llevar a cabo dentro del departamento y que no afectan directamente a la compañía o producto. Ésta es una de las habilidades más importantes y difíciles de llevar a cabo. Hay que tener en cuenta que el ritmo de desarrollo en las fases iniciales es frenético y no siempre puedes abordar todos los problemas de la forma correcta y se genera deuda técnica. Saber qué abordar y cuándo, sin perjudicar el ritmo en fases posteriores cuando los equipos son grandes, es una tarea que cualquier CTO debe saber abordar y organizar, y que si se equivoca, probablemente tenga consecuencias negativas por el coste de oportunidad que implica.

Si hablamos de habilidades, un CTO debe ser un motivador tecnológico. Debe dar impulso al equipo para motivarlos en hacer las cosas bien, que aunque parezca fácil, a veces no lo es tanto porque tienes que poner en la balanza lo que es hacerlo bien sin añadir una sobre-ingeniería o hacerlo rápido. Todo el mundo quiere hacer lo que hacen las grandes compañías en sus megapost sobre cómo gestionan 3 millones de peticiones por segundo, pero el equipo tiene que entender el problema que tienes que resolver y en qué fase estás. Aunque esto no suele gustar, suele funcionar bien explicar a tu equipo que el objetivo de una empresa es ganar dinero.

Tiene que saber encontrar qué miembros del equipo encajan mejor en qué tareas para que estén lo más motivados posibles. Debe de ser una persona accesible y muy empática. Esto me lo ha demostrado mis años de consultoría. Cada vez que entraba en un proyecto dónde tenía que pasar de un negocio dónde se vendían coches a otro dónde se vendían seguros, me sentía un auténtico imbécil por lo que tardaba en entender todos los procesos funcionales y memorizar los acrónimos de cada compañía. Tienes que recordar que tú has sido junior, que has metido la pata, que has tirado producción por mucho esfuerzo y cariño que has puesto a tu trabajo y eso mismo se lo tienes que trasladar al equipo para darle la confianza necesaria a todos y cada uno de ellos.

Por último y no menos importante, también es importante saber delegar. No puedes ser como CTO mejor que todos en todo. Imposible. Delega, deja que se equivoquen, que se comprometan con las soluciones que aportan y recompensa si se hacen bien. Y si no lo hacen bien, ayuda a entender y comprender cómo mejorar para que la próxima vez sea un éxito y no un fracaso. El famoso post-mortem es muy importante y hace crecer mucho de forma individual y como equipo.

Contratando

Genially no hubiera salido nunca al mercado si no hubiera habido un socio fundador que fuera un socio tecnológico. Imposible. Creo que en startups es muy importante que desde el día 1 esa figura, que ni siquiera es un CTO, es un ente tecnológico capaz de lidiar con X problemas inimaginables y de toda índole sea miembro del equipo fundador. No digo que para nada sea garantía de éxito, pero sí ayuda mucho.

Si no dispones de las habilidades necesarias una vez sales de esa fase alpha dónde ya has validado tu producto con el mercado, busca a las personas adecuadas que te complementen para poder seguir creciendo, y más importante aún, hacer crecer a la empresa.

Si además eres un CTO que también es cofundador de la compañía no tengas miedo y deja el orgullo de lado para que te sustituya otra persona que lo va a hacer mejor que tu. Sinceramente, esto es importante porque puede llegar a frenar a la compañía. Mi visión es clara, si hay una persona que puede hacer crecer y dirigir la empresa mejor que yo a nivel tecnológico, no tengo ningún problema en darle paso, al fin al cabo, si la empresa va mejor y aunque suene políticamente incorrecto, mis acciones valdrán más, es un win-to-win. Eso sí, y muy importante, cuando busques a otro que te sustituya, busca a uno que comparta los mismos valores y cultura que tu.

Algunos Consejos

Crea una cultura de equipo y una forma de hacer las cosas y ve iterando hasta que encuentres la mejor forma de hacer las cosas para tu compañía.

Lo que hagan otros CTOs en sus compañías no tiene porqué funcionar en la tuya. Si vas a aprender de otros, intenta enfocarte en un ámbito que sea similar al tuyo. Si haces SaaS, céntrate en leer sobre como otros SaaS han escalado, pero que no se te nuble la vista teniendo más microservicios que usuarios.

Entiende cómo funcionan las otras áreas de la compañía y ayúdales a entender que es mejor tener el 30% de algo en producción que el 100% de nada. De nada sirve tener una cultura interna de entrega continua si no estás alineado con las otras áreas.

Crea una marca tecnológica alrededor de tu compañía. Invierte tiempo en contar lo que haces y qué retos has superado y cuales te quedan por superar, esto te va a ayudar a encontrar talento más fácil.

Conoce todos los procedimientos que existen en tu departamento. No hace falta que conozcas el detalle de todos, pero sí que tengas un mapa mental de todas las piezas que están conectadas, si en algún momento esto no lo controlas, es señal de que algo puede ir mal.

Cuando el equipo crezca lo suficiente y ya no puedas tener un contacto personal con todos los miembros de tu equipo para conocer sus inquietudes, feedback, motivaciones, etc, busca a alguien que te ayude y crea un plan para cuidar (hablando en un contexto laboral) a las personas de tu equipo, al final sin ellas, tú no eres nadie.

Documenta todo lo que veas necesario pero sin perder el tiempo. Procesos de onboarding, puesta en marcha de los entornos, particularidades, herramientas internas, etc. Esto te va ahorrar mucho tiempo en el futuro. Pide feedback dos semanas después cada vez que entre una persona nueva al equipo para mejorar tus procesos.

Si no eres capaz de apagar el teléfono una semana y que tu departamento, o peor aún, la compañía no funcione bien sin ti, cuando ya sois más de 20 en tu departamento, tengo algo malo que decirte.

Escalando que es gerundio

El mayor reto de escalar cualquier solución tecnológica es acertar con el enfoque del problema. Los problemas suelen ser fáciles de resolver, pero cambia el paradigma cuando metemos en la ecuación un volumen X de usuarios o peticiones a tu sistema cuando este X tiende a crecer de forma exponencial.

Uno de los retos cuando estás escalando un sistema es no perder la velocidad de desarrollo y mantener el mismo ritmo que llevabas cuando estabas en las fases iniciales.

A las personas les suele costar entender el porqué eres más lento si tienes más desarrolladores en tu equipo. No se suele entender que estamos resolviendo problemas más complejos y que por ende tenemos que hacer cosas más complejas, y sorpresa, hacer cosas más complejas lleva más tiempo. Ya de por sí es un reto explicar y hacer entender que lo que haces tiene un porqué para el futuro de la compañía.

Algo tan sencillo como por ejemplo servir unos ficheros estáticos (eso que hace que una web normal funcione), cambia totalmente. Ahora tienes que crear unos procesos nuevos, que hagan que el proceso de integración continua los despliegue a un CDN para que vaya todo mejor independientemente de que accedan a tu web desde Madrid o desde Sao Paulo. Estos procesos hay que mantenerlos, actualizarlos y pueden fallar. El reto es que impacten lo menos posible en el crecimiento de la compañía.

Además, diseñar soluciones complejas requiere aprender e implementar cosas nuevas. A mi personalmente esto me encanta y es un reto continuo en nuestro día a día. Resolver problemas a los cuales nunca antes nos habíamos enfrentado.

Mejorar las latencias o tiempos de respuesta para una compañía como Genially, es uno de los retos dónde más trabajamos en el día a día y de cara al futuro. Como he dicho antes, nuestra herramienta debe funcionar bien sí o sí en muchísimos ámbitos, algunos son un dolor, como por ejemplo trabajar con conexiones lentas y que se caen constantemente como las de los colegios, con cientos de miles de usuarios accediendo a la vez desde diferentes partes del mundo y como es lógico, todo debe ir rápido y bien.

Además, para añadir más complejidad, nuestros contenidos son vivos, es decir, si un usuario hace un cambio a una presentación justo antes de un evento, ese cambio tiene que verse reflejado al momento. Esto te hace contextualizar tu problema de otra forma y añade otra capa de complejidad que normalmente no está.

Otro reto importante es la distribución de precios o planes a nivel global. Vender en Estados Unidos en euros os aseguro que funciona bastante mal. Distribuir esos planes de precios con herramientas o proveedores que no lo soportan de forma nativa fue un auténtico dolor de cabeza. Proveedores que no se entienden entre sí y que cuando generas un cupón descuento para por ejemplo el BlackFriday cambia totalmente. Es que es otro mundo. Muchos proveedores soportan descuentos de forma nativa, pero cuando mezclas a varios de ellos, y ojo, tienes que mezclarlos porque es lo mejor para tu negocio, porque obviamente no quieres cerrar la puerta a que alguien no pague porque sólo soportas tarjeta de crédito o sólo soportas PayPal.

Cuando recibes cientos de millones de peticiones se genera una cantidad de ruido en tu sistema de trazabilidad (o logs), que es todo un reto saber qué guardar y qué no, qué quieres cubrir, qué cosas son importantes para saber qué ha pasado cuando hay una incidencia.

Resumiendo. Cuando un equipo de desarrollo tiene que implementar un sistema de alto rendimiento, con pocas latencias, buenos tiempos de respuesta y distribuido a nivel global, todo cambia. El enfoque de los problemas cambia. Tienes que medir muchísimo más, cada consulta a base de datos debe tenerse en cuenta. Cada petición de más debe analizarse. Todo lo que se pueda cachear debe ser cacheado tan pronto como sea posible. Hemos hecho cambios a lo largo de nuestro desarrollo que han sido necesarios para la viabilidad del proyecto a largo plazo. Algunos muy radicales y con mucho impacto. El último reto que añadiría es hacer todo lo mencionado previamente sin que el usuario final se entere de absolutamente nada.

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.

Suma Positiva, por Samuel Gil

#99 El CTO: El Arquitecto (2)