Guies

Com incorporar un enginyer remot sènior en els primers 14 dies

Per Marc Molas·15 d’agost del 2025·9 min de lectura

Has dedicat temps a trobar l'enginyer adequat. El vetting està fet, el contracte signat i ja està a punt per començar. Ara ve la part que la majoria d'empreses espatllen: l'onboarding.

Un enginyer sènior que s'espera tres dies per tenir accés al repositori, es passa una setmana buscant documentació que no existeix i no té una primera tasca clara es replantejarà la decisió d'haver-s'hi incorporat abans d'haver escrit ni una línia de codi. L'onboarding remot agreuja el problema: no hi ha converses de passadís, ni cap company de taula a qui preguntar, ni aquell context que a l'oficina s'absorbeix sense adonar-se'n.

L'objecció òbvia: un enginyer sènior no necessita que el portin de la mà — per això és sènior. Cert. Però l'onboarding no és portar ningú de la mà; és eliminar la fricció que no té res a veure amb l'habilitat. L'enginyer més experimentat del món no pot fusionar cap PR en un repositori al qual no té accés.

Aquest és el pla de 14 dies que recomano a tots els clients que contracten a través de Conectia — porta un enginyer remot sènior de zero a productiu, amb la primera contribució significativa fusionada el dia 10.

Abans del dia 1: la checklist de pre-onboarding

Completa-ho tot abans del primer dia de l'enginyer. Cada dia que passa esperant accessos és un dia de sou malgastat i de motivació que s'erosiona.

Accessos i eines:

