Cultura d'Enginyeria en Equips Distribuïts: Com Construir-la des de Zero

En un equip co-localitzat, la cultura d'enginyeria es genera sola. Sorgeix a les converses de passadís, als debats davant la pissarra, als dinars on algú menciona un problema i tres persones es posen a resoldre'l. Hi ha osmosi. La gent aprèn veient com treballen els altres, absorbint decisions tècniques sense que ningú les documenti formalment.

En un equip distribuït, res d'això passa. Si no construeixes la cultura de forma deliberada, simplement no existeix. El que obtens és un grup de persones que treballen al mateix repositori però no comparteixen principis, no entenen el perquè de les decisions i no senten que pertanyen a alguna cosa més gran que els seus tickets de Jira.

He treballat amb equips distribuïts en múltiples zones horàries durant anys. El que vaig aprendre és que la cultura d'enginyeria remota no és una versió degradada de la presencial. Pot ser millor. Però requereix intenció, estructura i disciplina.

La comunicació escrita com a mode per defecte

Aquest és el pilar més important i el que més costa adoptar. En una oficina, la comunicació oral és eficient. En un equip distribuït, és un coll d'ampolla.

Quan la comunicació és oral, les decisions queden al cap de qui va ser a la trucada. Qui no hi era s'assabenta per rumors o no se n'assabenta. Quan algú se'n va de vacances, es perd context. Quan algú nou s'incorpora, ha de reconstruir mesos de decisions preguntant persona per persona.

La comunicació escrita força claredat. Si no pots explicar una decisió tècnica per escrit, probablement no l'has pensada prou.

Eines concretes:

• RFCs (Request for Comments): Abans d'implementar un canvi significatiu, escriu un document que expliqui el problema, les alternatives considerades i la proposta. L'equip comenta de forma asíncrona. Això democratitza les decisions i crea un registre permanent.
• ADRs (Architecture Decision Records): Documents curts que capturen decisions arquitectòniques. Data, context, decisió, conseqüències. Qualsevol pot entendre PER QUÈ es va prendre una decisió mesos després.
• Standups asíncrons: En lloc d'una reunió diària de 15 minuts que interromp el focus, cada persona escriu què va fer, què farà i si té algun bloqueig. Un missatge a Slack o un post a Linear. Porta 2 minuts i queda documentat.

El benefici col·lateral: quan tot està escrit, els enginyers en zones horàries diferents poden contribuir sense esperar que algú es desperti.

Code review com a mentoria, no com a barrera

El code review és on la cultura d'enginyeria es manifesta de forma més visible. I en equips distribuïts, és pràcticament l'únic moment on un enginyer sènior interactua directament amb el codi d'un júnior.

La diferència entre un equip amb bona cultura i un sense es veu als comentaris de review:

• Cultura pobre: "Això està malament. Canvia-ho." o simplement un "LGTM" sense llegir el codi.
• Cultura bona: "Això funciona, però considera fer servir X perquè Y. Aquí tens un exemple de com ho vam resoldre al servei Z."

Els comentaris de review haurien d'explicar el PER QUÈ, no només el QUÈ. Un review que diu "fes servir un índex aquí" ensenya menys que un que diu "sense un índex, aquesta consulta farà un full table scan quan la taula creixi. Considera afegir un índex compost en (user_id, created_at) perquè la majoria de queries filtren per usuari i ordenen per data."

Perquè això funcioni en equips distribuïts:

• Defineix expectatives clares de temps de review (ex: menys de 24 hores per a un primer comentari).
• Fes servir etiquetes de severitat als comentaris: "nit" per estil, "suggestion" per millores opcionals, "blocker" per problemes reals.
• Fomenta que els enginyers júnior també revisin codi de sèniors. No han d'aprovar, però llegir codi sènior i fer preguntes és una de les millors maneres d'aprendre.

Estàndards compartits: elimina els debats subjectius

Res destrueix més la dinàmica d'un equip distribuït que les discussions sobre tabs vs. spaces, cometes simples vs. dobles, o com anomenar una variable. Cada debat subjectiu en un PR és temps perdut i fricció innecessària.

La solució: automatitza tot el que sigui opinió.

• Linting i formatatge automàtic: ESLint, Prettier, Black, gofmt. Configura-ho un cop, integra-ho a CI, i mai més discuteixis sobre format.
• Convencions de naming: Defineix si fas servir camelCase o snake_case, com anomenes els endpoints, com estructures els directoris. Documenta-ho en un CONTRIBUTING.md.
• Templates de PR: Que incloguin descripció del canvi, tipus de canvi, com provar-ho, screenshots si és UI. Això estandarditza la informació que tot reviewer necessita.
• Definició de "fet": Tests escrits, documentació actualitzada, migration reversible, feature flag si és un canvi gran.

