AXENTED — Blog Article
Slug: /blog-posts/nearshore-team-90-day-playbook |
Meta description: Los primeros 90 días de un engagement nearshore determinan la productividad a largo plazo. Un playbook semana a semana que cubre la transferencia de contexto, el primer trabajo real, la integración y la independencia. |
Target keywords: onboarding equipo nearshore, construir equipo nearshore, plan 90 días equipo remoto, playbook ingeniería nearshore |
Los primeros 90 días de un engagement nearshore son cuando se toman las decisiones más importantes y cuando se siembran la mayoría de los fracasos. Los equipos que lo hacen bien generan un momentum que se multiplica. Los que lo hacen mal pasan meses en una disfunción de bajo nivel que todos perciben pero nadie puede diagnosticar.
Este es el playbook que utilizamos — semana a semana, con los resultados específicos que definen el éxito en cada etapa.
Nada productivo sucede antes de que la transferencia de contexto esté completa. Los ingenieros nearshore que se incorporan a tu equipo no tienen el conocimiento institucional que tu equipo interno ha acumulado durante meses o años. Hacerlos productivos antes de cerrar esa brecha es una forma de producir trabajo rápido pero incorrecto.
Cómo se ve esto en la práctica: recorridos sincrónicos de la arquitectura (grabados para revisión asíncrona), decisiones documentadas sobre por qué el sistema es como es (no solo qué es), acceso a todas las herramientas con credenciales y permisos completamente aprovisionados antes del primer día, y una definición clara de cómo se ve "listo" para el primer entregable real. Las primeras dos semanas no deberían producir código en producción. Deberían producir ingenieros que entiendan el sistema lo suficientemente bien como para contribuir de forma segura.
La primera tarea real asignada a un nuevo ingeniero nearshore debe ser moderadamente desafiante, tener una definición clara de listo, y no estar en el camino crítico. El objetivo es un entorno controlado para el primer ciclo real de retroalimentación: el nuevo ingeniero entrega algo, recibe una revisión de código, obtiene feedback y lo incorpora. Ese ciclo revela patrones de comunicación, expectativas de calidad y brechas de familiaridad con las herramientas en un contexto de bajo riesgo.
El error es asignar trabajo urgente primero. La urgencia comprime los ciclos de retroalimentación y dificulta distinguir entre "este ingeniero necesita más contexto" y "este ingeniero tiene una brecha de habilidades."
Para la quinta semana, el nuevo ingeniero debería estar en todos los rituales regulares del equipo: standup, sprint planning, retrospectiva, revisión de código. El objetivo de esta fase no es el output máximo. Es la integración: establecer los patrones de comunicación, las normas de retroalimentación y las relaciones de trabajo que determinan la productividad a largo plazo.
Asigna un buddy del equipo interno — no un manager, un ingeniero — cuyo trabajo explícito sea ser la primera llamada cuando el nuevo ingeniero esté bloqueado. Esa relación es la infraestructura social más importante de los primeros 90 días. Normaliza pedir ayuda y crea un canal de retroalimentación que no requiere una sesión formal de 1:1.
Al final del tercer mes, el ingeniero nearshore debería operar con el mismo grado de independencia que un ingeniero que lleva seis meses en el equipo. No independencia máxima — eso tarda un año. Pero independencia funcional: capaz de tomar un ticket del backlog a producción sin requerir que un ingeniero senior esté en cada decisión.
El hito que confirma que esta fase está completa: el ingeniero ha entregado algo de complejidad real, recibió feedback normal de revisión de código (no orientación a nivel de mentoría) y fue dueño de un incidente de producción no trivial desde la alerta hasta la resolución. Esos tres eventos indican que la integración funcionó.
Rastrea cuatro cosas durante los 90 días: tiempo desde la asignación hasta el primer pull request significativo (debe disminuir semana a semana), ciclos de revisión de código por pull request (números altos indican brechas de comunicación, no solo de habilidades), porcentaje de preguntas hechas síncronamente versus asíncronamente (los equipos distribuidos deben migrar hacia el async con el tiempo) y la relación de buddy — ¿la están usando y está produciendo retroalimentación útil?
Si alguna de estas métricas se estanca o se mueve en la dirección equivocada después de la sexta semana, el problema generalmente está en la fase de transferencia de contexto, no en el ingeniero. Revisa la documentación de onboarding y el recorrido de arquitectura antes de concluir que hay un problema de capacidad.
%20(1)-2.svg)
