Vamos a centrarnos en la segunda: la etapa beta. Una versión beta o lanzamiento representa generalmente la primera versión completa del programa informático, que es posible que sea inestable pero muy útil, por cuestiones que vamos a ver.

Qué pasaría si trabajar en beta fuera lo normal en nuestras organizaciones –entendiendo por “normal” lo habitual; si decidiéramos “congelar” lo que estamos planificando, no seguir adelante y empezáramos a implementar pequeñas cosas –minimum viable product, y a corregir errores. Es más, incluso nos atreviéramos a lanzarlo al mercado y empoderar a nuestros clientes –internos o externos, para que nos informaran sobre los errores y aspectos, de mayor o menor relevancia para nosotros pero que ellos quisieran ver en la “versión final”, incluso que participaran en ello…

¿Qué los errores saldrían caros? Pues sigamos invirtiendo incluso años diseñando planes a 4 años vista imposibles de cumplir en una sociedad líquida donde el cambio es la constante. Las start up’s trabajan en beta y no les va nada mal. En el mundo de la tecnología, las versiones beta permanecen incluso durante años y son utilizadas como si estuvieran en nivel de producción.

Nada menos que Gmail y las noticias de Google estuvieron en beta por un período de tiempo muy largo (5 años).

¿Por qué no hacer de ello la manera de trabajar en nuestras organizaciones? En el nuevo modelo de trabajo, caracterizado por la creatividad, el trabajo en red, lo digital, el conocimiento, la redarquía, la autocracia, la colaboración, la pasión por lo que se hace, la confianza vs el control, la apertura de las empresas hacia el exterior, el activity based working, el talent as a service y un montón de cosas más que darían para unos cuantos posts, trabajar en “beta permanente” y ser un longlife learner es un must.

Hace unos meses, en una conferencia sobre Future of Work en la sede de Microsoft en Madrid, donde tuve la suerte de participar como speaker, mantuve una interesante discusión con el Director de RRHH de KFC, mi buen amigo Rogelio Iglesias. Él defendía la importancia de sacar a los empleados de su zona de confort, lo que comparto totalmente, pero en aquella ocasión añadí un “pero”: para ello debemos ser capaces de instaurar la cultura del error en nuestras organizaciones. Así, si queremos trabajar en beta y conseguir que nuestros empleados salgan de su zona de confort se hace imprescindible normativizar el error.

Cuando somos niños ya se encargan de dejarnos claro que error es igual a fracaso.

En Silicon Valley, la cuna del emprendizaje, término que da muchas pistas, el error es una condición sine qua non en el camino hacia el éxito. No en vano es considerada la zona del mundo donde más empresas nacen y mueren. Los inversores jamás darían dinero a alguien allí que no hubieran errado en el pasado…

¿Qué ha ido bien? ¿Qué ha ido mal? ¿Qué hemos aprendido? ¿Qué haremos diferente la próxima vez? Los de TeamLabs, campus de innovación y emprendimiento, consideran que éstas son las preguntas que llevan a mejorar la manera en que se desarrollan los proyectos, pero aún las organizaciones que practican el error como “modo de vida”, sólo las humildes y proactivas obtienen respuestas significativas y útiles.

En TeamLabs incluso celebran sus “golden mistakes”: las mayores cagadas del año que han cometido.

Todo el mundo puede equivocarse, por eso los lápices vienen con goma en un extremo, como decían los Simpson.

Comparto con los de TeamLabs que, cuando conseguimos que los errores sean valorados como herramientas de aprendizaje -y si no, recordemos lo que su padre decía a Batman cuando apenas era un niño:

¿Por qué caemos Bruce? Para aprender a levantarnos

nos permitimos experimentar, desarrollar nuestra creatividad y nos planteamos cosas disruptivas y provocadoras que nos hacen alcanzar resultados que jamás hubiéramos imaginado al empezar. Estadísticamente hablando, cagadas y aprendizaje son dos variables directamente proporcionales: a mayor cagada, mayor aprendizaje. ¿Quién se atreve?