Seguridad psicológica e innovación: lo que sostiene la investigación

En programas de innovación, la pregunta que más escuchamos de los directivos es por qué no aparecen ideas. La empresa creó un canal de sugerencias, hizo un hackathon, reservó presupuesto. Las propuestas que llegan son pocas y demasiado seguras. Casi siempre la respuesta está menos en el proceso y más en lo que ocurre en las reuniones de equipo cuando alguien admite que no sabe, discrepa con el jefe o cuenta que una prueba salió mal.

Amy Edmondson le puso nombre a este fenómeno en un artículo de 1999: seguridad psicológica, definida como la creencia compartida por los miembros de un equipo de que el grupo es seguro para asumir riesgos interpersonales.

Qué mostró el estudio original

La investigación de Edmondson siguió a 51 equipos de trabajo en una empresa industrial. El hallazgo central fue que la seguridad psicológica estaba asociada al comportamiento de aprendizaje del equipo: pedir ayuda, buscar retroalimentación, discutir errores, experimentar. Y ese comportamiento de aprendizaje, a su vez, estaba asociado al desempeño.

Hay un matiz importante. En un trabajo anterior con equipos hospitalarios, Edmondson había observado que los mejores equipos reportaban más errores, no menos. La explicación no era que se equivocaran más, sino que se sentían cómodos para registrarlos. Esa inversión es el núcleo del concepto: entornos que parecen tener pocos problemas pueden simplemente tener poca gente dispuesta a hablar de ellos.

El caso Google, con la debida cautela

El tema ganó visibilidad fuera de la academia con el Project Aristotle, iniciativa interna de Google sobre efectividad de equipos. Según el reportaje de Charles Duhigg en The New York Times Magazine (2016) y el material que la propia empresa divulgó, la seguridad psicológica apareció como el factor más relevante entre las dinámicas identificadas en los equipos estudiados.

Conviene la cautela: se trata de un estudio interno, divulgado de forma resumida, y no de una investigación publicada con revisión por pares. Es útil como ilustración y como puerta de entrada para la conversación con ejecutivos. El sustento científico está en los trabajos de Edmondson y en la revisión de Edmondson y Lei (2014), que reúne dos décadas de estudios sobre el constructo.

Seguridad psicológica no es comodidad

El malentendido más frecuente es confundir seguridad psicológica con un ambiente sin exigencia. Edmondson insiste en lo contrario. Cruza la seguridad psicológica con el estándar de desempeño y describe cuatro situaciones: baja seguridad y bajo estándar generan apatía; alta seguridad y bajo estándar generan comodidad; baja seguridad y alto estándar generan ansiedad; alta seguridad y alto estándar crean la zona de aprendizaje.

La implicación para la innovación es clara. No se trata de reducir la exigencia, sino de hacerla compatible con exponer dudas, hipótesis y fracasos. Un equipo de I+D con metas agresivas donde contar un experimento fallido es normal está en la zona correcta. Un equipo con las mismas metas donde el fracaso se vuelve tema de evaluación de desempeño va a esconder los malos resultados hasta el último momento posible.

Cómo medirla

La escala original de Edmondson tiene siete ítems, respondidos en una escala de acuerdo. Algunos están redactados en negativo, como la percepción de que un error cometido en el equipo se usa en contra de la persona, o de que es difícil pedir ayuda a los compañeros. Es breve, fue muy usada en investigaciones posteriores y funciona bien como componente de evaluaciones más amplias de cultura de innovación.

Tres cuidados prácticos:

• Mida a nivel de equipo. El constructo es grupal. El promedio de la empresa esconde lo que importa, que es la variación entre equipos con liderazgos distintos.
• Combínela con indicadores de comportamiento. Número de experimentos registrados, ideas que llegan a la etapa de prueba, frecuencia de revisiones posteriores a los proyectos. Si la escala dice que es seguro equivocarse y nadie registró un experimento fallido en un año, algo no cierra.
• Devuelva el resultado al equipo, no solo al gerente. La conversación sobre el resultado, bien conducida, ya es una intervención.

Qué puede hacer el liderazgo el lunes

Práctica	Ejemplo concreto
Encuadrar el trabajo como aprendizaje	Abrir el proyecto diciendo explícitamente qué no se sabe aún y qué hipótesis se probarán
Reconocer la propia falibilidad	El gerente cuenta un error propio y lo que aprendió, antes de pedirle lo mismo al equipo
Hacer preguntas genuinas	En las reuniones, preguntar "¿qué se nos está escapando?" y esperar la respuesta
Responder bien a las malas noticias	Agradecer a quien trajo el problema antes de discutir la solución
Separar fracaso inteligente de negligencia	Criterio escrito para distinguir un experimento fallido de un descuido evitable

Ninguna de estas prácticas requiere presupuesto. Todas requieren constancia, porque la seguridad psicológica se construye despacio y se pierde en una reunión. Según nuestra experiencia, el indicador más honesto de que el trabajo funciona es el aumento de problemas reportados temprano, no su disminución.