Llevaba un tiempo pensando en que sería una buena idea poner en claro parte de la experiencia acumulada en ya bastantes años de desarrollos tecnológicos para startups (propias o ajenas). Siendo la casuística relativamente acotada, como ahora comentaré, es probable que pueda ser útil a un conjunto concreto de personas que están a punto de emprender una aventura de un nuevo negocio en Internet en donde la tecnología no es un elemento “commodity”, sino la clave del éxito.
Como sería imposible abarcar todo en un solo artículo, he decidido empezar con lo relativo a la configuración del equipo para más tarde hablar sobre tecnología y metodologías de trabajo en sendos artículos.
Equipo de una startup tecnológica
Lo primero sería hacernos la pregunta sobre qué es una startup tecnológica. Mi respuesta es que es una nueva empresa que necesita, para desarrollar su idea de negocio, tecnología nueva que ha de desarrollar para hacerla viable. Esta tecnología nueva tiene un grado alto de incertidumbre por su complejidad, novedad o innovación requerida. A veces el reto tecnológico se asienta sobre la escala del problema o número de usuarios, otras veces sobre la necesidad de múltiples integraciones y muchas veces es una cuestión de que (casi) nadie ha hecho algo parecido en el pasado.
Por tanto, no caben en esta definición las startups que emplean la tecnología ya existente, recombinándola o configurándola, en donde es mucho más importante dar con una clave de negocio de éxito que la elección acertada del equipo técnico, por ejemplo, algo que es fundamental para el éxito de las que trato en esta serie de artículos.
En España el ecosistema de emprendimiento de startups tecnológicas ha ido mejorando con los años. Me refiero sobre todo a las que necesitan de un capital importante muy rápidamente para poder mantener un ritmo de desarrollo alto y llegar a tiempo al mercado con su propuesta. Aún así detecto una carencia muy llamativa y es el perfil técnico de la persona que hace de CEO, que es prácticamente inexistente.
El fundador o fundadora, ya sea una persona o varias, rara vez puede siquiera soñar con ejecutar ella misma parte de la tecnología subyacente. Ha concebido la visión y tiene una estrategia clara, incluso ha forjado ya relaciones con terceras partes para preparar el terreno, pero necesita desesperadamente un equipo de primera línea para llevar a cabo el desarrollo tecnológico del proyecto.
¿Contrato equipo propio o externalizo?
Uno de los grandes dilemas del CEO no-técnico es, sin duda, si es mejor fichar a un equipo propio o buscar a una empresa externa para ese trabajo. Hay ventajas e inconvenientes en ambos modelos pero voy a centrarme en lo más destacado de cada uno.
Con el equipo propio existe el problema de si es necesario empezar por el CTO (Chief Technology Officer) o dejarlo para más tarde. Pero sin el CTO ¿cómo elegir al equipo adecuado? ¿cómo son los salarios y qué conocimiento y experiencia se necesitan? ¿Es suficiente con gente con mucho potencial que esté dispuesta a dedicar todo el tiempo que sea necesario? Y con el CTO hay otras preguntas igual de importantes ¿tengo que darle porcentaje de la compañía? ¿cuánto? ¿necesito un CTO orientado más a negocio y tecnológo o un CTO que se arremangue el primero y programe?
Con el equipo externo a través de una empresa surgen las dudas sobre las capacidades, experiencia y, muy a menudo, “esfuerzo” que esa empresa va a querer dedicar. No me refiero a si el equipo externo va a estar dedicado al 100% si no si va a estar realmente comprometido con el éxito del proyecto. ¿Debería ser partner del proyecto? ¿dónde tienen que estar físicamente estas personas? ¿qué contrato tengo que firmar para no poner en riesgo la inversión? ¿Qué dedicación van a requerir de mí?
Una solución intermedia
Cada caso necesita un análisis específico pero tras aplicar una fórmula con casi veinte startups en estos últimos 8 años, me atrevería a decir que hay un modelo que puede funcionar muy bien si se dan unas circunstancias concretas.
Sería tentador bautizar a este modelo como “el modelo Kaleidos” porque realmente lo aplicamos de forma muy consciente en nuestra empresa pero hemos visto variantes de él más allá de nuestros “muros” y tomamos prestadas algunas ideas de nuestro entorno.
En esencia, consiste en minimizar cada riesgo en parte posponiendo cada decisión complicada hasta que realmente resulta mucho más valioso optar por una vía que no hacerlo.
En el caso del equipo, constituir uno es menos importante que dar a luz el producto. Lo ideal sería tener ambos a la vez pero el riesgo de montar un equipo que sea capaz de funcionar como tal, a buen ritmo, buena comunicación, equilibrado en fuerzas, realmente fullstack en tecnología y diseño, es casi una utopía. Para empezar ¿qué personas y conocimientos realmente se necesitan cuando el trabajo aún no ha empezado? En estos proyectos donde la tecnlogía es a la vez un catalizador y una amenaza constante, es muy complicado acertar a la primera sobre plano.
Por tanto, el primer equipo de estas startups puede perfectamente ser uno externo que está listo al completo el día 0.
Pero aquí viene un primer baño de realidad. Por un lado, no todas las empresas con perfil técnico son buenas aliadas para concebir un producto o plataforma de una startup. Se requiere una sensibilidad especial cuando tratamos del core de negocio de una empresa que aún está naciendo. Hay que ser un compañero crítico que sepa hacer las preguntas adecuadas, desarrollar pensando en el futuro pero entregando resultados a cada poco asumiendo que va a haber cambios sobre la marcha. Por otro, puede haber inversores de la startup que no vean con buenos ojos que el equipo emprendedor no está reclutando el talento que necesita desde el primer día y esté sacando fuera buena parte del saber-hacer.
El modelo Kaleidos da una respuesta bastante convincente a esta situación.
Equipo temporal: el equipo formado por kaleiders para el proyecto se configura como el equipo idóneo (todos los perfiles, desde UX hasta backend) para el proyecto pero tiene fecha de caducidad. Tienen la misión de aterrizar el problema, encontrar una primera versión del producto que pueda lanzarse al mercado, desarrollarlo de forma sostenible para que pueda crecer libremente en el futuro y ayudar a la startup a la confección de su equipo interno así como su formación.
CTO as a service: una persona de Kaleidos puede jugar el papel de CTO en funciones como si fuese un servicio que se presta. Esto es particularmente útil para mitigar los miedos de algunos inversores iniciales ya comprometidos pero, sobre todo, para dar la cara en cualquier due dilligence que pueda aparecer durante el tiempo de la colaboración. Esto es más habitual de lo que pueda uno creer y hasta ahora tenemos 100% de éxito.
Orientado a startups: las circunstancias particulares del tipo de empresa lo permean todo. Desde la forma de concebir el producto o servicio, la necesidad de poder pivotar sin que sea un drama para nadie, la transparencia total sobre el trabajo que se va haciendo, comunicación fluida, anticipación, ritmo, etc. Muchas grandes empresas de servicios tecnológicos se embarcan a buscar clientes startup y abandonan muy rápido porque se ven incompatibles.
Algo que me he reservado conscientemente para este momento es el hecho de que Kaleidos también incuba y emprende sus propias ideas. El mecanismo que más admiración despierta es lo que llamamos PiWEEK, una semana cada seis meses de innovación completamente libre en toda la empresa. No todos los proyectos acaban en ideas de negocio porque tampoco se persigue. Eso sí, estamos muy orgullosos del caso de éxito más claro, Taiga, una empresa surgida de Kaleidos con un producto alucinante para la gestión de proyectos empleando metodologías ágiles. Con medio millón de usuarios en todo el mundo, es una de las mejores plataformas del momento.
Si a esto sumamos que Kaleidos ha concluido con éxito la aceleración tecnológica de unas 20 startups (algunas con padrinos y madrinas muy importantes, otras protegidas por NDAs), superado con éxito 5 due dilligences para sucesivas rondas de la startup y ayudado en la búsqueda y formación de 18 equipos internos, parece claro que nos hemos especializado muy bien en esta solución intermedia. Y además lo hemos hecho en Reino Unido, España, Suiza o Estados Unidos.
¿Qué riesgo asume la startup con este modelo?
Podría responder de forma teórica o tirando de experiencia. La teoría dice que puede haber una disfuncionalidad grave al cabo de dos meses cuando el enamoramiento inicial ha dejado paso a una ristra constante de malentendidos. Es decir, no se está consiguiendo el efecto “mente colmena” entre startup y equipo externo y se genera muchísimo desperdicio.
La experiencia me dice que esto no pasa porque nos aseguramos de tener unas tres semanas previas al arranque del proyecto con sesiones de trabajo que analizan el proyecto desde todas las perspectivas y a esas sesiones van todas las personas relevantes, incluyendo a veces hasta (potenciales) inversores de la startup. Esa convivencia resulta crucial para acordar una misma visión del proyecto.
Lo que la experiencia sí me dice que pasa es que la startup empiece a estar demasiado cómoda con este modelo de colaboración. El equipo funciona a buen ritmo, la idea se va tangibilizando, la startup consigue momentum… y no quiere cambiar nada. No quiere iniciar el proceso de confección de equipo interno porque las prioridades son enteramente el producto y el negocio. De pronto el coste de un equipo de Kaleidos no es ningún problema porque el rendimiento lo justifica. Esto es un grave riesgo porque no es lo mismo desarrollar para salir al mercado y monitorizar los primeros meses aplicando cambios y mejoras que tener que vivir el día a día de la empresa en donde todos los estímulos provenientes del exterior son muy relevantes. En ese momento es cuando se necesita un equipo interno de la startup que pueda estar completamente alineado con ella porque el producto está vivo ahí fuera y se necesita una cohesión absoluta de todas las partes de la compañía.
En al menos cinco proyectos hemos tenido que contener ese riesgo porque el cliente quería que siguiéramos nosotros a toda costa, sin importar la tarifa. En uno de ellos, pasamos de planificar 2 años a estar casi 4. Dado que desde muy temprano hacemos los proyectos nuestros, tampoco tienes unas ganas terribles de soltarlos, pero hay que anticiparse y tener la disciplina para conformar el equipo interno. Lo que puede funcionar perfectamente en la primera fase, no tiene por qué ser válido en el día a día de un producto ya lanzado.
Lo que desde luego no es un riesgo que la startup vaya a asumir es que su idea de negocio se vaya al traste por la ejecución técnica. Absolutamente todas nuestras colaboraciones han resultado en un éxito de producto en su confección. Es decir, se ha lanzado lo que se quería lanzar (mutado desde el inicio, por supuesto). Otra cosa muy diferente es que todas las startups hayan tenido éxito o hayan tenido el éxito que deseaban. Pero nunca ha sonado el teléfono de Kaleidos de un ex-cliente para decirnos que por nuestra culpa se ven imposibilitados para hacer realidad su idea de negocio. Todo lo contrario, nos suelen llegar felicitaciones sobre lo fácil que fue evolucionar el producto y pivotar (o no).
Esto no es casualidad, hay formas de desarrollar una plataforma para evitar quedar atrapado en un concepto de producto en el futuro y que no haya equipo que lo herede que pueda rescatarlo. Muchos partners tecnológicos que se animan con startups no se dan cuenta de esto y condenan a la startup ya en su nacimiento, pero ése no es el modelo que estamos describiendo aquí.
¿Qué plazos tienen sentido para esta solución mixta?
Si recordamos que hablamos de desarrollo tecnológico complejo, está claro que estas startups no pueden pensar en que van a salir en cuatro meses. Un ritmo y rendimiento elevados de un equipo no están exentos de cambios de prioridad o callejones sin salida y el proyecto tiene que poder respirar y el tiempo es la variable más importante y mucho más si queremos realmente que sea un desarrollo sostenible.
Los plazos que al menos en Kaleidos vemos que tienen sentido en este modelo es un rango de entre 10 meses y dos años, estando el sweetspot en año y medio. Un equipo de Kaleidos en año y medio puede hacer casi cualquier cosa realmente nueva.
¿Cuándo debería iniciarse la confección del equipo interno de la starup? Hemos tenido casos extremos de ir montando ese equipo desde el día 1, una persona nueva cada mes aproximadamente, buscando “espejar” al equipo de Kaleidos y que la transferencia fuese instantántea, hasta postergarlo demasiado tiempo y empezar a tener crisis serias porque la startup se queda con un equipo mínimo propio que no puede mantener el ritmo al que negocio está acostumbrado. Una regla sencilla es ejecutar este plan aproximadamente cuando alcanzamos 3/4 del tiempo acordado teniendo siempre al menos 3 meses de margen.
Consideraciones finales
En Kaleidos estamos muy a gusto con este modelo. Nos permite ir creando nuevas plataformas para gente que realmente “lo vive”. Hay reto tecnológico y creativo y los equipos se involucran de lleno (y obligan a la startup a hacer lo propio). La localización del equipo en nuestras oficinas no es absoluto un problema cuando la startup tiene ella misma una presencia testimonial (y la tecnología de videoconferencia empieza a ir realmente bien). Finalmente, entregar algo de lo que estás orgulloso a un equipo nuevo que ve una oportunidad para continuar con un trabajo agradecido es una sensación de realización profesional fantástica que no abunda mucho en el sector, desafortunadamente.
Pero todo esto requiere de una relación de confianza y entre iguales entre la startup y, en este caso, Kaleidos. Si no existe eso que a veces llaman “química”, las metodologías, las tecnologías, toda la experiencia acumulada, el mejor talento o el “modelo” en global, no van a resultar. Pero de eso podemos hablar en otro artículo si os parece. De momento lo dejo aquí hasta el siguiente artículo de la serie. Podéis contactarnos en hello@kaleidos.net.