Si trabajas en una startup, es posible que tarde o temprano tengas que pasar por una due diligence. Ya sea porque otra empresa os quiere comprar o invertir, o porque un gran cliente quiera contratar vuestros servicios o productos. Personalmente me ha tocado vivir las due diligence desde ambos lados, primero como CTO cuando algún inversor quería invertir, y luego como fractional CTO desempeñando el rol de auditor para algunos clientes.
La due diligence es un proceso de auditoría al que se somete una compañía para entender mejor su valor real. Normalmente se examinan diferentes aspectos como el técnico, el funcional, el financiero o el legal. El objetivo es recolectar el máximo de información posible acerca del funcionamiento de la startup por dentro, para contrastar la hipótesis de inversión o compra y detectar posibles riesgos y problemas que no son evidentes desde fuera. Para ello se hace un análisis a fondo, donde se entra literalmente en la cocina, se habla con los cocineros, se prueba la comida, se examina cómo se cocina, se buscan problemas en la calidad de la comida, y hasta se puede llegar a hablar con los clientes.
En este post me centraré en las due diligence técnicas, que evalúan los productos y activos tecnológicos desarrollados por la startup, junto con los equipos de ingeniería, sus metodologías de trabajo, y todos los aspectos técnicos necesarios para mantener el negocio, como son la seguridad, el compliance, etc..
Qué aspectos se revisan en las due diligence técnicas
Normalmente se examina los siguientes aspectos:
- Activos tecnológicos. Se busca entender cómo están desarrollados los productos de la startup, el stack de tecnología utilizado, la arquitectura técnica, la infraestructura, y el código fuente. El objetivo es contestar a preguntas del tipo ¿se utiliza un stack de tecnología actual y adecuado? ¿cómo de costoso será evolucionar y mantener el producto? ¿La infraestructura ofrece la suficiente resiliencia para mantener el servicio funcionando incluso cuando se produzcan fallos? ¿Existe un nivel de deuda técnica razonablemente bajo?
- Seguridad. ¿Cómo está protegido el sistema y sus datos? ¿Existen buenas prácticas que minimizen el riesgo de introducir vulnerabilidades? ¿Existen perfiles o equipos dedicados a la seguridad? ¿Se hace una monitorización activa de la seguridad?
- Equipo. ¿Cómo de buenos son los líderes técnicos? ¿El dimensionamiesto de los equipos es adecuado? ¿Existen perfiles de QA? ¿Hay devops? ¿Hay Product Managers? ¿Hay una baja rotación?
- Procesos. ¿Qué metodología de trabajo siguen los equipos de ingeniería? ¿Existe una cultura de mejora continua? ¿Cómo se define el backlog de producto? ¿Hay principios bien definidos que guían el trabajo? ¿Existen procesos adecuados para dar soporte y mantener el servicio?
- Compliance. ¿La startup tiene procedimientos para cumplir con la GDPR? ¿Tienen certificaciones ISO (ISO 27001, ISO 9001, ISO 22301, … )?
- Proveedores de tecnología. ¿Se han contratado los servicios de proveedores externos? ¿Qué partes están externalizadas? ¿Hay partes core externalizadas?
Problemas y patrones que se repiten en las due diligence
Es común que al realizar una due diligence como auditor se observen de forma repetida una serie de patrones y problemas. En mi experiencia estos son algunos de los más importantes:
- Falta de cultura ágil y una implementación robusta. De forma bastante generalizada, he observado una adopción y puesta en práctica bastante deficiente de las metodologías ágiles. Scrum parece ser el rey de los frameworks ágiles en startups que desarrollan productos de software. En la inmensa mayoría se siguen las ceremonias estipuladas, pero no hay una compresión real de los principios ni la filosofía ágil, lo que provoca que se siga utilizando una mentalidad obsoleta bajo la etiqueta de agilidad. Un patrón que me he encontrado de forma recurrente, es la realización de retrospectivas periódicas pero sin un impacto real, sin mejora continua. Más allá de la metodología, revisar cómo trabajan con Scrum arroja mucha información acerca de la cultura.
- La adopción de QA Automation y Devops es más baja de lo que parece. Aunque ya hace más de una década desde que se empezaron a adoptar, es sorprendente ver como todavía muchas empresas no las usan o tienen implementaciones muy parciales, dependiendo demasiado del testing y los despliegues manuales.
- El estándar de calidad es demasiado bajo. Muchas veces se acepta como razonable un número de incidencias en producción alto. Una de las cosas que más observo cuando realizo una due diligence es el número de bugs e incidencias en producción en el último año. Y me ha sorprendido que el número no suele ser bajo.
- La seguridad se suele tratar como un aspecto secundario que se posterga hasta que es inevitable, principalmente por la falta de tiempo y que no se ve como una prioridad para el negocio. En algunos casos extremos me he encontrado malas prácticas, como son passwords y api keys en texto plano en los repositorios de código. Un fallo de este tipo, expuso un número importante de repositorios de Mercedes Benz hace unos meses, por ejemplo.
- Se hace poco product management, muchas startups no tienen roadmaps bien definidos ni perfiles de product management. Es bastante común que las peticiones de un cliente acaben traducidas en funcionalidades, con poco análisis acerca de su encaje dentro de la estrategia de producto.
¿Cómo prepararte?
Algunas cosas que me parecen importantes de cara a prepararte para una Due Diligence técnica, son:
- Entender el acuerdo que se está valorando. Este aspecto es clave porque determinará cómo el auditor o auditores llevarán a cabo la due diligence, y lo que van a mirar. Saber si se está valorando la compra de la compañía o la inversión, y cuáles son las intenciones en caso de producirse, es decir, si se quiere integrar la startup dentro de la empresa que compra o si por el contrario se quiere mantener como una empresa independiente. Si se está valorando la integración de la startup, aspectos como el stack tecnológico, el equipo y la cultura cobran mayor relevancia.
- Responder con calidad y completitud. Casi todas las due diligence van acompañadas de cuestionarios en los que se solicita contestar a unas cuantas preguntas que pueden ser sobre temas como la tecnología, la seguridad, las personas, los procesos, el compliance o los proveedores. Es frecuente que los ingenieros encargados de responder a estos cuestionarios, sean gente bastante ocupada, y los vean como un trámite tedioso que les resta foco de sus tareas del día a día. Además no se suele reservar mucho tiempo para este tipo de trabajos, lo cual provoca que muchas veces se respondan de forma rápida, sin suficiente calidad y con información incompleta. El problema de esto es que por un lado estamos mostrando poca atención a la calidad frente a los auditores y por otro lado estamos dificultando su trabajo, lo cual es posible que tenga un impacto negativo. Es cierto que muchos auditores son conscientes de las razones que llevan a los ingenieros a contestar a los cuestionarios de esta forma, pero el auditor no puede adivinar lo que no se cuenta o se hace de forma incompleta. Y con todo esto, lo que ocurre es que nos arriesgamos a tener una evaluación desfavorable y poco fiel de la realidad, con lo que ello conlleva para la estrategia y el futuro de la startup.
- Evitar dar una imagen irreal. Seguramente el auditor o auditores que hacen la Due Diligence tengan la suficiente experiencia para saber que en todos los sitios se cuecen habas. Y también sepan que a veces las startups pretenden vender una idea de su valor que está alejada de la realidad. Una de las cosas que más me hace sospechar, como auditor, es una startup que parece cumplir con todos los checks técnicos (ej: utilizan las mejores prácticas, no tienen prácticamente incidencias en producción, utilizan metodologías ágiles que mejoran continuamente a través del uso de métricas, no tienen rotación, y tienen una seguridad excelente.. y todo esto lo consiguen con un equipo de 5 ingenieros). Pero contestar a los cuestionarios intentando proyectar una imagen demasiado perfecta suele tener las patas muy cortas. Pues los cuestionarios suelen ir acompañados de reuniones, en las que se piden evidencias para validar las contestaciones y también del acceso a las herramientas y repositorios de código para inspeccionarlos. Y si un auditor detecta que le han intentado engañar puede ser una bandera roja. Personalmente valoro más los equipos que son sinceros en las contestaciones y reconocen cuando no cumplen con algún check. Y si además dan evidencias de tener ese punto ya identificado y haber planificado una acción de mejora, es un gran plus.
- Involucrar a los mejores ingenieros. Por lo que hemos comentado más arriba, dar una buena respuesta a los cuestionarios de la due diligence es clave, y sin duda la mejor forma de hacerlo es involucrando a los ingenieros que mejor conocen la tecnología. Además cuando se está valorando la compra o inversión en una startup, uno de los aspectos primordiales tiene que ver con el equipo y el talento que tiene. Es casi seguro que el auditor querrá conocer de primera mano al equipo, y sobretodo a los líderes técnicos. Puede que no lo pidan explícitamente, por lo que es bueno que seamos proactivos involucrando a los mejores para obtener una buena valoración en el aspecto de equipo. Una reunión en que los ingenieros de la startup demuestran seniority y dominio sobre los temas que se tratan y sus campos, puede ser un valor diferencial.. Al igual que ocurre en las entrevistas de trabajo.
Conclusiones
Si a la startup en la que trabajas le va bien, es muy posible que tarde o temprano os enfrentéis a una due diligence, y ser capaz de dar una buena respuesta a la parte técnica es clave. Como en todo la preparación es crucial, darle la prioridad que se merece, involucrar a los mejores ingenieros y no intentar dar una imagen irreal te ayudará. Pero sin duda la mejor forma de prepararte para un due diligence técnica, es empezar antes siquiera de que esta se plantee como una opción remota. Ya que lo que se evalúa es el estado actual de la startup y sus activos, que son el fruto de un trabajo prolongado. En la due diligence pueden quedar al descubierto una cultura deficiente, malas prácticas de programación, fallos de diseño, vulnerabilidades, fallos de seguridad, violaciones de la GDPR, … Y todo eso puede impactar el deal.