Quan les decisions subjectives estan automatitzades o documentades, els code reviews se centren en el que importa: lògica, arquitectura, edge cases.

Transparència de decisions

En una oficina, pots preguntar al CTO per què es va triar PostgreSQL en lloc de MongoDB. En un equip distribuït, si aquella decisió no està escrita, es perd.

Els Architecture Decision Records (ADRs) són l'eina més infravalorada per a equips distribuïts. Són documents simples amb una estructura fixa:

1. Títol: ADR-001: Usar PostgreSQL com a base de dades principal
2. Estat: Acceptat
3. Context: Necessitem una base de dades que suporti transaccions ACID i relacions complexes.
4. Decisió: PostgreSQL per la seva maduresa, suport de JSON, i ecosistema.
5. Conseqüències: Haurem de gestionar migracions. No tindrem la flexibilitat d'esquema d'un document store.

El poder dels ADRs és que permeten a qualsevol enginyer, inclòs un que s'incorpori sis mesos després, entendre no només QUÈ es va decidir sinó PER QUÈ. Això redueix dràsticament les preguntes repetitives i els intents de relitigar decisions que ja van ser preses amb informació completa.

Seguretat psicològica en remot

La seguretat psicològica és difícil de construir en persona. En remot, és encara més difícil. Quan no veus les cares dels teus companys, és fàcil assumir el pitjor. Un missatge curt a Slack s'interpreta com a enfadament. Un PR rebutjat es percep com un atac personal.

Pràctiques que funcionen:

• Preguntes a canals públics, no a DMs. Si algú té un dubte, és probable que altres també el tinguin. Preguntar en públic normalitza no saber alguna cosa i crea una base de coneixement cercable.
• Post-mortems sense culpables. Quan alguna cosa falla en producció, el focus ha d'estar en quins processos van fallar, no en qui va cometre l'error. "Què podem canviar perquè això no torni a passar?" en lloc de "qui va fer el deploy?"
• Celebrar les bones captures. Quan algú detecta un bug en review, celebra-ho públicament. Estàs reforçant que trobar problemes abans de producció és exactament el que vols.

Els anti-patrons que destrueixen la cultura remota

Si estàs fent alguna d'aquestes coses, estàs construint una cultura de desconfiança:

• Eines de vigilància: Programari que fa screenshots o rastreja activitat del teclat. Si necessites vigilar el teu equip, el teu problema és de contractació, no de monitoratge.
• Càmera obligatòria a totes les reunions. Algunes reunions es beneficien de vídeo. Obligar càmera a una standup diària és esgotador i invasiu.
• Mesurar hores en lloc d'output. A ningú li importa si un enginyer treballa de 9 a 17 o d'11 a 19 amb una pausa de 2 hores al migdia. El que importa és si lliura codi de qualitat a temps.
• "Pots saltar a una call ràpida?" per a tot. Cada trucada no planificada interromp el focus d'algú. La majoria de les coses es resolen millor amb un missatge ben escrit que amb una trucada de 30 minuts.

Rituals que sí funcionen

No tots els rituals presencials es tradueixen bé al remot. Aquests sí:

• Tech talks setmanals. 30 minuts on algú presenta un tema tècnic. Pot ser alguna cosa que va aprendre, un problema que va resoldre, una eina nova. Rotatiu i voluntari.
• Sessions de pair programming. No com a obligació, sinó com a recurs disponible. "Algú vol fer pair en aquest problema? Porto 2 hores encallat." Funciona especialment bé en onboarding.
• Retrospectives enfocades en procés. Cada 2 setmanes, què va funcionar, què no, què canviar. El focus ha d'estar en els processos, no en les persones.

Com funciona això amb enginyers externs

Si treballes amb enginyers que no són empleats directes, tot l'anterior cobra més importància. Un enginyer extern que s'incorpora sense documentació, sense estàndards clars i sense canals de comunicació oberts trigarà setmanes a ser productiu.

A Conectia, els nostres enginyers s'integren a la TEVA cultura, no al revés. Però això només funciona si tens una cultura definida. Quan treballem amb startups europees, el primer que avaluem és si existeix la infraestructura de comunicació i processos necessària perquè un enginyer remot sènior sigui productiu des de la primera setmana.

Si no existeix, ajudem a construir-la. Perquè un enginyer sènior de LATAM amb experiència en equips distribuïts no només escriu bon codi, sinó que porta pràctiques provades de comunicació asíncrona, documentació tècnica i code review que eleven l'equip sencer.

La cultura d'enginyeria distribuïda no es compra. Es construeix. Però es construeix molt més ràpid quan tens gent que ja ha passat pel procés abans.

---

Estàs construint un equip distribuït i no saps per on començar amb la cultura d'enginyeria? Parla amb un CTO — t'ajudem a definir processos i a integrar enginyers sènior que ja saben treballar així.