Accés al repositori de codi font (GitHub, GitLab, Bitbucket)
Accés a l'eina de gestió de projectes (Jira, Linear, Asana)
Canals de comunicació (workspace de Slack, canals rellevants, missatges directes amb l'equip)
Accés a la infraestructura cloud si escau (AWS, GCP, Azure — només lectura al principi)
Visibilitat del pipeline de CI/CD
Plataforma de documentació (Confluence, Notion, wiki interna)
VPN o eines de seguretat si calen
Correu i calendari si escau

Documentació a preparar:

Document de visió general de l'arquitectura — no cal que sigui perfecte; cal que existeixi. Un diagrama amb els serveis, els fluxos de dades i les dependències clau. Amb una pàgina n'hi ha prou per començar.
Guia de configuració de l'entorn de desenvolupament — pas a pas i provada fa poc. Si els teus enginyers actuals no són capaços de muntar l'entorn de dev seguint aquesta guia en menys de dues hores, arregla la guia abans que la persona nova comenci.
Prioritats de l'sprint o del trimestre actual — en què treballa l'equip ara mateix i per què. No cal el roadmap sencer: el context immediat.
Normes de comunicació de l'equip — quan es fan els standups, quins canals serveixen per a què, quin temps de resposta s'espera en els missatges asíncrons i com es gestionen les code reviews.

Primera tasca:

Identifica una tasca abans que l'enginyer comenci. Ha de ser:

Prou petita per enllestir-la en 2–3 dies
Prou real per tocar el codebase de veritat (ni tutorials ni exercicis de sandbox)
Prou ben definida perquè l'enginyer hi pugui treballar sol després d'una explicació breu
Revisable per l'equip amb el procés habitual de code review

Bones primeres tasques: arreglar un bug conegut, afegir una funcionalitat petita amb criteris d'acceptació clars, escriure els tests que falten en un mòdul existent, refactoritzar un tros ben delimitat de deute tècnic.

Males primeres tasques: «explora el codebase i pregunta el que calgui», qualsevol cosa que exigeixi entendre tot el sistema per començar, qualsevol cosa bloquejada per decisions que encara no s'han pres.

Dia 1: orientació i posada a punt de l'entorn

Matí (2–3 hores, síncron):

Trucada de benvinguda amb el seu manager directe o el team lead. 30 minuts. Temes: què construeix l'equip, qui és qui i com seran les dues primeres setmanes. Sense allargar-se — el panorama general ja l'anirà absorbint amb el temps.
Presenta'l al canal de l'equip. Un missatge breu: com es diu, en què treballarà i una invitació perquè l'equip el saludi.
Configuració de l'entorn de desenvolupament. Ha de poder seguir la guia pel seu compte, amb un membre de l'equip designat i disponible a Slack per resoldre dubtes. L'objectiu: entorn de dev local funcionant i capaç de compilar i testejar el projecte abans d'acabar el dia.

Tarda (asíncron):

Llegir el document de visió general de l'arquitectura.
Remenar el codebase — serveis principals, estructura de carpetes, convencions de noms.
Llegir els últims cinc PR fusionats per entendre la cultura de code review i els patrons de codi de l'equip.

Mètrica d'èxit del dia 1: entorn de dev funcionant, presentacions fetes i document d'arquitectura llegit.

Dia 2–3: recorregut pel codebase i primera tasca

Dia 2 — recorregut guiat (1–2 hores, síncron):

Un enginyer sènior del teu equip recorre el codebase amb la persona nova. No és una classe magistral: és una conversa. Els punts a tocar:

Els tres serveis o mòduls més crítics i com interactuen
El pipeline de desplegament: com va el codi del PR a producció
L'estratègia de testing: què es testeja, què no i per què
Els punts problemàtics coneguts: zones de deute tècnic, components fràgils, coses que es trenquen sovint

Després del recorregut, assigna-li la primera tasca. Repasseu el ticket junts, explica-li el context, ensenya-li el codi rellevant i confirmeu els criteris d'acceptació.

Dia 3 — treball independent:

L'enginyer treballa en la primera tasca. Hauria de tenir prou context per avançar de manera significativa. Check-in asíncron al final del dia: «On ets? Tens cap bloqueig?»

L'objectiu no és tancar la tasca el dia 3 — és confirmar que l'enginyer sap moure's pel codebase, entén les convencions i pot treballar sol.

Mètrica d'èxit del dia 2–3: primera tasca en marxa i l'enginyer treballant de manera autònoma amb un mínim d'acompanyament.

Dia 4–5: primer PR i integració amb l'equip

Dia 4:

L'enginyer obre el seu primer pull request. L'equip el revisa amb el procés habitual de code review — sense tractes de favor ni estàndards rebaixats. És la primera dada real sobre la qualitat del codi, la disciplina de testing i l'estil de comunicació (la descripció del PR i com respon als comentaris de la review).

Que el PR necessiti canvis és normal, i és útil. Com encaixa el feedback l'enginyer et diu més del seu estil de treball que cap entrevista.

Dia 5:

Primer PR fusionat. L'enginyer assisteix al primer standup complet de l'equip (si encara no ho ha fet) i participa en els rituals de l'sprint. Hauria de poder donar un estat breu de la feina i agafar la següent tasca del board.

Mètrica d'èxit del dia 4–5: primer PR revisat i fusionat. L'enginyer participa en els rituals de l'equip.

Dia 6–10: agafar ritme

L'enginyer ja és dins la cadència normal de treball: agafa tasques del board de l'sprint, treballa de manera autònoma, envia PR i respon a les code reviews. Durant aquesta fase:

Sessions de pair programming (2–3 sessions d'una hora):

Programa sessions de pairing amb diferents membres de l'equip sobre tasques reals. Acceleren l'aprenentatge, creen relacions i ajuden l'enginyer nou a absorbir les convencions no escrites i el raonament arquitectònic que la documentació no recull.

Context de les decisions d'arquitectura:

Comparteix el raonament que hi ha darrere de les grans decisions del passat. Per què vau triar aquesta base de dades? Per què aquest servei està separat d'aquell altre? Per què el pipeline de desplegament funciona com funciona? Els enginyers sènior rendeixen més quan entenen el «per què» del sistema, no només el «què».

Amplia l'accés gradualment:

Si has començat amb accés de només lectura a la infraestructura, dona-li accés d'escriptura a mesura que demostri fiabilitat. Obre-li els dashboards de monitoratge, els sistemes d'alertes i els logs de producció perquè pugui entendre com es comporta el sistema en execució.

Mètrica d'èxit del dia 6–10: 2–3 PR fusionats. L'enginyer tanca tasques a un ritme constant i es mou amb comoditat pel flux de treball i els patrons de comunicació de l'equip.

Dia 11–14: ownership i avaluació

Dia 11–12:

Assigna-li una tasca una mica més complexa — alguna cosa que demani prendre una petita decisió d'arquitectura o de disseny, no només implementar una especificació. Observa com gestiona l'ambigüitat: pren una decisió raonable i la documenta, o s'espera que algú li digui què ha de fer?

Dia 13:

Conversa 1:1 amb el seu manager o tech lead. Feedback en les dues direccions:

Per part teva: com és la qualitat del codi? I la comunicació? El ritme? Hi ha res que et preocupi?
Per part seva: què funciona? Què el confon? Què l'ajudaria a ser més productiu?

La conversa ha de ser franca. Si hi ha problemes, treu-los ara — no al cap de tres mesos, quan s'hauran fet grossos.

Dia 14:

L'enginyer hauria d'estar operant al 60–70% de la seva productivitat plena. Aquest és l'objectiu realista per al dia 14 amb un codebase nou. Per la meva experiència, la productivitat plena arriba a la setmana 4–6 en el cas d'enginyers sènior amb un codebase complex.

Mètrica d'èxit del dia 11–14: l'enginyer pren decisions de manera autònoma. Conversa de feedback feta. Camí clar cap a la productivitat plena.

La mentalitat d'onboarding async-first

Tot aquest pla parteix d'una premissa: el temps síncron és escàs i valuós. Amb 6+ hores de solapament horari en tens prou per als standups diaris, les sessions de pairing i algun recorregut puntual. Però el gruix de l'onboarding ha de funcionar en asíncron:

Documentació escrita abans que explicacions orals
Recorreguts gravats (Loom, gravacions de pantalla) abans que presentacions en directe
Fils de Slack abans que reunions
Comentaris al PR abans que code reviews en persona

I això no és una particularitat del nearshore: és com operen els bons equips remots. A més, té un benefici secundari: tot el material d'onboarding que creïs per a aquest enginyer farà més ràpid el següent.

De què s'encarrega Conectia

Per als enginyers incorporats a través de Conectia, donem suport al procés d'onboarding:

Garantim que l'enginyer tingui equipament, connectivitat i un entorn de treball operatiu des del primer dia.
Oferim una capa de suport de transició durant les dues primeres setmanes — un punt de contacte per a l'enginyer si té dubtes que encara no se sent còmode plantejant a l'equip del client.
Fem seguiment amb el client i amb l'enginyer els dies 7 i 14 per detectar i resoldre friccions de seguida.
Activem el procés de substitució immediatament si l'avaluació del dia 14 indica un desencaix de fons.

Tens previst contractar aviat i vols un pla d'onboarding adaptat al teu stack i al teu equip? Comença amb una trucada de descoberta tècnica — t'ajudarem a tenir-ho tot a punt abans i tot que l'enginyer comenci.