Trabajar en innovación es tan divertido como puede ser frustrante. La parte divertida es la que suele llevarse toda la atención: imágenes de hipsters saltando alegremente por las praderas verdes con post-its y sharpies, en dirección hacia una nueva entrevista con usuarios o una nueva sesión de brainstorming. Esa es la parte linda.

Si bien es cierto que pasamos mucho tiempo saltando alegremente por las praderas verdes con nuestros post-its, la otra parte del trabajo es reconciliar toda la novedad de los futuros posibles con la realidad inescapable del presente. Conseguir que organizaciones acostumbradas a hacer las cosas de una cierta manera empiecen a hacerlas de una manera diferente es un trabajo difícil que requiere de muchísima paciencia. Tiene mucho menos de saltar alegremente por las praderas, y mucho más de discusiones, negociaciones, compromisos.

Luego de haber pasado muchos años en ese tipo de procesos, hay una serie de lugares comunes que me he acostumbrado a escuchar en organizaciones grandes y pequeñas, más nuevas y más antiguas. Hace unos meses reuní algunos de estos lugares comunes en un post en LinkedIn como una serie de “red flags” del mundo de la innovación — y fue sorprendente cuánto resonaron con las experiencias de muchísimas personas.

Cuando se trata de cambiar la manera en la que una organización piensa o se comporta, hay una serie de indicadores que rápidamente te ayudan a entender que hay problemas estructurales que van a dificultar esa transformación. A veces parecen inofensivos, incluso hasta razonables: pero como todo buen red flag, son una señal de que hay un problema mucho más complejo de fondo que hay que resolver.

A veces la mejor opción es simplemente salir corriendo lo más rápido posible; pero muchas veces, por la razón que fuera, esto no es posible. De modo que quiero tomar algunos de los red flags que he escuchado con mayor frecuencia y desempacar cuál es el verdadero problema de fondo que deberíamos concentrarnos en resolver.

"¿Podemos ahorrarnos la parte de investigación con usuarios?"

Buscar la manera de ahorrar tiempo o dinero acortando o eliminando la investigación con usuarios en un proceso de innovación o diseño es uno de los indicadores más claros de que la organización está escenificando una forma de “teatro de la innovación” y no ha asimilado del todo principios metodológicos importantes. La organización quiere decir que está innovando, pero no está comprometida con todas las implicancias de lo que eso significa.

Una organización que ha realmente asimilado el diseño y la innovación entiende el valor que trae acercarse y entender las necesidades de las personas, y cómo esa comprensión se convierte en una ventaja competitiva en el mercado. Entender a las personas no es un desperdicio de recursos, ni es demorar la ejecución: es obtener la evidencia necesaria para saber que lo que se quiere desarrollar efectivamente hará una diferencia para alguien.

En muchos casos, querer obviar la parte de investigación es también un indicador de que la decisión respecto a lo que se va a hacer — el producto o servicio que se va a crear, la iniciativa que se quiere activar, etc. — ya han sido tomadas por el liderazgo de la organización. Es decir: que ya hay una hipótesis de solución antes de haber dedicado tiempo a entender el problema, y por lo tanto dedicar tiempo a la investigación solo podría cuestionar esa decisión ya tomada. Pero ese es uno de los caminos más comunes a terminar poniendo en el mercado propuestas de valor que en la práctica no le importan a nadie; es una señal de que la organización toma decisiones en base a intuiciones en lugar de sistemas y evidencia.

¿Qué hacer al respecto? Todo proyecto de innovación tiene que dedicar mucha energía al principio a transparentar las agendas de todos los stakeholders involucrados. ¿Qué es lo que realmente quieren conseguir con este proyecto? ¿Qué preocupaciones y dudas tienen? ¿Qué evidencia e información podemos traer para mitigar esas preocupaciones?

Cuando los stakeholders son escépticos de lo que se puede lograr con un proceso de innovación, lo mejor es acercarlos en lugar de alejarlos. Incentivarlos a participar de las entrevistas con usuarios, de las visitas de campo, de las sesiones de síntesis — y que de esa manera experimenten de primera mano todo lo que se puede aprender en muy poco tiempo.

"Estamos empezando/avanzando/terminando con nuestra implementación de SAP."

Y por SAP puede entenderse cualquier ERP, CRM, o gran proyecto de integración tecnológica que requiera de la intervención de múltiples proveedores externos durante muchísimo tiempo.

Muchas organizaciones se meten en estos procesos porque los ven más como ritos de transición, como si fuera algo que “negocios serios” u “operaciones importantes” tienen que hacer en algún momento de su camino de crecimiento. Y no me malentiendan: digitalizar las operaciones es importantísimo, y muchas veces un ERP o un CRM son el mejor camino a seguir.

El problema con una cantidad importante de estos procesos es que revelan la manera en la que la organización piensa en su incorporación de tecnología: como algo que se compra en lugar de algo que se construye. Como una pieza que se adquiere de una serie de proveedores reconocidos que tienen el know-how para integrar esta pieza con el resto de la organización. Rara vez un gerente de tecnología se meterá en problemas por empujar la idea de que es necesario invertir muchísimo tiempo y dinero en implementar una de estas plataformas serias e importantes para modernizar el negocio.

En cambio la alternativa si podría meterle en problemas: si abogara en cambio por construir equipos internos que desarrollen soluciones propias a los problemas identificados dentro de la organización, sería fácil que eso sea visto como innecesariamente riesgoso, o como un intento por reinventar la rueda y resolver un problema que ya ha sido resuelto.

