Resolviste el bug que tenía a soporte contestando el mismo ticket hacía tres semanas. Lo hiciste solo, sin pedir ayuda, y el fix quedó mergeado un jueves a las once de la noche. El viernes, en el standup, nadie lo mencionó. Dos semanas después tu manager te pregunta en una 1:1 si estás "enganchado" con el proyecto, porque casi no te ve en las conversaciones del equipo.
Esto le pasa todo el tiempo a devs senior en remoto, y cuanto mejor sos en tu trabajo, más te pasa. Con seis, ocho, diez años de experiencia resolvés las cosas rápido y sin ruido. El problema es que en un equipo distribuido, sin ruido significa invisible. Nadie te ve pensar, nadie te ve iterar, nadie te ve descartar tres soluciones antes de llegar a la buena. Solo ven un PR que apareció y se mergeó.
Mi postura es simple: la visibilidad en remoto no es un tema de personalidad ni de "prender la cámara". Es un problema de información. El equipo toma mejores decisiones cuando sabe qué pensás, qué evaluaste y por qué elegiste lo que elegiste. Si esa información se queda en tu cabeza, el equipo pierde algo real, no solo vos.
Por qué el consejo genérico no te sirve a esta altura
El consejo típico (prendé la cámara, participá en las reuniones, saludá en el canal de la empresa) está pensado para alguien que recién entra y necesita mostrarse aprendiendo. A vos ya no te hace falta demostrar que aprendés rápido. El problema inverso es que como necesitás cada vez menos ayuda, cada vez comunicás menos, y comunicar menos en remoto se lee como estar menos presente, aunque estés rindiendo al máximo.
La solución no es hablar más porque sí. Es hacer visible el trabajo de pensar, que en un senior es la mitad del valor real que aportás.
Documentá las decisiones, no solo el código
Un PR que dice "refactor: nuevo protocolo interno" no cuenta nada. Un PR que dice qué problema resolvía, qué alternativas evaluaste y por qué ganó la que ganó, sí.
Ejemplo concreto: si migraste un servicio interno de REST a gRPC, no alcanza con el diff. Escribí un documento corto (un ADR de una página sirve) donde quede el problema real (latencia de red entre microservicios que estaba afectando un SLA), las alternativas que consideraste (mantener REST con streaming HTTP, usar GraphQL subscriptions, ir a gRPC) y el trade-off que aceptaste a cambio (curva de aprendizaje del equipo, tooling menos maduro en algunos lenguajes). Ese documento vale más para tu carrera que el código en sí, porque es la evidencia de que pensás en sistemas y no solo en tickets.
En Howdy, muchos equipos usan la descripción del PR como si fuera el ADR: contexto, alternativas, decisión, riesgo aceptado. Es gratis, no requiere una herramienta nueva, y queda buscable para siempre.
Convertite en la persona a la que consultan, no en la que solo entrega
Hay una diferencia grande entre resolver problemas en privado y resolverlos donde el equipo puede verlo. Si alguien te escribe por DM con una duda técnica y la respuesta le sirve a más de una persona, respondé en el canal público del equipo, no en el privado. No es un truco de marketing personal, es evitar que otras tres personas pierdan el mismo tiempo la semana que viene.
Lo mismo aplica cuando resolvés algo raro y no trivial: un bug de concurrencia, una race condition en un cron, un edge case en una integración de pagos. Escribí dos párrafos en el wiki interno o en el canal del equipo explicando qué pasó y cómo lo diagnosticaste. Eso te posiciona como la persona que entiende el sistema a fondo, que es exactamente lo que separa a un senior de alguien que simplemente escribe buen código.
Cuantificá tu impacto en vez de listar tareas
Los reportes semanales tipo "trabajé en X, avancé en Y" son ruido. Nadie los lee dos veces. Un reporte que dice "bajé el tiempo de build de 14 a 4 minutos ajustando la caché de Docker, lo que le ahorra unos 45 minutos por día a cada dev del equipo" es información que un manager puede usar, repetir hacia arriba y recordar en tu próxima revisión de compensación.
Esto no es inflar logros. Es traducir trabajo técnico a un lenguaje que el resto de la organización, que no lee tu código, pueda entender y valorar. Si no lo hacés vos, nadie más lo va a hacer por vos.
El límite: no todo necesita un anuncio
Esto no es licencia para llenar el canal general de actualizaciones cada media hora. Hay una diferencia entre visibilidad y ruido, y cruzarla tiene un costo real: si todo lo que compartís es de bajo valor, el equipo aprende a ignorarte cuando de verdad importa.
Reservá la comunicación proactiva para los momentos de mayor apalancamiento: cuando cerrás algo que bloqueaba a otros, cuando detectás un problema de arquitectura antes de que llegue a producción, cuando tomaste una decisión que otro equipo va a heredar. El resto (el trabajo rutinario del día a día) puede ir en tu reporte semanal, sin necesidad de narrarlo en tiempo real.
Nada de esto reemplaza el contacto humano real: de vez en cuando vale la pena aparecer por la oficina si tenés una cerca, porque el vínculo presencial sigue construyendo confianza de una forma que ninguna herramienta async logra igualar. En Howdy tenemos ocho oficinas en Latinoamérica justamente para eso, aunque el trabajo del día a día siga siendo remoto.
La visibilidad en un equipo remoto no se gana actuando más seguro de lo que estás ni participando por participar. Se gana convirtiendo en información compartida el trabajo de pensar que ya hacés todos los días. Si sos la persona que evita que el equipo repita errores y nadie más que vos lo sabe, ese es un problema del equipo, no solo tuyo. Arreglarlo empieza por escribir mejor sobre lo que ya hacés bien, no por hablar más.
