La mayoría de los problemas de comunicación en el trabajo no son por mala intención. La causa más común es más simple: falta de contexto, dar por sentado que la otra persona sabe lo que vos tenés en la cabeza.
Alguien manda un mensaje dando por hecho su propio contexto, pero se olvida de que del otro lado hay una persona que no sabe nada de lo que está pensando. Y ahí empieza el ida y vuelta innecesario, las preguntas que no deberían existir, el tiempo perdido.
Hoy gran parte de cómo trabajamos pasa por lo escrito: chat, tickets, documentos, mails. Por eso este post se enfoca ahí, que es donde más se cuela la fricción, aunque varias de estas ideas sirvan para comunicar mejor en general.
La buena noticia es que casi todos estos errores se arreglan con pequeños hábitos. Los agrupé en cinco frentes para que sea más fácil quedarse con la idea.
1. Cuidá la atención del otro
Cada interrupción tiene un costo. Estos puntos son para no gastar la atención de la otra persona más de lo necesario.
La regla del “no hello”
Este es el clásico. Alguien te escribe:
Compañero: Hola
Y nada más. Vos respondés “hola”, y recién ahí, cuando ya estás esperando, te tiran la pregunta real.
El problema es que ese “hola” suelto no comunica nada. Te interrumpe, te pone en modo espera y te obliga a estar pendiente de una conversación que todavía no empezó. Si en ese momento estabas concentrado en otra cosa, te sacó de foco para nada.
La alternativa es simple: saludá y hacé tu pregunta en el mismo mensaje.
Compañero: Hola, ¿sabés si el deploy a producción quedó configurado para correr automático o hay que dispararlo a mano?
Así, la otra persona puede leer tu mensaje cuando le quede cómodo, entender de qué se trata y responderte cuando tenga la respuesta. Sin esperas, sin interrupciones de más.
Hay hasta una página dedicada a esto: nohello.net. Vale la pena compartirla cuando alguien cae en la trampa.
Un mensaje, no diez
Muy relacionado con lo anterior. Hay gente que escribe así:
Compañero: Che
Compañero: estuve mirando lo del bug
Compañero: y creo que es por el cache
Compañero: ¿lo vemos en un rato?
Cuatro mensajes para una sola idea. Y cada uno de esos mensajes es una notificación. Y cada notificación es una distracción que saca a la otra persona de lo que estaba haciendo.
La solución es ridículamente fácil: en vez de apretar Enter cada vez que terminás una frase, usá Shift + Enter para separar párrafos dentro del mismo mensaje, y mandalo todo junto al final.
Compañero: Che, como estas?
Estuve mirando lo del bug y creo que es por el cache. ¿Lo vemos en un rato?
Por cierto, mañana estoy off por mudanza.
Un mensaje, una notificación.
Eso sí, cuidado con el otro extremo. Tampoco mandes una pared de texto: un bloque gigante de diez líneas sin un solo salto. Es igual de difícil de leer, y lo que cuesta leer, la gente lo posterga. Para eso están esos mismos Shift + Enter: separá las ideas en párrafos cortos dentro del mismo mensaje.
Elegí el canal según el caso
No todo va al chat. Cuando un tema empieza a llevar muchas idas y vueltas, a veces una llamada de cinco minutos resuelve lo que veinte mensajes no. Otras cosas piden un mail, un documento o un ticket.
Parte de comunicar bien es elegir el medio: lo urgente y simple, un mensaje; lo que necesita discusión, una llamada; lo que tiene que quedar registrado, un doc o un ticket. Saber cuándo pasar de lo asincrónico a lo sincrónico, y al revés, ahorra muchísimo tiempo y malentendidos.
Hacé tu tarea antes de preguntar
Antes de interrumpir a alguien, fijate si podés resolverlo solo: buscá en la documentación, googleá, revisá si ya se preguntó antes, probá un poco. Un montón de preguntas se responden con dos minutos de búsqueda.
Y si después de eso seguís trabado, preguntá, pero contá lo que ya intentaste. No es lo mismo esto:
No anda el login.
Que esto:
El login tira 401 con el usuario “qa_user”. Ya probé regenerar el token y revisar la config, y sigue igual.
Lo segundo respeta el tiempo del otro y, de paso, hace que te puedan ayudar mucho más rápido.
La diferencia es usar a la otra persona como último recurso, no como tu buscador personal.
2. Hacé que se entienda de un saque
Que la otra persona capte la idea sin esfuerzo y sin malinterpretarte.
Aprovechá las herramientas de formato
Todas las herramientas que usamos para comunicarnos (el chat, los tickets, la documentación) tienen opciones de formato: negritas, itálicas, subrayados, bullets, encabezados, tablas, imagenes. Y casi nadie las usa.
Es una lástima, porque ayudan muchísimo a transmitir una idea. Una negrita resalta lo importante de un mensaje largo. Una lista con bullets ordena puntos que en prosa se mezclan. Un encabezado separa temas distintos de un vistazo.
Compará estos dos mensajes con la misma información:
Para el release necesitamos que actualices la variable de entorno, corras las migraciones y avises en el canal de QA cuando esté listo, ah y acordate que el deploy es a las 18.
Para el release necesito que hagas:
- Actualizar la variable de entorno
- Correr las migraciones
- Avisar en el canal de QA cuando esté listo
El deploy es a las 18 hs.
Misma información, pero el segundo se entiende de un saque y deja menos lugar a que se te escape un paso. Darle forma al mensaje es parte de comunicarlo bien.
Usá emojis para setear expectativas
Un emoji bien puesto comunica antes de que la otra persona siquiera lea una palabra.
Si los tests pasaron, un ✅ o 🟢 al principio del mensaje ya te baja la ansiedad: sabés que es una buena noticia antes de leer el detalle. Si algo es urgente o requiere atención, un 🚨 al arranque hace que el ojo vaya directo ahí y que no se pierda entre otros mensajes.
✅ Los tests de la branch de release pasaron exitosamente.
🚨 Ojo, el deploy de las 18 hs queda en pausa hasta que validemos el fix del login.
El emoji funciona como una etiqueta visual: clasifica el mensaje de un vistazo y setea el tono. Eso sí, con criterio. Si todo lleva 🚨, nada es urgente; y un mensaje lleno de emojis de colores transmite lo contrario a lo que buscás.
Links embellecidos, no en crudo
Pegar una URL cruda en medio de un mensaje es feo y difícil de leer:
Como vimos en https://docs.tuempresa.com/guias/onboarding/setup-entorno-local conviene arrancar por ahí.
Donde la herramienta te lo permita, poné el link sobre una palabra o frase:
Como vimos en esta guía de setup, conviene arrancar por ahí.
Se lee mejor, ocupa menos y el texto del link le dice a la otra persona qué va a encontrar antes de hacer clic.
Cuidá el tono
En lo escrito no hay cara, ni voz, ni gestos. Un mensaje cortito y directo que en persona sonaría de lo más normal, por escrito puede leerse seco u hostil sin que esa haya sido tu intención.
Un “ok.” con punto puede sonar molesto. Un “no” pelado puede sonar cortante. No hace falta endulzar todo ni llenar de signos de exclamación, pero un poco de calidez o de contexto evita malentendidos: un “dale, gracias” en vez de un “ok” seco, una línea que aclare que no estás enojado, simplemente ocupado.
Releé pensando en cómo le va a sonar a alguien que no te ve la cara mientras lo escribís.
Adaptá el mensaje a quién te lee
No le hablás igual a otro desarrollador que a alguien de negocio o a un cliente. El mismo mensaje técnico que para tu equipo es perfecto, para un stakeholder no técnico puede ser chino básico.
Antes de mandar, pensá qué sabe y qué le importa a esa persona, y traducí lo técnico a eso. Imaginá que tenés que reportar este problema:
Hay un memory leak en el worker de imágenes.
Para otro desarrollador ese mensaje es perfecto. Pero a alguien de negocio no le dice nada: no sabe qué es un worker ni por qué debería importarle. Para esa persona funciona mucho mejor algo así:
El procesamiento de imágenes se cae cada un par de horas y por eso algunos usuarios no ven sus fotos. Ya estamos trabajando en el fix.
Misma realidad, contada para quien la lee.
3. Dá el contexto necesario
El error de fondo del que hablábamos al principio. Que la otra persona tenga todo para responderte sin tener que pedirte más.
Anticipate a la pregunta
Antes de mandar algo, pensá qué te va a preguntar la otra persona cuando lo lea. Y respondelo de una.
La mayoría de los mensajes que generan ida y vuelta son fáciles de detectar si te ponés un segundo en el lugar del que recibe.
Probé el ticket y encontré este error.
Apenas lea eso, te va a preguntar: ¿en qué ambiente? ¿con qué usuario? ¿qué pasos hiciste? Todo eso son mensajes de ida y vuelta que podrías haberte ahorrado.
Probé el ticket en el ambiente de staging, con el usuario de test “qa_user”, siguiendo los pasos del caso 3, y encontré este error.
Mismo esfuerzo de tu lado, pero ahora la otra persona tiene todo para ayudarte sin tener que sacarte la información a cuentagotas.
El poder de la simplificación
Recién te dije que agregues contexto y te anticipes a las preguntas. Pero hay un equilibrio, y este es el otro lado de la balanza.
Saber resumir es un arte, y de los más valiosos. Quedarte con lo esencial, sacar el ruido y dejar solo lo que la otra persona necesita para entender, es difícil y se nota cuando alguien lo hace bien.
Hay una frase que lo resume perfecto:
Te escribo una carta larga porque no tengo tiempo de escribirte una corta.
Blaise Pascal
Suena paradójico, pero es exacto: sintetizar lleva más trabajo que largar todo lo que se te viene a la cabeza. La diferencia es que ese laburo lo hacés una vez vos, en lugar de repartirlo entre todos los que después tienen que leerte.
El truco está en no pasarse para ningún lado. Si simplificás de más, perdés información necesaria y caés de nuevo en el ida y vuelta. Si agregás de más, enterrás lo importante abajo de un montón de detalle que nadie pidió y volvés a la pared de texto.
El punto justo es ese: la información necesaria, ni más ni menos.
Una buena forma de chequearlo es releer lo que escribiste antes de mandarlo y preguntarte qué podés sacar sin perder sentido. Casi siempre sobra algo.
Si mencionás un ticket, decime cuál
Otro muy frecuente. Te escriben algo como:
Compañero: ¿Pudiste avanzar con el ticket que te pasé?
¿Cuál ticket? Capaz me pasaste tres esta semana. Capaz fue hace diez días. Capaz ni me acuerdo de la conversación.
Ahora tengo que frenar lo que estoy haciendo para o bien preguntarte cuál es, o bien ir a buscarlo yo: revisar el board, scrollear el chat, abrir el gestor de tickets. Todo ese trabajo para reconstruir un contexto que vos ya tenías y podrías haber compartido en dos segundos.
Cuando menciones un ticket, decí cuál es. Y si podés, sumá el link directo. Mejor todavía.
Compañero: ¿Pudiste avanzar con el ticket PROJ-482, el del bug de login en mobile?
El link me lleva directo a donde tengo que ir. El número me sirve de referencia. Y la descripción corta me ubica al instante, sin siquiera tener que abrirlo. Tres segundos tuyos me ahorran varios minutos míos.
En las capturas, mostrá el contexto y señalá
Una captura recortada justo en el botón del que querés hablar parece prolija, pero muchas veces deja afuera lo más importante: dónde estás parado.
Mandá una captura más amplia, donde se vea la URL, la pantalla completa, el contexto. Eso solo ya responde un montón de preguntas implícitas: en qué ambiente estás, en qué parte de la app, con qué datos.
Pero hay algo todavía más importante: señalá la sección de la que estás hablando. Una captura tiene mil cosas: botones, links, menús, información por todos lados. Si no me marcás exactamente qué tengo que mirar con una flecha o un recuadro, pierdo tiempo buscando a qué te referís, y capaz ni lo encuentro.
Contexto amplio para ubicarme, y una marca clara para no perderme. Las dos cosas.
4. Dejá rastro para el futuro
Lo que escribís hoy puede servirle a alguien mañana, o a vos mismo en seis meses. Que se pueda encontrar.
Público mejor que privado
Un error muy común es resolver todo por mensajes privados. El problema es que lo que se habla ahí no deja historia: muere en ese chat, no lo puede encontrar nadie más, y muchas veces ni vos lo volvés a encontrar.
Todo lo que pueda ser útil para otros debería vivir en el lugar más público posible: el canal del equipo, el ticket, la documentación. No el privado.
Pensalo así: más de una vez me sirvió un mensaje que alguien escribió hace tres años en un canal para entender algo. Quién te dice que el mensaje que mandás hoy le sirva a alguien dentro de tres años, cuando capaz vos ya ni estés en el proyecto.
Lo privado se pierde. Lo público queda.
Escribí pensando en el buscador
Tarde o temprano vas a estar buscando un mensaje viejo, propio o de otro, y no lo vas a encontrar. Escribí pensando en ese momento.
Dale contexto a lo que mandás y llamá a las cosas por su nombre: el del servicio, el del ticket, el del error puntual. Esas son las palabras que alguien (capaz vos) va a tipear en el buscador después.
Y cuidá la ortografía. No por formalismo, sino porque un typo puede hacer que un mensaje sea imposible de encontrar: si lo escribiste mal, no va a aparecer cuando lo busques bien.
5. Hacé que las cosas avancen
Comunicar no es solo informar: muchas veces es destrabar algo. Que la conversación termine en una acción, no en el aire.
Cerrá el loop
Si abriste algo, cerralo. Pediste ayuda y lo resolviste: contá cómo. Reportaste un bug: avisá cuando esté arreglado. Dejaste una pregunta picando: dá el desenlace.
Los hilos que quedan abiertos dejan a todos con la duda de en qué terminó la cosa, y el que te ayudó muchas veces se queda con ganas de saber si funcionó. Cerrar el loop, aunque sea con un “listo, era un tema de permisos, ya quedó”, además deja la respuesta registrada para el próximo que caiga en lo mismo.
Sabé quién decide, y facilitale la decisión
Muchas conversaciones se traban no porque falte información, sino porque no está claro quién tiene que tomar la decisión.
Hay decisiones de todo tipo, y cada una le corresponde a alguien distinto: una cuestión técnica del equipo, una de prioridades del product owner, una de presupuesto de quien maneja la plata. Saber quién decide qué evita dos errores muy comunes: tomar una decisión que no te tocaba, o quedarte trabado esperando una respuesta de alguien que ni sabía que la pelota estaba de su lado.
Y cuando le llevás una decisión a quien corresponde, no le tires el problema crudo y listo. Eso lo obliga a arrancar de cero. En vez de eso, planteá el problema y acercá un par de posibles soluciones.
No sé cómo guardar las imágenes que suben los usuarios. ¿Qué hacemos?
Tenemos que definir dónde guardar las imágenes que suben los usuarios.
Veo dos opciones:
- A) S3, más simple de integrar pero nos ata a AWS;
- B) un bucket propio, más laburo al principio pero más control.
Me inclino por la A por tiempos. ¿Cómo lo ves?
Ojo, la idea no es decidir vos y avisar, sino facilitarle la decisión a quien le toca. Que elija con una de tus sugerencias, o con otra que vos no habías visto. Le ahorrás todo el trabajo de entender el problema desde cero y, de paso, la conversación avanza mucho más rápido.
El hilo común: hacele el camino fácil al otro
Si te fijás, todos estos puntos son la misma idea con distinto disfraz.
El contexto es responsabilidad de quien manda el mensaje, no de quien lo recibe.
Antes de enviar algo, vale la pena hacerse una pregunta rápida: si yo fuera la otra persona y me llega esto, ¿tengo todo lo que necesito para responder, o voy a tener que preguntar, ir a buscar algo o adivinar?
No se trata de escribir testamentos. Un buen mensaje no es el más largo, es el que se puede responder sin tener que pedir más datos.
Y esto importa más de lo que parece. Cada mensaje incompleto genera una interrupción, y las interrupciones son caras: rompen la concentración y cuesta retomar. Multiplicá eso por todo un equipo, todos los días, y el costo es enorme. Encima, hoy gran parte del trabajo es asincrónico, con equipos distribuidos y husos horarios distintos. Un mensaje que se puede responder sin ida y vuelta hace que las cosas avancen; uno incompleto puede frenar algo hasta el día siguiente solo porque faltaba un dato.
Comunicar bien no es ser formal ni escribir lindo. Es hacerle el camino fácil a la otra persona.