Com Incorporar un Enginyer Remot Sènior en els Primers 14 Dies
Has dedicat temps a trobar l'enginyer adequat. El vetting està fet, el contracte signat i estan preparats per començar. Ara ve la part que la majoria d'empreses fallen: l'onboarding.
Un enginyer sènior que espera tres dies per l'accés al repositori, passa una setmana buscant documentació que no existeix i no té una primera tasca clara qüestionarà la seva decisió d'unir-se abans d'escriure una línia de codi. L'onboarding remot amplifica aquest problema perquè no hi ha conversa de passadís, no hi ha company de taula a qui preguntar i no hi ha absorció casual del context d'oficina.
Aquí tens un pla d'onboarding de 14 dies que porta un enginyer remot sènior de zero a productiu — amb la seva primera contribució significativa mergejada pel dia 10.
Abans del Dia 1: El Checklist de Pre-Onboarding
Completa tot això abans del primer dia de l'enginyer. Cada dia que passen esperant accés és un dia de salari malgastat i motivació erosionada.
Accés 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, DMs de l'equip)
- Accés a infraestructura cloud si és rellevant (AWS, GCP, Azure — només lectura inicialment)
- Visibilitat del pipeline de CI/CD
- Plataforma de documentació (Confluence, Notion, wiki intern)
- VPN o eines de seguretat si cal
- Configuració d'email/calendari si aplica
Documentació a preparar:
- Document de visió general de l'arquitectura — no cal que sigui perfecte, cal que existeixi. Un diagrama de serveis, fluxos de dades i dependències clau. Una pàgina és suficient per començar.
- Guia de configuració de l'entorn de desenvolupament — pas a pas, provada recentment. Si els teus enginyers actuals no poden configurar l'entorn de dev des d'aquesta guia en menys de dues hores, arregla la guia abans que comenci la nova persona.
- Prioritats de l'sprint/trimestre actual — en què està treballant l'equip ara i per què. No el roadmap complet — el context immediat.
- Normes de comunicació de l'equip — quan són els standups, quins canals s'utilitzen per a què, quin és el temps de resposta esperat per a missatges asíncrons, com es gestionen les code reviews.
Primera tasca:
Identifica una tasca abans que l'enginyer comenci. Hauria de ser:
- Prou petita per completar en 2–3 dies
- Prou real per tocar el codebase actual (no un tutorial o exercici sandbox)
- Prou ben definida perquè l'enginyer pugui treballar de forma independent després d'un breu recorregut
- Revisable per l'equip a través del procés normal de code review
Bones primeres tasques: corregir un bug conegut, afegir una feature petita amb criteris d'acceptació clars, escriure tests que falten per a un mòdul existent, refactoritzar una peça ben delimitada de deute tècnic.
Males primeres tasques: "explora el codebase i fes preguntes", qualsevol cosa que requereixi entendre el sistema complet per començar, qualsevol cosa bloquejada per decisions que encara no s'han pres.
Dia 1: Orientació i Configuració de l'Entorn
Matí (2–3 hores, síncron):
- Trucada de benvinguda amb el seu manager directe o tech lead. 30 minuts. Cobrir: què està construint l'equip, qui és qui, i com seran les dues primeres setmanes. Mantenir-ho enfocat — absorbiran el panorama general amb el temps.
- Presentar-los al canal de l'equip. Un missatge breu: el seu nom, en què treballaran, i una invitació perquè l'equip saludi.
- Configuració de l'entorn de desenvolupament. Haurien de seguir la guia de configuració de forma independent, amb un membre de l'equip designat disponible a Slack per a preguntes. L'objectiu: entorn de dev local funcionant i capaç de compilar/testejar el projecte pel final del dia.
Tarda (asíncron):
- Llegir el document de visió general de l'arquitectura.
- Explorar el codebase — serveis principals, estructura de carpetes, convencions de noms.
- Llegir els últims 5 PRs mergejats 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 de l'equip fetes, document d'arquitectura llegit.
Dia 2–3: Recorregut del 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 nova persona. No una classe — una conversa. Enfocar-se en:
- Els tres serveis o mòduls més crítics i com interactuen
- El pipeline de desplegament: com el codi va de PR a producció
- L'estratègia de testing: què es testeja, què no, i per què
- Punts de dolor coneguts: àrees de deute tècnic, components fràgils, coses que es trenquen sovint
Després del recorregut, assignar la primera tasca. Repassar el ticket, explicar el context, assenyalar el codi rellevant i confirmar els criteris d'acceptació.
Dia 3 — Treball independent:
L'enginyer treballa en la seva primera tasca. Haurien de tenir prou context per fer progrés significatiu. Check-in asíncron al final del dia: "On ets? Algun bloqueig?"
L'objectiu no és lliurar la tasca el dia 3 — és confirmar que l'enginyer pot navegar pel codebase, entendre les convencions i treballar de forma independent.
Mètrica d'èxit del Dia 2–3: Primera tasca en curs, enginyer treballant de forma independent amb mínima orientació.
Dia 4–5: Primer PR i Integració amb l'Equip
Dia 4:
L'enginyer obre el seu primer pull request. L'equip el revisa a través del procés normal de code review — sense tracte especial, sense estàndards relaxats. Aquest és el primer punt de dades real sobre qualitat de codi, disciplina de testing i estil de comunicació (la descripció del PR i la resposta als comentaris de review).
Si el PR necessita canvis, és normal i útil. Com l'enginyer respon al feedback et diu més sobre el seu estil de treball que qualsevol entrevista.
Dia 5:
Primer PR mergejat. L'enginyer assisteix al seu primer standup complet de l'equip (si no ho ha fet ja) i participa en els rituals de l'sprint. Haurien de poder donar una breu actualització d'estat i agafar la seva pròxima tasca del board.
Mètrica d'èxit del Dia 4–5: Primer PR revisat i mergejat. Enginyer participant en els rituals de l'equip.
Dia 6–10: Construint Impuls
L'enginyer ara està en la cadència regular de treball. Agafen tasques de l'sprint board, treballen de forma independent, envien PRs i responen a code reviews. Durant aquesta fase:
Sessions de pair programming (2–3 sessions, 1 hora cadascuna):
Programa sessions de pairing amb diferents membres de l'equip en tasques reals. Això accelera l'aprenentatge, construeix relacions i ajuda el nou enginyer a absorbir convencions no escrites i raonament arquitectònic que la documentació no captura.
Context de decisions d'arquitectura:
Comparteix el raonament darrere de les principals decisions passades. Per què vas triar aquesta base de dades? Per què aquest servei està separat d'aquell? Per què el pipeline de desplegament funciona així? Els enginyers sènior rendeixen millor quan entenen el "per què" darrere del sistema, no només el "què".
Expandir accés gradualment:
Si vas començar amb accés de només lectura a la infraestructura, atorga accés d'escriptura a mesura que l'enginyer demostra fiabilitat. Dona'ls accés a dashboards de monitoratge, sistemes d'alertes i logs de producció perquè puguin entendre el comportament en temps d'execució del sistema.
Mètrica d'èxit del Dia 6–10: 2–3 PRs mergejats. Enginyer completant tasques a un ritme constant. Còmode amb el flux de treball i els patrons de comunicació de l'equip.
Dia 11–14: Ownership i Avaluació
Dia 11–12:
Assigna una tasca lleugerament més complexa — alguna cosa que requereixi prendre una decisió menor d'arquitectura o disseny, no només implementar una especificació. Observa com l'enginyer aborda l'ambigüitat: pren una decisió raonable i la documenta, o espera que algú li digui què fer?
Dia 13:
Conversa 1:1 amb el seu manager o tech lead. Feedback bidireccional:
- De la teva part: Com és la qualitat del codi? La comunicació? El ritme? Alguna preocupació?
- De la seva part: Què funciona? Què és confús? Què els ajudaria a ser més productius?
Aquesta conversa hauria de ser franca. Si hi ha problemes, posa'ls sobre la taula ara — no al mes tres quan s'hauran acumulat.
Dia 14:
L'enginyer hauria d'estar operant al 60–70% de productivitat plena. Aquesta és la meta realista pel dia 14 amb un nou codebase. La productivitat plena típicament arriba a la setmana 4–6 per a enginyers sènior en un codebase complex.
Mètrica d'èxit del Dia 11–14: Enginyer prenent decisions independents en tasques. Conversa de feedback completada. Camí clar cap a la productivitat plena.
La Mentalitat d'Onboarding Async-First
Tot en aquest pla assumeix que el temps síncron és preciós i limitat. Amb 6+ hores de solapament de zona horària, tens prou per a standups diaris, sessions de pairing i algun recorregut ocasional. Però la majoria de l'onboarding hauria de funcionar de forma asíncrona:
- Documentació escrita sobre explicacions verbals
- Recorreguts gravats (Loom, gravacions de pantalla) sobre presentacions en directe
- Fils de Slack sobre reunions
- Comentaris en PRs sobre code reviews presencials
Això no és només una consideració nearshore — és com operen els bons equips remots. I té un benefici secundari: cada peça de material d'onboarding que crees per a aquest enginyer fa que el pròxim onboarding sigui més ràpid.
El que Conectia Gestiona
Per a enginyers col·locats a través de Conectia, donem suport al procés d'onboarding:
- Assegurant que l'enginyer tingui equipament, connectivitat i un entorn de treball funcional des del primer dia.
- Proporcionant una capa de suport de transició durant les dues primeres setmanes — un punt de contacte per a l'enginyer si té preguntes que encara no se sent còmode plantejant a l'equip del client.
- Fent check-in tant amb el client com amb l'enginyer al dia 7 i dia 14 per identificar i resoldre qualsevol fricció aviat.
- Activant el procés de reemplaçament immediatament si l'avaluació del dia 14 indica un desajust fonamental.
Contractant aviat i vols un pla d'onboarding adaptat al teu stack i equip? Comença amb una trucada de descobriment tècnic — t'ajudarem a preparar-te abans que l'enginyer ni tan sols comenci.
