[ACTUALIZACIÓN 2022] Cuando a uno le proponen llevar la dirección de un departamento de tecnología y tiene que llevar equipo, producto y operación tecnológica, uno siempre quiere ser el mejor CTO pero eso es un camino y en el camino se producen errores que van añadiendo experiencia a la mochila. En este artículo te explico errores que he visto cometer a CTOs desde la óptica de consultor externo y otros que he cometido yo mismo trabajando como CTO en una stratup.
Un error muy común es la selección de la tecnología de desarrollo del producto. Muchas veces se selecciona una tecnología en base a criterios relacionados con los intereses personales o profesionales del CTO. Por ejemplo, me he encontrado muchas veces con productos en producción que usan una tecnología que no da más de si y limita el crecimiento del producto. También es común encontrarse con CTOs que han seleccionada tecnologías tan puntera que no hay manera de encontrar developers con conocimientos de ellas.
La selección de la tecnología no puede basarse ni en la tendencia del momento ni en la tecnología que conozca el CTO aunque ambos criterios deberán tener peso en la decisión.
Según mi experiencia hay que encontrar una tecnología que esté suficientemente madura e implantada como para que haya recursos experimentados en el mercado, que sea fiable en producción y que tenga herramientas de desarrollo.
Eso no significa que no podamos escoger una tecnología puntera que nos ahorre tiempo de desarrollo o nos permita acceder a librerías específicas de nuestro sector, si el CTO es demasiado conservador en la selección de la tecnología podemos perder competitividad con nuestros competidores.
Por lo tanto, para evitar errores en la toma de decisión de la tecnología, es importante hacer hunting tecnológico tanto de mercado como de vertical para conocer sus tendencias y la madurez de las mismas. La clave del éxito será encontrar un buen balance entre inversión y capacidades que ofrece la tecnología.
Otra cosa con la que me he encontrado con frecuencia es la toma de decisiones erróneas por falta de estrategia. Esto puede ser porque la empresa usa un exceso de táctica para operar, o también porque a pesar de ser una empresa digital, el CEO tiene una visión más tradicional de IT y lo ve como un departamento independiente que desarrolla lo que le pide negocio.
Una roadmap con un buen nivel de detalle y alineado con los objetivos globales de la compañía suele ser una herramienta que permite seguir el hilo estratégico.
Aunque lo más normal es que, independientemente de la situación de la compañía, sea el propio CTO el que carezca de visión estratégica. Una de las responsabilidades clave de un CTO es comprender cuál es la estrategia de la compañía y alinear la estrategia tecnológica a las necesidades de la misma, pero sucede a veces que los CTOs se pierden en los propios retos que ofrece la tecnología perdiendo su foco principal.
Uno de los puntos que afecta a empresas digitales en su momento de startup es el uso de soluciones faraónicas. Muchas veces disparan la inversión del MVP sin haber validado la idea. Escoger soluciones sobre dimensionadas tecnológicamente no es una buena opción puesto que esta sobre dimensión representará un sobre coste en tiempo de producción y/o en tiempo de ejecución (infraestrcutura).
No hace falta hacer una catedral como MVP, si el mercado nos dice que va a ser un unicornio ya construiremos una catedral.
Lo cierto es como consultor no me he encontrado con soluciones de este tipo, pero si que conozco a bastantes amigos (tecnólogos) emprendedores que han iniciado proyectos o startups que se han bloqueado antes de salir sin poder validar la idea por la complejidad tecnológica de la solución. Incluso, he visto fracasar casos de ideas que un Drupal hubiera servido de MVP para validar la idea.
Eso no quita que, una vez validado o incluso en paralelo, se inicie un proceso de desarrollo más largoplacista, de hecho, establecer este balance es la clave de la estrategia digital.
Existen partes de los productos digitales que no aportan valor al negocio puesto que no son parte del core del negocio. Es el caso de algunos procesos administrativos, las landing pages, etc. Querer asumir la producción de este tipo de productos digitales desde dentro del equipo de desarrollo puede ser bueno en cuanto a ahorro de costes, pero es un claro error a nivel estratégico por dos motivos: la carga de pasivo laboral y la pérdida de foco.
Internalizar desarrollos que no aportan valor a tu negocio puede suponer una carga de pasivo laboral inecesaria o la pérdida de foco de recursos de alto valor.
Vamos a trabajar sobre el ejemplo de las landing pages, pero aplicaría igual en cualquier otro desarrollo que no sea de core. Cuando el director de marketing pregunta al CTO, podemos asumir el desarrollo de una landing para esta campaña publicitaria internamente, el CTO puede pensar, bueno, es solo una landing, me cuesta 4 horas hacerla. Para empezar, esas 4 horas nunca serán 4 horas, se convertirán en dos jornadas de un ingeniero especializado en tu negocio péridas haciendo una web de bajo valor añadido. A priori, el coste será menor que contratarlo fuera, eso es seguro, pero ¿qué tareas habrá dejado de hacer tu ingeniero?, ¿qué valor tienen para la compañía esas tareas de valor añadido? ... Entonces ... ¿es realmente más barato?
Existen varias opciones que un CTO debería conocer para externalizar desarrollos de software ya sea porque no aporten valor al negocio o bien para poder soportar sprints puntuales de desarrollo.
Muchas veces la tendencia de un CTO es la de simplificar los problemas y entender que piezas de software preconstruidas no encajan al 100% con el problema que tienen. El uso de herramientas estándar muchas veces nos permite solucionar el 80-95% de los problema estándar en un 1-8% del tiempo que cuesta desarrollar una solución a medida.
Ejemplo de ello son temas como el CRM, CMS e incluso un ERP. Lo que me he encontrado ya varias veces es con CTOs que en su momento decidieron solucionar con un desarrollo a medida alguna necesidad no de core (por ejemplo: CMS, un gestor de newletter o incluso un gestor de ticketing (bug tracker) ) y decide externalizar el mantenimiento de la herramienta pasado un tiempo. Lo cierto es que suelen tener muchísimos problemas para encontrar un proveedor que acceda al mantenimiento de un aplicativo que con frecuencia carece de documentación y no sigue demasiados estándares de desarrollo ... Por esto, todo lo que no sea de core, mi recomendación siempre es buscar algún producto opensource (ya maduro) que pueda solucionarnos el problema en parte.
Muchas veces sucede que el CTO establece unos vínculos de confianza elevados con su equipo, hasta aquí, es un punto positivo. El problema viene cuando el CTO da por supuesto que todo su equipo permanecerá en la empresa eternamente, y en momentos de presión, en los que hay una entrega cercana puede tomar decisiones como "esto no hay que documentarlo por ahora", "los tests unitarios no son tan importantes en esta parte porque este ingeniero se como trabaja y lo hará bien", etc.
Especialmente en el sector de IT, hemos de asumir que cualquiera de las personas que está en nuestro equipo puede desaparecer en cualquier momento.
Está claro, que cuando ese ingeniero en el que tanto confía decida dejar la empresa, el equipo lo notará y como consecuencia, el producto se resentirá.
Otro caso que me he encontrado es que el CTO vaya añadiendo gente y una falta de estructura le impida crecer. Es decir, que al final el equipo sea el CTO y 15 desarrolladores (con algún team leader) y que su capacidad de producción sea la misma que era cuando eran 10. A la que empiezas a escarbar, todo el mundo está bloqueado por alguna decisión del CTO, que a su vez está desbordado por el día a día. De hecho, esto es extremadamente común, es en ese momento cuando la figura de un Software Engineer Manager es de gran ayuda. Esta situación da para escribir otro post.