Cultura d'enginyeria en equips distribuïts: com construir-la des de zero

En un equip que comparteix oficina, la cultura d'enginyeria es fa sola. Neix a les converses de passadís, als debats davant la pissarra, als dinars on algú esmenta un problema i tres persones s'hi llancen a resoldre'l. Hi ha osmosi. La gent aprèn mirant com treballen els altres, absorbint decisions tècniques sense que ningú les documenti formalment.

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

Fa anys que treballo amb equips distribuïts repartits en diverses zones horàries. El que n'he après és que la cultura d'enginyeria en remot no és una versió degradada de la presencial. Pot ser millor. Però demana 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 viuen al cap dels qui eren a la trucada. Els qui no hi eren se n'assabenten de retruc, o no se n'assabenten mai. Quan algú marxa de vacances, es perd context. Quan algú nou s'incorpora, ha de reconstruir mesos de decisions preguntant d'una persona a una altra.

La comunicació escrita obliga a ser clar. Si no pots explicar una decisió tècnica per escrit, probablement és que 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 trenca la concentració de tothom, cada persona escriu què ha fet, què farà i si té algun bloqueig. Un missatge a Slack o un post a Linear. Són dos minuts, i queda documentat.

El benefici col·lateral: quan tot està escrit, els enginyers de 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 el lloc on la cultura d'enginyeria es fa més visible. En equips distribuïts, és pràcticament l'únic moment en què un enginyer sènior toca directament el codi d'un júnior.

La diferència entre un equip amb cultura sòlida i un que no en té es veu als comentaris de review:

• Cultura feble: «Això està malament. Canvia-ho.» O un «LGTM» sense haver llegit el codi.
• Cultura sòlida: «Això funciona, però planteja't fer servir X perquè Y. Aquí tens un exemple de com ho vam resoldre al servei Z.»

Els comentaris de review han d'explicar el PER QUÈ, no només el QUÈ. Una review que diu «afegeix un índex aquí» ensenya menys que una que diu «sense índex, aquesta consulta farà un full table scan a mesura que la taula creixi. Valora afegir un índex compost sobre (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 resposta a les reviews (per exemple, primer comentari en menys de 24 hores).
• Fes servir etiquetes de severitat als comentaris: «nit» per a l'estil, «suggestion» per a millores opcionals, «blocker» per a problemes de debò.
• Anima els enginyers júnior a revisar també codi dels sèniors. No cal que l'aprovin, però llegir codi sènior i fer-hi preguntes és una de les millors maneres d'aprendre.

Estàndards compartits: elimina els debats subjectius

Res no destrueix tan de pressa la dinàmica d'un equip distribuït com les discussions sobre tabs o espais, cometes simples o 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 qüestió d'opinió.

• Linting i formatatge automàtics: ESLint, Prettier, Black, gofmt. Configura-ho un cop, integra-ho al CI i no tornis a discutir mai més sobre format.
• Convencions de naming: Decideix si feu servir camelCase o snake_case, com anomeneu els endpoints, com estructureu els directoris. Documenta-ho en un CONTRIBUTING.md.
• Plantilles de PR: Que incloguin la descripció del canvi, el tipus de canvi, com provar-lo i captures de pantalla si és UI. Així s'estandarditza la informació que tot reviewer necessita.
• Definició de «fet»: Tests escrits, documentació actualitzada, migració 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: la lògica, l'arquitectura, els edge cases.

Una decisió que no s'escriu és una decisió que es perd

En una oficina, pots preguntar al CTO per què va triar PostgreSQL i no 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: Fer servir PostgreSQL com a base de dades principal
2. Estat: Acceptat
3. Context: Necessitem una base de dades que admeti transaccions ACID i relacions complexes.
4. Decisió: PostgreSQL, per la maduresa, el suport de JSON i l'ecosistema.
5. Conseqüències: Haurem de gestionar migracions. No tindrem la flexibilitat d'esquema d'un document store.

La força dels ADRs és que permeten a qualsevol enginyer, també al que s'incorpora sis mesos més tard, entendre no només QUÈ es va decidir sinó PER QUÈ. Això redueix dràsticament les preguntes repetitives i els intents de reobrir decisions que ja s'havien pres amb tota la informació sobre la taula.

En remot, la seguretat psicològica no surt sola

La seguretat psicològica ja costa de construir en persona. En remot, encara costa més. Quan no veus la cara dels companys, és fàcil posar-se en el pitjor. Un missatge curt a Slack es llegeix com a enuig. Un PR rebutjat se sent com un atac personal.

Pràctiques que funcionen:

• Preguntes als canals públics, no per DM. Si algú té un dubte, segur que algú altre també el té. Preguntar en públic normalitza no saber alguna cosa i crea una base de coneixement on es pot cercar.
• Post-mortems sense culpables. Quan alguna cosa falla en producció, el focus ha de ser quins processos han fallat, no qui ha comès l'error. «Què podem canviar perquè això no torni a passar?» en lloc de «qui ha fet el deploy?».
• Celebra els errors caçats a temps. Quan algú detecta un bug en una review, celebra-ho en públic. Reforces la idea que trobar problemes abans de producció és exactament el que vols.

Els anti-patrons que destrueixen la cultura remota

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

• Eines de vigilància: Programari que fa captures de pantalla o registra l'activitat del teclat. Si has de vigilar el teu equip, el problema el tens en la contractació, no en el monitoratge.
• Càmera obligatòria a totes les reunions. Hi ha reunions que guanyen amb vídeo. Exigir la càmera a la standup diària és esgotador i invasiu.
• Mesurar hores en lloc de resultats. A ningú no li importa si un enginyer treballa de 9 a 17 o d'11 a 19 amb dues hores de pausa al migdia. El que importa és si lliura codi de qualitat a temps.
• El «fem una call ràpida?» per a tot. Cada trucada no planificada trenca la concentració d'algú. La majoria de coses es resolen millor amb un missatge ben escrit que amb una trucada de mitja hora.

Rituals que sí que funcionen

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

• Tech talks setmanals. Trenta minuts en què algú presenta un tema tècnic. Pot ser una cosa que ha après, un problema que ha resolt, una eina nova. Rotatiu i voluntari.
• Sessions de pair programming. No com a obligació, sinó com a recurs disponible. «Algú vol fer pair amb aquest problema? Fa dues hores que hi estic encallat.» Funciona especialment bé durant l'onboarding.
• Retrospectives centrades en el procés. Cada dues setmanes: què ha funcionat, què no i què cal canviar. El focus han de ser els processos, no les persones.

Com funciona això amb enginyers externs

Si treballes amb enginyers que no són empleats directes, tot el que he explicat fins aquí encara pesa més. 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 mirem és si hi ha la infraestructura de comunicació i els processos perquè un enginyer sènior en remot sigui productiu des de la primera setmana.

Si no hi són, ajudem a construir-los. Perquè un enginyer sènior de LATAM amb experiència en equips distribuïts no es limita a escriure bon codi: aporta pràctiques contrastades de comunicació asíncrona, documentació tècnica i code review que fan pujar el nivell de tot l'equip.

La cultura d'enginyeria distribuïda no es compra. Es construeix. Però es construeix molt més de pressa quan tens gent que ja ha passat per aquest 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í.