Justificar o resolver
La forma en que pedimos ayuda puede poner a la otra persona a la defensiva o ayudarla a concentrarse en encontrar una solución.
No sé si con los años me he vuelto menos tolerante, o si simplemente hemos normalizado una forma poco útil de pedir ayuda: preguntar primero por qué ocurrió algo, antes de explicar claramente cuál es el problema.
Pensemos en estas dos formas de comunicar la misma situación:
“¿Por qué no funciona el registro de usuarios?”
y
“Observamos que los usuarios no pueden completar el registro desde esta mañana. Ayúdanos a revisarlo.”
Ambas pueden surgir de una preocupación legítima.
Pero no necesariamente provocan la misma reacción en quien las recibe.
La primera puede poner a la otra persona en modo justificar.
La segunda la invita a ponerse en modo resolver.
Y esa diferencia, aunque parezca pequeña, puede cambiar por completo lo que ocurre después.
Las palabras crean el marco de la conversación
Cuando alguien recibe un mensaje que empieza con:
“Necesito que me expliquen por qué pasó esto…”
aunque esa no sea la intención de quien lo escribió, el mensaje puede sentirse como una solicitud de rendición de cuentas.
La primera pregunta que aparece en la mente del receptor puede no ser:
“¿Cómo solucionamos esto?”
Puede ser:
“¿Qué tengo que explicar?”
Y ahí cambia la conversación.
El foco deja de estar en resolver el problema y empieza a estar en construir una explicación.
Lo interesante es que muchas veces quien escribe la solicitud nunca quiso provocar esa reacción. Simplemente necesitaba ayuda.
Pero la persona que recibe el mensaje no puede interpretar intenciones. Solo puede interpretar las palabras que tiene delante.
Por eso la forma de escribir importa.
Una solicitud puede crear un contexto de colaboración o, sin pretenderlo, poner al receptor a la defensiva.
Si necesitas ayuda, facilita que quieran ayudarte
Hay una paradoja en muchas solicitudes.
Necesitamos el conocimiento, la experiencia o la capacidad de otra persona para resolver algo y, sin embargo, comenzamos la conversación de una manera que puede hacer que esa persona sienta que primero tiene que defenderse.
No tiene mucho sentido.
Si necesitas ayuda, tu objetivo debería ser facilitar que la otra persona pueda ayudarte.
Eso no significa ser excesivamente cuidadoso, utilizar fórmulas artificialmente amables o esconder la urgencia.
Significa comunicar el problema de una manera que permita actuar.
En lugar de:
“¿Por qué no funciona el registro de usuarios?”
podemos decir:
“Los usuarios no pueden completar el registro desde esta mañana. El problema está bloqueando las nuevas altas. Ayúdanos a revisarlo.”
La segunda solicitud no es menos exigente.
Es más útil.
Describe lo que ocurre, explica el impacto y establece con claridad qué necesitamos.
No acusa.
No presupone una causa.
No exige una explicación antes de empezar.
Permite que el equipo entre directamente en modo diagnóstico y solución.
No pongas al equipo a defenderse
Esto es especialmente importante cuando hablamos con equipos especializados.
Un equipo de desarrollo no necesita que le indiquemos que investigue una falla. Investigar forma parte de su trabajo.
Lo que necesita es información suficiente para hacerlo.
Cuando una solicitud comienza con una exigencia de explicación, podemos arrastrar al equipo a una conversación que no necesitamos tener todavía.
En lugar de investigar el problema, alguien puede terminar explicando qué ocurrió, qué cambio se hizo, quién lo hizo o por qué se tomó determinada decisión.
Quizá esa información sea necesaria después.
Pero si el sistema está fallando, probablemente no sea lo primero que necesitamos.
No pongas a quien puede ayudarte en una posición donde primero tenga que defenderse.
Si tu objetivo es obtener una solución, construye una conversación que facilite la solución.
Primero resuelve. Después analiza.
Esto no significa que entender las causas no sea importante.
Todo equipo profesional necesita analizar sus fallos.
Encontrar la causa raíz.
Revisar qué decisiones influyeron.
Aprender.
Prevenir recurrencias.
Pero esa es otra conversación.
Cuando un sistema deja de funcionar, normalmente existe una secuencia más útil:
- Reducir el impacto.
- Recuperar el servicio.
- Entender qué ocurrió.
- Corregir la causa.
- Evitar que vuelva a suceder.
A veces será necesario investigar mientras se intenta resolver. Por supuesto.
La idea no es imponer una secuencia rígida.
La idea es no confundir conversaciones diferentes.
Preguntar por qué puede ser perfectamente válido durante una investigación técnica.
Lo que cuestiono es convertir esa pregunta en el punto de partida de una solicitud cuyo objetivo real es conseguir ayuda.
Una regla sencilla
Antes de enviar una solicitud, hazte una pregunta:
¿Esta frase pone a la otra persona en modo justificar o en modo resolver?
Si la respuesta es “justificar”, probablemente podamos escribirla mejor.
En lugar de:
“Necesito que me expliquen por qué pasó esto.”
podemos empezar por:
“Observamos este comportamiento…”
Y añadir tres cosas:
Qué ocurre.
Qué impacto tiene.
Qué ayuda necesitamos.
Eso suele ser suficiente para iniciar una buena conversación.
No necesitamos eliminar el “por qué”.
Necesitamos aprender cuándo y cómo hacerlo.
Porque pedir ayuda también es una forma de colaboración.
Y colaborar implica pensar no solo en lo que queremos obtener, sino también en el contexto que estamos creando para que la otra persona pueda ayudarnos.
Las palabras no solo transmiten información.
También programan el estado mental con el que alguien entra a una conversación.
Una frase puede hacer que alguien piense:
“Tengo que explicar qué pasó.”
O puede hacer que piense:
“Vamos a resolverlo.”
Si lo que necesitas es ayuda, creo que la elección debería ser evidente.
¿Qué opinas sobre este post?
Comentar en XCompartir:
¿Te gustó este artículo? Apoya este blog y ayuda a que siga creciendo.
Invítame un café