Onboarding de un ingeniero remoto senior: el plan de los primeros 14 días
Has dedicado tiempo a encontrar al ingeniero adecuado. La evaluación técnica está cerrada, el contrato firmado y está listo para empezar. Ahora viene la parte que la mayoría de las empresas estropea: el onboarding.
Un ingeniero senior que espera tres días a que le den acceso al repositorio, pasa una semana buscando documentación que no existe y no tiene una primera tarea clara empezará a cuestionar su decisión antes de escribir una sola línea de código. El onboarding remoto amplifica el problema: no hay conversación de pasillo, no hay compañero de mesa al que preguntar y no hay esa absorción casual de contexto que da la oficina.
La objeción obvia: un ingeniero senior no necesita que lo lleven de la mano — para eso es senior. Cierto. Pero el onboarding no consiste en llevar de la mano a nadie; consiste en eliminar la fricción que no tiene nada que ver con la capacidad. El ingeniero más experimentado del mundo no puede mergear un PR en un repositorio al que no tiene acceso.
Este es el plan de 14 días que recomiendo a cada cliente que contrata a través de Conectia: lleva a un ingeniero remoto senior de cero a productivo, con su primera contribución significativa mergeada el día 10.
Antes del día 1: la checklist de pre-onboarding
Completa todo esto antes del primer día del ingeniero. Cada día que pasa esperando accesos es un día de salario desperdiciado y de motivación que se erosiona.
Accesos y herramientas:
- Acceso al repositorio de código (GitHub, GitLab, Bitbucket)
- Acceso a la herramienta de gestión de proyectos (Jira, Linear, Asana)
- Canales de comunicación (workspace de Slack, canales relevantes, mensajes directos del equipo)
- Acceso a la infraestructura cloud si aplica (AWS, GCP, Azure — solo lectura al principio)
- Visibilidad del pipeline de CI/CD
- Plataforma de documentación (Confluence, Notion, wiki interna)
- VPN o herramientas de seguridad si hacen falta
- Email y calendario si corresponde
Documentación que preparar:
- Documento de visión general de la arquitectura — no hace falta que sea perfecto, hace falta que exista. Un diagrama de servicios, flujos de datos y dependencias clave. Con una página basta para empezar.
- Guía de configuración del entorno de desarrollo — paso a paso y probada recientemente. Si tus ingenieros actuales no consiguen montar el entorno con esa guía en menos de dos horas, arregla la guía antes de que empiece la persona nueva.
- Prioridades del sprint o trimestre actual — en qué está trabajando el equipo ahora y por qué. No el roadmap completo: el contexto inmediato.
- Normas de comunicación del equipo — cuándo son los standups, qué canal se usa para qué, cuál es el tiempo de respuesta esperado en mensajes asíncronos y cómo se gestionan las code reviews.
Primera tarea:
Identifica una tarea antes de que el ingeniero empiece. Debería ser:
- Lo bastante pequeña para completarse en 2–3 días
- Lo bastante real para tocar el código de verdad (nada de tutoriales ni ejercicios en sandbox)
- Lo bastante bien definida para que el ingeniero pueda trabajar de forma autónoma tras una breve explicación
- Revisable por el equipo a través del proceso normal de code review
Buenas primeras tareas: corregir un bug conocido, añadir una feature pequeña con criterios de aceptación claros, escribir los tests que le faltan a un módulo existente, refactorizar una pieza bien acotada de deuda técnica.
Malas primeras tareas: "explora el código y pregunta lo que quieras", cualquier cosa que exija entender el sistema completo para arrancar, cualquier cosa bloqueada por decisiones que aún no se han tomado.
Día 1: orientación y puesta a punto del entorno
Mañana (2–3 horas, síncrono):
- Llamada de bienvenida con su manager directo o tech lead. 30 minutos. Qué está construyendo el equipo, quién es quién y cómo serán las dos primeras semanas. Mantenla acotada — el panorama general lo irá absorbiendo con el tiempo.
- Preséntalo en el canal del equipo. Un mensaje breve: su nombre, en qué va a trabajar y una invitación a que el equipo lo salude.
- Configuración del entorno de desarrollo. Debería seguir la guía por su cuenta, con un miembro del equipo designado y disponible en Slack para dudas. El objetivo: entorno local funcionando y capaz de compilar y testear el proyecto antes de acabar el día.
Tarde (asíncrono):
- Leer el documento de visión general de la arquitectura.
- Explorar el código — servicios principales, estructura de carpetas, convenciones de nombres.
- Leer los últimos 5 PRs mergeados para entender la cultura de code review y los patrones de código del equipo.
Métrica de éxito del día 1: entorno de desarrollo funcionando, presentaciones hechas, documento de arquitectura leído.
Días 2–3: recorrido por el código y primera tarea
Día 2 — Recorrido guiado (1–2 horas, síncrono):
Un ingeniero senior de tu equipo recorre el código con la persona nueva. No es una clase magistral — es una conversación. El foco:
- Los tres servicios o módulos más críticos y cómo interactúan
- El pipeline de despliegue: cómo viaja el código del PR a producción
- La estrategia de testing: qué se testea, qué no y por qué
- Los puntos de dolor conocidos: zonas de deuda técnica, componentes frágiles, cosas que se rompen a menudo
Después del recorrido, asigna la primera tarea. Repasad juntos el ticket, explica el contexto, señala el código relevante y confirma los criterios de aceptación.
Día 3 — Trabajo autónomo:
El ingeniero trabaja en su primera tarea. Debería tener contexto suficiente para avanzar de verdad. Check-in asíncrono al final del día: "¿Cómo vas? ¿Algún bloqueo?"
El objetivo no es entregar la tarea el día 3 — es confirmar que el ingeniero sabe moverse por el código, entiende las convenciones y puede trabajar de forma autónoma.
Métrica de éxito de los días 2–3: primera tarea en marcha, ingeniero trabajando de forma autónoma con una supervisión mínima.
Días 4–5: primer PR e integración con el equipo
Día 4:
El ingeniero abre su primer pull request. El equipo lo revisa con el proceso normal de code review — sin trato especial, sin rebajar el listón. Es la primera señal real sobre calidad de código, disciplina de testing y estilo de comunicación (la descripción del PR y cómo responde a los comentarios de la review).
Si el PR necesita cambios, es normal y además es útil. Cómo responde un ingeniero al feedback te dice más sobre su forma de trabajar que cualquier entrevista.
Día 5:
Primer PR mergeado. El ingeniero asiste a su primer standup completo del equipo (si no lo ha hecho ya) y participa en los rituales del sprint. Debería poder dar un breve estado de situación y coger su siguiente tarea del tablero.
Métrica de éxito de los días 4–5: primer PR revisado y mergeado. Ingeniero participando en los rituales del equipo.
Días 6–10: coger ritmo
El ingeniero ya está en la cadencia normal de trabajo: coge tareas del tablero del sprint, trabaja de forma autónoma, abre PRs y responde a las code reviews. Durante esta fase:
Sesiones de pair programming (2–3 sesiones, 1 hora cada una):
Programa sesiones de pairing con distintos miembros del equipo sobre tareas reales. Acelera el aprendizaje, construye relaciones y ayuda al nuevo ingeniero a absorber las convenciones no escritas y el razonamiento arquitectónico que la documentación no captura.
Contexto de las decisiones de arquitectura:
Comparte el razonamiento detrás de las grandes decisiones del pasado. ¿Por qué elegisteis esta base de datos? ¿Por qué este servicio está separado de aquel otro? ¿Por qué el pipeline de despliegue funciona así? Los ingenieros senior rinden mejor cuando entienden el "por qué" del sistema, no solo el "qué".
Amplía los accesos gradualmente:
Si empezaste con acceso de solo lectura a la infraestructura, concede escritura a medida que el ingeniero demuestre fiabilidad. Dale acceso a los dashboards de monitorización, los sistemas de alertas y los logs de producción para que entienda cómo se comporta el sistema en ejecución.
Métrica de éxito de los días 6–10: 2–3 PRs mergeados. Ingeniero completando tareas a un ritmo estable. Cómodo con el flujo de trabajo y los patrones de comunicación del equipo.
Días 11–14: ownership y evaluación
Días 11–12:
Asigna una tarea algo más compleja — algo que exija tomar una decisión menor de arquitectura o de diseño, no solo implementar una especificación. Observa cómo aborda la ambigüedad: ¿toma una decisión razonable y la documenta, o espera a que alguien le diga qué hacer?
Día 13:
Conversación 1:1 con su manager o tech lead. Feedback en los dos sentidos:
- Por tu parte: ¿qué tal la calidad del código? ¿La comunicación? ¿El ritmo? ¿Alguna preocupación?
- Por la suya: ¿qué funciona? ¿Qué resulta confuso? ¿Qué le ayudaría a ser más productivo?
Esta conversación debe ser franca. Si hay problemas, ponlos sobre la mesa ahora — no en el tercer mes, cuando ya se hayan enquistado.
Día 14:
El ingeniero debería estar operando al 60–70% de su productividad plena. Ese es el objetivo realista para el día 14 con un código nuevo. En mi experiencia, la productividad plena llega entre la semana 4 y la 6 para un ingeniero senior en un código complejo.
Métrica de éxito de los días 11–14: ingeniero tomando decisiones por su cuenta. Conversación de feedback completada. Camino claro hacia la productividad plena.
La mentalidad async-first en el onboarding
Todo este plan parte de una premisa: el tiempo síncrono es valioso y escaso. Con 6+ horas de solapamiento horario tienes de sobra para los standups diarios, las sesiones de pairing y algún recorrido puntual. Pero la mayor parte del onboarding debería funcionar en asíncrono:
- Mejor documentación escrita que explicaciones de viva voz
- Mejor recorridos grabados (Loom, grabaciones de pantalla) que presentaciones en directo
- Mejor hilos de Slack que reuniones
- Mejor comentarios en el PR que code reviews en persona
Esto no es solo una consideración nearshore — es como operan los buenos equipos remotos. Y tiene un beneficio secundario: cada pieza de material de onboarding que creas para este ingeniero hace más rápido el siguiente onboarding.
De qué se encarga Conectia
Para los ingenieros incorporados a través de Conectia, apoyamos el proceso de onboarding así:
- Garantizamos que el ingeniero tenga equipo, conectividad y un entorno de trabajo operativo desde el primer día.
- Proporcionamos una capa de soporte de transición durante las dos primeras semanas — un punto de contacto para el ingeniero si tiene dudas que todavía no se atreve a plantear al equipo del cliente.
- Hacemos seguimiento con el cliente y con el ingeniero los días 7 y 14 para detectar y resolver cualquier fricción a tiempo.
- Activamos el proceso de reemplazo de inmediato si la evaluación del día 14 revela un desajuste de fondo.
¿Vas a contratar pronto y quieres un plan de onboarding adaptado a tu stack y a tu equipo? Empieza con una llamada de descubrimiento técnico — te ayudamos a prepararlo todo antes incluso de que el ingeniero empiece.
