Cultura de ingeniería en equipos distribuidos: cómo construirla desde cero
En un equipo que comparte oficina, la cultura de ingeniería se genera sola. Surge en las conversaciones de pasillo, en los debates frente a la pizarra, en las comidas donde alguien menciona un problema y tres personas se ponen a resolverlo. Hay ósmosis. La gente aprende viendo cómo trabajan los demás, absorbiendo decisiones técnicas sin que nadie las documente formalmente.
En un equipo distribuido, nada de eso ocurre. Si no construyes la cultura de forma deliberada, simplemente no existe. Lo que obtienes es un grupo de personas que trabajan en el mismo repositorio pero no comparten principios, no entienden el porqué de las decisiones y no sienten que pertenecen a algo más grande que sus tickets de Jira.
He trabajado con equipos distribuidos en múltiples zonas horarias durante años. Lo que aprendí es que la cultura de ingeniería remota no es una versión degradada de la presencial. Puede ser mejor. Pero requiere intención, estructura y disciplina.
La comunicación escrita como modo por defecto
Este es el pilar más importante y el que más cuesta adoptar. En una oficina, la comunicación oral es eficiente. En un equipo distribuido, es un cuello de botella.
Cuando la comunicación es oral, las decisiones quedan en la cabeza de quienes estuvieron en la llamada. Los que no estuvieron se enteran por rumores o no se enteran. Cuando alguien se va de vacaciones, se pierde contexto. Cuando alguien nuevo se incorpora, tiene que reconstruir meses de decisiones preguntando persona por persona.
La comunicación escrita obliga a ser claro. Si no puedes explicar una decisión técnica por escrito, probablemente no la has pensado lo suficiente.
Herramientas concretas:
- RFCs (Request for Comments): Antes de implementar un cambio significativo, escribe un documento que explique el problema, las alternativas consideradas y la propuesta. El equipo comenta de forma asíncrona. Esto democratiza las decisiones y crea un registro permanente.
- ADRs (Architecture Decision Records): Documentos cortos que capturan decisiones arquitectónicas. Fecha, contexto, decisión, consecuencias. Cualquiera puede entender POR QUÉ se tomó una decisión meses después.
- Standups asíncronos: En lugar de una reunión diaria de 15 minutos que rompe la concentración de todo el equipo, cada persona escribe qué hizo, qué va a hacer y si tiene algún bloqueo. Un mensaje en Slack o un post en Linear. Lleva 2 minutos y queda documentado.
La ventaja añadida: cuando todo está escrito, los ingenieros en diferentes zonas horarias pueden contribuir sin esperar a que alguien se despierte.
El code review como mentoría, no como aduana
El code review es donde la cultura de ingeniería se manifiesta de forma más visible. En equipos distribuidos, es prácticamente el único momento en que un ingeniero senior interactúa directamente con el código de un junior.
La diferencia entre un equipo con cultura sólida y uno sin ella se ve en los comentarios de review:
- Cultura débil: "Esto está mal. Cámbialo." o simplemente un "LGTM" sin leer el código.
- Cultura sólida: "Esto funciona, pero considera usar X porque Y. Aquí tienes un ejemplo de cómo lo resolvimos en el servicio Z."
Los comentarios de review deberían explicar el PORQUÉ, no solo el QUÉ. Un review que dice "añade un índice aquí" enseña menos que uno que dice "sin un índice, esta consulta hará un full table scan cuando la tabla crezca. Considera añadir un índice compuesto en (user_id, created_at) porque la mayoría de queries filtran por usuario y ordenan por fecha."
Para que esto funcione en equipos distribuidos:
- Define expectativas claras de tiempo de review (por ejemplo, primer comentario en menos de 24 horas).
- Usa etiquetas de severidad en los comentarios: "nit" para estilo, "suggestion" para mejoras opcionales, "blocker" para problemas reales.
- Fomenta que los ingenieros junior también revisen código de seniors. No tienen que aprobarlo, pero leer código senior y hacer preguntas es una de las mejores formas de aprender.
Estándares compartidos: elimina los debates subjetivos
Nada destruye más rápido la dinámica de un equipo distribuido que las discusiones sobre tabs vs. spaces, comillas simples vs. dobles, o cómo nombrar una variable. Cada debate subjetivo en un PR es tiempo perdido y fricción innecesaria.
La solución: automatiza todo lo que sea cuestión de opinión.
- Linting y formateo automáticos: ESLint, Prettier, Black, gofmt. Configúralo una vez, intégralo en CI, y no vuelvas a discutir sobre formato.
- Convenciones de naming: Define si usáis camelCase o snake_case, cómo nombráis los endpoints, cómo estructuráis los directorios. Documéntalo en un CONTRIBUTING.md.
- Plantillas de PR: Que incluyan descripción del cambio, tipo de cambio, cómo probarlo y capturas de pantalla si es UI. Esto estandariza la información que todo reviewer necesita.
- Definición de "hecho": Tests escritos, documentación actualizada, migración reversible, feature flag si es un cambio grande.
Cuando las decisiones subjetivas están automatizadas o documentadas, los code reviews se centran en lo que importa: lógica, arquitectura, edge cases.
Si una decisión no está escrita, se pierde
En una oficina, puedes preguntar al CTO por qué se eligió PostgreSQL en vez de MongoDB. En un equipo distribuido, si esa decisión no está escrita, se pierde.
Los Architecture Decision Records (ADRs) son la herramienta más infravalorada para equipos distribuidos. Son documentos simples con una estructura fija:
- Título: ADR-001: Usar PostgreSQL como base de datos principal
- Estado: Aceptado
- Contexto: Necesitamos una base de datos que soporte transacciones ACID y relaciones complejas.
- Decisión: PostgreSQL por su madurez, soporte de JSON y ecosistema.
- Consecuencias: Tendremos que gestionar migraciones. No tendremos la flexibilidad de esquema de una base de datos documental.
El poder de los ADRs es que permiten a cualquier ingeniero, incluido uno que se incorpore seis meses después, entender no solo QUÉ se decidió sino POR QUÉ. Esto reduce drásticamente las preguntas repetitivas y los intentos de reabrir decisiones que ya se tomaron con toda la información sobre la mesa.
La seguridad psicológica en remoto no surge sola
La seguridad psicológica es difícil de construir en persona. En remoto, lo es todavía más. Cuando no ves las caras de tus compañeros, es fácil asumir lo peor. Un mensaje corto en Slack se interpreta como enfado. Un PR rechazado se siente como un ataque personal.
Prácticas que funcionan:
- Preguntas en canales públicos, no en DMs. Si alguien tiene una duda, es probable que otros también la tengan. Preguntar en público normaliza no saber algo y crea una base de conocimiento donde buscar.
- Post-mortems sin culpables. Cuando algo falla en producción, el foco debe estar en qué procesos fallaron, no en quién cometió el error. "¿Qué podemos cambiar para que esto no vuelva a ocurrir?" en lugar de "¿quién hizo el deploy?"
- Celebrar los bugs cazados a tiempo. Cuando alguien detecta un bug en una review, celébralo públicamente. Estás reforzando que encontrar problemas antes de producción es exactamente lo que quieres.
Los anti-patrones que destruyen la cultura remota
Si estás haciendo alguna de estas cosas, estás construyendo una cultura de desconfianza:
- Herramientas de vigilancia: Software que hace capturas de pantalla o registra la actividad del teclado. Si necesitas vigilar a tu equipo, tu problema es de contratación, no de monitorización.
- Cámara obligatoria en todas las reuniones. Algunas reuniones se benefician del vídeo. Exigir la cámara encendida en la standup diaria es agotador e invasivo.
- Medir horas en lugar de resultados. A nadie le importa si un ingeniero trabaja de 9 a 17 o de 11 a 19 con una pausa de 2 horas al mediodía. Lo que importa es si entrega código de calidad a tiempo.
- "¿Hacemos una llamada rápida?" para todo. Cada llamada no planificada rompe la concentración de alguien. La mayoría de las cosas se resuelven mejor con un mensaje bien escrito que con una llamada de 30 minutos.
Rituales que sí funcionan
No todos los rituales presenciales se trasladan bien al remoto. Estos sí:
- Tech talks semanales. 30 minutos donde alguien presenta un tema técnico. Puede ser algo que aprendió, un problema que resolvió, una herramienta nueva. Rotativo y voluntario.
- Sesiones de pair programming. No como obligación, sino como recurso disponible. "¿Alguien quiere hacer pair en este problema? Llevo 2 horas atascado." Funciona especialmente bien durante el onboarding.
- Retrospectivas centradas en el proceso. Cada 2 semanas, qué funcionó, qué no, qué cambiar. El foco debe estar en los procesos, no en las personas.
Cómo funciona esto con ingenieros externos
Si trabajas con ingenieros que no son empleados directos, todo lo anterior cobra aún más importancia. Un ingeniero externo que se incorpora sin documentación, sin estándares claros y sin canales de comunicación abiertos va a tardar semanas en ser productivo.
En Conectia, nuestros ingenieros se integran en TU cultura, no al revés. Pero eso solo funciona si tienes una cultura definida. Cuando trabajamos con startups europeas, lo primero que evaluamos es si existen la infraestructura de comunicación y los procesos necesarios para que un ingeniero remoto senior sea productivo desde la primera semana.
Si no existen, ayudamos a construirlos. Porque un ingeniero senior de LATAM con experiencia en equipos distribuidos no solo escribe buen código: trae prácticas probadas de comunicación asíncrona, documentación técnica y code review que elevan el nivel del equipo entero.
La cultura de ingeniería distribuida no se compra. Se construye. Pero se construye mucho más rápido cuando tienes gente que ya ha pasado por el proceso antes.
¿Estás construyendo un equipo distribuido y no sabes por dónde empezar con la cultura de ingeniería? Habla con un CTO — te ayudamos a definir procesos y a integrar ingenieros senior que ya saben trabajar así.