¿Qué hacer al respecto? Una organización que realmente piense que la tecnología puede darle una ventaja competitiva en el mercado tiene que aprender no solamente a comprar e integrar esa tecnología — algo que podría hacer cualquiera de sus competidores — sino también a construirla específicamente para sus necesidades. Pero desarrollar esa capacidad interna no se ve como un gran proyecto para implementar una única plataforma que lo resuelva todo: se ve, más bien, como una gran cantidad de pequeños esfuerzos articulados que resuelven rápidamente cuellos de botella que frenan el crecimiento de la organización.

También puede ser útil incorporar nuevos paradigmas de desarrollo — como las herramientas nocode y lowcode, que permiten desplegar soluciones rápidamente sin requerir grandes equipos de desarrollo. Estas herramientas pueden ayudar a las organizaciones a ganar confianza en sus propia capacidad para resolver problemas utilizando tecnología propia.

"Trabajamos en sprints para avanzar más rápido."

En los últimos años, la agilidad se ha puesto de moda. Y con eso, equipos de tecnología de todos los tamaños han empezado a adoptar muchas de las prácticas y los rituales que están asociados con el mundo de la agilidad, a utilizar el lenguaje y celebrar los mantras.

Sin embargo, en muchos casos esto se está haciendo sin entender el trasfondo detrás de estas prácticas, repitiendo mecánicamente palabras y conceptos sin dejar que tengan un impacto transformador en la cultura de la organización. El uso de “sprints” es uno de los ejemplos más comunes, donde hablar de un sprint de trabajo ha terminado convirtiéndose en un equivalente a hablar de una etapa en un proyecto, o simplemente a querer decir “vamos a tratar de hacer esto muy rápido”.

La idea de un sprint tiene que ver con dos cosas: la primera es la práctica de timeboxing, crear una unidad artificial de tiempo en la que se realiza el trabajo para poder tener múltiples iteraciones sucesivas que construyen sobre las anteriores. Es decir: como no sabemos cuánto nos va a tomar todo el proyecto, vamos a trabajar en unidades de una duración fija para poder revisar continuamente nuestro progreso y aprendizajes.

La segunda es la idea de que cada sprint debe producir un incremento de valor para el equipo y para los usuarios. En cada sprint debemos producir y entregar algo nuevo, continuamente creando valor. No tiene que ver realmente con la velocidad, ni con poder predecir las etapas del proyecto, sino con un compromiso que el equipo hace a entregar valor continuamente.

¿Qué hacer al respecto? Así como hay un “teatro de la innovación”, también hay un “teatro de la agilidad” del que las organizaciones deben cuidarse. El solo hecho de organizarse en squads, trabajar en sprint, y celebrar rituales o ceremonias Scrum pueden terminar teniendo un impacto solo cosmético si al final los equipos pasan la mayor parte de su tiempo respondiendo a las preocupaciones de los stakeholders en un proyecto, o si las determinaciones sobre qué se implementa se basan más en directivas que en evidencia.

Para esto es importante tener al talento correcto con las condiciones correctas manejando estos procesos: idealmente, personas que traigan las cicatrices y los aprendizajes de haberlo intentado antes y tengan suficiente empoderamiento en la organización como para poder proteger a los equipos de desarrollo y empujar al liderazgo a desaprender prácticas establecidas. Pero es importante que este talento construya capacidades internas y no se convierta únicamente en ejércitos de consultores trayendo playbooks y frameworks, pero que no participan directamente de la cultura de la organización.

Esto tendría que ser una serie

Y por eso vamos a seguir capturando y compartiendo más red flags del mundo de la innovación. Porque lo impresionante es lo comunes que pueden llegar a ser, y lo benignos que pueden aparecer: ninguna de estas afirmaciones sería percibida como problemática a primera vista. Querer acortar el tiempo de investigación de un proyecto hace sentido en busca de eficiencias y de avanzar más rápido. Trabajar con proveedores reconocidos mundialmente para implementar soluciones tecnológicas complejas hace muchísimo sentido. Organizar los proyectos alrededor de prácticas ágiles para ganar velocidad en la entrega de valor tiene todo el sentido del mundo.

Todas estas cosas son razonables. Pero esconden sutilezas, dejan entrever ciertas prácticas en la organización que traicionan los objetivos de estas iniciativas. Queremos construir organizaciones que comuniquen claramente la importancia de escuchar y responder a las necesidades de las personas. Queremos construir organizaciones que sepan desplegar inteligentemente la tecnología para responder a sus desafíos operacionales. Queremos construir organizaciones que desarrollen agilidad para mitigar la incertidumbre y enfocarse en crear valor para los usuarios. Tenemos que enfocarnos en qué queremos conseguir cuando hacemos estas cosas, cuando queremos transformar la organización y activar procesos de innovación.

Dicho de otro modo: ninguno de estos red flags implica que exista mala fe de parte de las personas, que hayan agendas secretas, o falta de transparencia. Pero sí es fácil que hayan brechas de alineamiento, expectativas no comunicadas, o ansiedades que vienen del hecho de estar probando cosas nuevas.

Queremos volver cada cierto tiempo sobre nuestra colección creciente de red flags porque son herramientas útiles para diagnosticas potenciales problemas y tomar acción al respecto. Si tienes tus propias historias que quieras compartir, puedes escribirnos por correo electrónico, Instagram o LinkedIn y así iremos ampliando nuestra colección.

Pero sobre todo, si te encuentras con este tipo de red flags, recuerda que no estás solo o sola. Es sorprendente cuántos hemos pasado por lo mismo, más de una vez, y por lo mismo cuántos aprendizajes podemos compartir cuando empezamos a contar estas historias.