Como construir y gestionar un equipo tecnico remoto distribuido para escalar tu startup de software

En 2019 eramos tres ingenieros en una oficina pequena en el centro de Madrid. Para finales de 2021 teniamos 45 personas repartidas entre Espana, Colombia, Argentina, Portugal y Polonia. No fue un camino lineal. Hubo semanas donde contratamos a dos personas geniales y semanas donde perdimos a alguien clave porque no teniamos los procesos para retenerle. Voy a contarte lo que aprendi montando ese equipo desde cero en una fintech espanola, con los numeros reales y los errores que me costaron meses de retraso.

Construir un equipo tecnico solido es probablemente el reto mas complicado que vas a enfrentar como fundador de una startup de software. Y hacerlo en remoto no es simplemente "lo mismo pero con Slack". Es un modelo operativo completamente diferente que, si lo haces bien, te da una ventaja competitiva brutal. Si lo haces mal, te destruye la velocidad de ejecucion y la moral del equipo en cuestion de meses.

Por que el modelo distribuido tiene sentido real para una startup de software

Cuando arrancamos la fintech, mi cofundador y yo teniamos claro que necesitabamos un backend engineer senior con experiencia en sistemas de pagos. Llevabamos dos meses buscando en Madrid. Dos meses. En una startup con runway de 14 meses, eso es un porcentaje aterrador de tu tiempo quemandose mientras no avanzas en producto.

El talento tecnico de alto nivel no vive concentrado en una sola ciudad. Esto suena obvio escrito asi, pero la inercia de buscar "cerca" es fortisima. En Madrid habia quiza 15-20 personas con el perfil que necesitabamos, y todas estaban felices en sus puestos o pedian salarios que no podiamos pagar en nuestra ronda seed. Cuando abrimos la busqueda a toda Latinoamerica y Europa, pasamos de 15 candidatos potenciales a mas de 200 en tres semanas.

El coste de oportunidad de no contratar rapido es enorme y se subestima sistematicamente. Hicimos los numeros: cada semana sin ese backend senior nos costaba aproximadamente 12.000 euros en features que no se lanzaban, bugs que se acumulaban y decisiones de arquitectura que se posponian. Multiplicalo por ocho semanas y tienes casi 100.000 euros en coste de oportunidad. Eso es mas que el salario anual de la persona que buscabamos.

La resiliencia operativa de un equipo distribuido es algo que no valoras hasta que lo necesitas. Cuando en marzo de 2020 todo el mundo se fue a casa, nosotros ya llevabamos seis meses operando en remoto. No perdimos ni un solo dia de productividad. Competidores nuestros tardaron semanas en adaptarse. Esa ventana nos permitio lanzar dos features criticas antes que ellos.

Pero voy a ser honesto: el modelo remoto no funciona por defecto. Si simplemente contratas gente en otros paises y les das acceso al repo, vas directo al desastre. Requiere inversion deliberada en procesos, herramientas y sobre todo cultura. Calculo que dedicamos un 15-20% de mi tiempo como CTO durante el primer ano exclusivamente a construir la infraestructura operativa del trabajo remoto. Fue una inversion que se pago con creces, pero hay que hacerla.

Fase 1: Disenar la estructura antes de contratar a nadie

Este fue mi primer gran error. Empezamos a contratar antes de tener claro que equipo necesitabamos. Resultado: contratamos a un frontend engineer senior cuando lo que realmente necesitabamos era un DevOps que nos montara el CI/CD. Perdimos tres meses.

El mapa de roles tecnicos que necesitas (con 18 meses de vision)

Antes de publicar una sola oferta, sientate y dibuja el organigrama tecnico que necesitaras dentro de 18 meses. No el que necesitas manana, sino el que necesitaras cuando tu producto tenga 10x los usuarios actuales. Este ejercicio te obliga a tomar decisiones estrategicas sobre que capacidades construir internamente y cuales externalizar.

En nuestro caso, el mapa quedo asi: necesitabamos dos squads de producto (pagos y onboarding), un equipo de plataforma (DevOps + SRE) y un data engineer. Total: 12 personas en 18 meses, partiendo de 3. Eso significaba contratar una persona cada seis semanas de media. Tener ese numero claro nos permitio planificar el pipeline de contratacion con antelacion en lugar de ir apagando fuegos.

Una trampa comun: no incluir el "engineering manager" en tu mapa inicial. Cuando tienes 3-5 ingenieros, tu como CTO puedes gestionar directamente. Cuando llegas a 8-10, necesitas a alguien dedicado. Si no lo planificas, te encuentras con que tu eres el cuello de botella en code reviews, 1:1s y decisiones de arquitectura, y dejas de tener tiempo para la estrategia tecnica. Nos paso exactamente eso alrededor de la persona numero 9.

Que perfiles requieren horario solapado y cuales no

Esta decision es mas importante de lo que parece y la mayoria de equipos la toman por defecto sin pensarla. Nuestra regla, despues de muchas iteraciones: exigimos al menos 4 horas de solapamiento de trabajo activo para roles que estan en el camino critico de deploys o decisiones de arquitectura.

Concretamente: los backend engineers del squad de pagos necesitaban solaparse entre si y con el SRE porque haciamos deploys diarios de un sistema financiero. No puedes hacer un deploy de un servicio de pagos a las 3 de la tarde en Madrid si el SRE esta durmiendo en Bogota.

Pero el frontend engineer que trabajaba en el dashboard de analitica? No necesitaba solaparse con nadie mas alla de la daily asincrona y una hora de pair programming semanal. Eso nos permitio contratar a una persona excelente en Mexico que trabajaba en un horario completamente diferente al nuestro, y funcionaba perfecto.

La regla practica que usabamos: dibuja un diagrama de dependencias entre roles. Si dos roles tienen dependencias de ejecucion diaria (no solo de comunicacion, sino de ejecucion), necesitan solapamiento. Si las dependencias son semanales, con una reunion semanal sincronizada basta.

Niveles de seniority con criterios que funcionan en remoto

En una oficina fisica puedes compensar la falta de autonomia de un junior con supervision presencial. En remoto, no puedes. Esto cambia radicalmente los atributos que buscas en cada nivel.

Despues de contratar a 45 personas, estos son los tres atributos que mejor predicen el exito en remoto, por encima de los anos de experiencia:

Primero, capacidad de autogestionarse sin supervision diaria. No hablo de trabajar muchas horas, hablo de saber priorizar, pedir ayuda cuando estas bloqueado (en lugar de quedarte atascado en silencio) y mantener visible tu progreso sin que nadie te lo pida.

Segundo, calidad de la comunicacion escrita en issues, PRs y documentacion. En remoto, el 80% de tu comunicacion es texto. Si alguien no puede explicar una decision tecnica por escrito de forma clara y concisa, vas a tener problemas. Evaluamos esto directamente en el proceso de seleccion.

Tercero, historial de decisiones tecnicas documentadas. Quiero ver que la persona ha tomado decisiones con trade-offs explicitos y las ha escrito. No necesito que acertara siempre, necesito que sepa razonar sobre las consecuencias de una decision tecnica.

Fase 2: El proceso de contratacion para equipos distribuidos

Aqui es donde la mayoria de startups copian el proceso de contratacion presencial y lo meten en Zoom. No funciona. Necesitas un proceso disenado desde cero para evaluar las competencias que importan en remoto.

Donde encontrar talento tecnico internacional de verdad

LinkedIn con busqueda booleana avanzada sigue siendo la herramienta mas efectiva para sourcing activo. Pero tienes que aprender a usarla bien. Nuestro truco: en lugar de buscar por titulo ("Senior Backend Engineer"), buscabamos por tecnologias especificas y proyectos. "Golang AND microservices AND fintech" nos daba mejores resultados que "Senior Backend Developer". Invertimos unas 8 horas semanales en sourcing activo durante los picos de contratacion.

Plataformas como Toptal, Arc.dev y Deel Talent funcionan bien para perfiles especificos, pero son caras. Toptal cobra un markup del 40-60% sobre lo que cobra el freelance. Para contratacion directa a largo plazo, preferimos hacer el sourcing nosotros y usar estas plataformas solo para necesidades puntuales o para validar rangos salariales en mercados que no conociamos.

GitHub y contribuciones a proyectos open source es una mina de oro infrautilizada. Cuando necesitamos un experto en Kubernetes, fuimos directamente a los contributors de proyectos relacionados con nuestro stack. Encontramos a nuestro SRE senior asi, una persona en Portugal que mantenia un operador de Kubernetes con 2.000 estrellas en GitHub. Ni siquiera estaba buscando trabajo, pero le intereso nuestro reto tecnico.

Las comunidades de nicho tecnicas son donde esta el talento que no esta en LinkedIn. Meetups virtuales, Discord servers de tecnologias especificas, newsletters tecnicas. Nuestro mejor data engineer vino de una comunidad de Apache Kafka en Telegram.

Disena un proceso que revele como trabaja la persona, no solo lo que sabe

La entrevista clasica de preguntas tecnicas tipo trivia no te dice absolutamente nada sobre como va a rendir esa persona en un equipo remoto. Despues de iterar mucho, nuestro proceso quedo en dos fases principales:

Prueba de trabajo asincrona con un problema tecnico realista y plazo de 48-72 horas. No un ejercicio de algoritmos, sino algo parecido a lo que harian en su dia a dia. Para backend, les dabamos un microservicio con un bug de rendimiento y les pediamos que lo diagnosticaran y propusieran una solucion. Evaluabamos tres cosas: la solucion tecnica (obviamente), la calidad de la comunicacion escrita en su explicacion, y como gestionaban su tiempo y dudas durante el proceso.

Un detalle que marco la diferencia: les deciamos explicitamente que podia preguntarnos dudas por email durante la prueba. Los mejores candidatos siempre preguntaban algo. Los que entregaban sin preguntar nada solian haber asumido cosas incorrectas que un simple mensaje habria resuelto. Eso te dice mucho sobre como van a trabajar en remoto.

Sesion de pair programming en vivo de 45 minutos. No para ver si saben resolver un problema bajo presion, sino para evaluar como razonan en voz alta, como reaccionan al feedback ("que pasaria si en lugar de eso...?") y como estructuran la conversacion tecnica. En remoto, la capacidad de pensar colaborativamente a traves de una pantalla compartida es critica.

La historia de Andres: mi primera contratacion en Colombia

Nuestro primer senior developer fuera de Espana fue Andres, un backend engineer en Medellin. Encontre su perfil en LinkedIn porque habia escrito un articulo tecnico en Medium sobre migracion de monolito a microservicios en una fintech colombiana. El articulo era claro, honesto sobre los errores que habian cometido, y mostraba exactamente el tipo de pensamiento que necesitabamos.

Le escribi un mensaje directo bastante personal, explicandole nuestro reto tecnico especifico. Me respondio en dos horas. Hicimos la prueba de trabajo asincrona y su entrega fue la mejor que habiamos visto: no solo resolvio el problema, sino que documento tres enfoques alternativos con los trade-offs de cada uno.

Pero la contratacion casi se cae por un tema que no habiamos anticipado: la estructura legal. No teniamos entidad en Colombia y Andres no queria facturar como freelance. Terminamos usando Deel para la contratacion, lo que anadio un 15% de coste pero nos permitio ofrecerle un contrato con beneficios locales. Esa leccion nos llevo a montar una estructura de Employer of Record antes de seguir contratando en LATAM, lo que nos ahorro tiempo y problemas en las siguientes 12 contrataciones en la region.

Andres se convirtio en nuestro tech lead del squad de pagos en ocho meses. Hoy sigue siendo una de las mejores contrataciones que he hecho en mi carrera.

Fase 3: Operar con velocidad real cuando tu equipo esta en cinco paises

Contratar bien es la mitad del reto. La otra mitad es que el equipo funcione a velocidad real, no a la velocidad reducida que muchos equipos remotos aceptan como normal.

Tu sistema de comunicacion tiene que ser explicito, no implicito

En una oficina, la comunicacion ocurre por osmosis. Escuchas conversaciones, pillas contexto sin buscarlo, le preguntas algo al de al lado. En remoto, si no disenas el sistema de comunicacion, no existe. Y lo que no existe se convierte en mensajes directos desordenados, informacion perdida y decisiones que nadie sabe quien tomo.

Nuestro sistema, despues de muchas iteraciones:

Canales por proposito bien definidos. No por equipo, por proposito. Un canal para decisiones de arquitectura (#arch-decisions), otro para incidentes (#incidents), otro para preguntas de producto (#product-questions). Cada canal tiene una descripcion que dice exactamente para que se usa y que NO va ahi. Parece excesivo? Cuando tienes 30 personas, es la diferencia entre encontrar una decision en 30 segundos o en 30 minutos.

Nivel de respuesta esperado por canal. #incidents: respuesta en 15 minutos durante horario laboral. #arch-decisions: respuesta en 24 horas. #random: cuando te de la gana. Esto elimina la ansiedad de "tengo que responder a todo inmediatamente" que quema a la gente en remoto.

Documentacion como output por defecto. Si una decision se tomo en una videollamada, no existe hasta que alguien la escribe. Punto. Tuvimos una regla explicita: la persona que convoca la reunion es responsable de publicar las decisiones en el canal correspondiente dentro de las dos horas siguientes. Si no lo hace, las decisiones se consideran no tomadas.

Estructura de reuniones que no mata la productividad

Las reuniones son el cancer de los equipos remotos cuando no se gestionan bien. Vi equipos donde la gente pasaba 4 horas al dia en videollamadas y luego se quejaba de que no tenia tiempo para programar. Nuestro framework:

Standup asincrono diario: cada persona escribe en un formulario automatizado tres cosas antes de las 10:00 de su hora local. Que hizo ayer, que va a hacer hoy, si esta bloqueado por algo. Tiempo: 5 minutos. Cero videollamadas. Uso un bot que lo publica automaticamente en el canal del squad. Si alguien reporta un bloqueo, el engineering manager tiene 30 minutos para responder o asignar ayuda.

Weekly de equipo tecnico: 60 minutos, video obligatorio, camaras encendidas. Esta es la unica reunion semanal para todo el equipo de ingenieria. La estructura es fija: 15 minutos de metricas (cycle time, bugs abiertos, cobertura de tests), 30 minutos de demos de features completadas, 15 minutos de decisiones pendientes con votacion. Si una decision necesita mas de 15 minutos, se saca a un documento asincrono.

1:1 manager-IC: quincenal como minimo, semanal para personas con menos de tres meses en el equipo. Duracion: 30 minutos. El IC pone la agenda, no el manager. Esto es critico porque en remoto los problemas se esconden mas facilmente que en una oficina. Si el IC no tiene nada que hablar, eso en si mismo es informacion que el manager debe investigar.

Haciamos las cuentas: con este framework, un IC dedicaba maximo 2.5 horas semanales a reuniones. Eso dejaba mas de 35 horas para trabajo profundo. Comparalo con la media de la industria, que anda por las 8-12 horas semanales en reuniones.

Gestionar el rendimiento sin convertirte en un microgestor

Medir el rendimiento en remoto sin caer en la microGestion es un equilibrio dificil. He visto dos extremos: CTOs que instalan software de tracking de pantalla (por favor, no hagas eso) y CTOs que no miden absolutamente nada y se sorprenden cuando el equipo esta estancado.

Lo que nos funciono fue medir outputs del sistema, no actividad individual:

Cycle time y lead time en el sistema de tickets. No miramos cuantas horas trabaja alguien, miramos cuanto tarda un ticket desde que se empieza hasta que esta en produccion. Nuestro objetivo era cycle time medio de 3 dias para tickets estandar. Cuando subia por encima de 5 dias de forma consistente, investigabamos por que. Normalmente el problema era del proceso (code reviews lentas, entorno de staging roto), no de la persona.

Calidad del output tecnico medida en bug rate por feature y cobertura de tests. Cada squad tenia un dashboard con estas metricas. Si un squad lanzaba features con bug rate por encima del 8%, haciamos una retro especifica para entender que estaba fallando en su proceso de QA.

Participacion en revisiones y documentacion. Esto es mas cualitativo pero igualmente importante. En un equipo remoto, las personas que solo escriben codigo pero nunca revisan PRs de otros ni documentan sus decisiones crean silos de conocimiento peligrosos. Lo medimos de forma trimestral y lo incluiamos en las conversaciones de desarrollo profesional.

Fase 4: Construir cultura tecnica cuando nadie comparte oficina

La cultura no se crea con canas de cerveza virtuales (por favor, dejemos de hacer eso). Se crea con rituales que refuerzan los comportamientos que quieres ver y con artefactos que hacen visible como piensa y decide el equipo.

Los tres artefactos culturales que mas impacto tuvieron en nuestro equipo:

ADRs (Architecture Decision Records): cada decision tecnica significativa se documenta en un formato estandar con contexto, opciones evaluadas, decision tomada y consecuencias esperadas. Cuando llegamos a tener 120 ADRs, cualquier persona nueva podia entender por que el sistema era como era sin tener que preguntarle a nadie. Eso es cultura tecnica cristalizada en documentos.

Post-mortems sin culpa: cada incidente de severidad 1 o 2 genera un post-mortem publico en las 48 horas siguientes. La estructura es rigida: timeline, causa raiz, acciones correctivas con owners y fechas. La regla mas importante: el post-mortem analiza sistemas, no personas. "El sistema de alertas no detecto el incremento de latencia" es valido. "Fulanito no reviso las alertas" no lo es. Esto creo una cultura donde la gente reportaba errores rapido en lugar de esconderlos.

Celebracion explicita de trabajo completado: en remoto, terminar algo grande puede sentirse como un anticlima porque no hay nadie a tu lado para chocar los cinco. Creamos un ritual semanal: en la weekly, dedicamos los ultimos 10 minutos a que cada squad presente su logro de la semana. No tiene que ser algo enorme, puede ser "redujimos el tiempo de build de 12 a 4 minutos". La clave es el reconocimiento publico y especifico.

Onboarding estructurado: las primeras semanas definen los proximos meses

El onboarding remoto es donde mas startups la pifian. Le dan acceso al repo a la persona nueva, le mandan un documento de "como configurar el entorno" escrito hace 8 meses que ya no funciona, y esperan que en dos semanas este produciendo como alguien que lleva un ano. No funciona asi.

Nuestro framework de onboarding, refinado despues de incorporar a 42 personas:

Semana 1: el entorno de desarrollo tiene que estar funcionando el primer dia. No el segundo, no el tercero, el primero. Si tu proceso de setup tarda mas de 4 horas, tienes un problema de tooling que debes arreglar antes de contratar a nadie. Primer PR mergeado antes del viernes, aunque sea un cambio trivial como actualizar un README. Un 1:1 de 20 minutos con cada miembro del squad para ponerle cara al equipo. Buddy asignado: una persona del equipo que responde dudas sin juzgar.

Semanas 2-3: primer ticket de complejidad media completado de forma autonoma. "Autonoma" no significa sin ayuda, significa que la persona lidera la solucion y pide ayuda cuando la necesita en lugar de que alguien le diga cada paso. El buddy sigue disponible pero ya no hace check-ins proactivos, espera a que la persona nueva le busque.

Mes 2: la persona nueva debe contribuir a una decision tecnica documentada. Puede ser tan simple como proponer una mejora en el proceso de code review o sugerir una libreria alternativa para un problema concreto. Lo que importa es que participe activamente en la conversacion tecnica del equipo, no solo que ejecute tickets.

Mediamos el exito del onboarding con una metrica simple: tiempo hasta el primer PR de produccion que resuelve un ticket real (no trivial). Nuestro objetivo era 10 dias laborables. La media real era 12. Los equipos que no miden esto suelen tener medias de 25-30 dias y ni siquiera lo saben.

Los errores que mas caro nos costaron

Despues de tres anos construyendo este equipo, estos son los errores que nos costaron mas tiempo y dinero. Los ordeno por impacto, no por frecuencia:

Contratar rapido y documentar tarde. Durante los primeros seis meses contratamos a seis personas sin tener documentacion decente del sistema. Cada persona nueva necesitaba dias de pair programming con alguien senior para entender la arquitectura. Cuando calcule el coste, eran unas 40 horas de tiempo senior por cada nuevo hire, multiplicado por seis. 240 horas de un senior a 65 euros la hora son 15.600 euros tirados en un onboarding que podria haberse resuelto con documentacion de 20 paginas que se escriben en una semana.

Ignorar las diferencias de zona horaria hasta que generan bloqueos. Contratamos a alguien en Chile sin pensar que su horario laboral solapaba exactamente 2 horas con el de Madrid. Durante un mes funciono porque estaba en onboarding y trabajaba con materiales asincronos. Cuando empezo a necesitar code reviews en tiempo real y discusiones de arquitectura, todo se atascaba. Tuvimos que mover su asignacion a un squad con menos dependencias sincronas. Leccion: piensa en las zonas horarias ANTES de la oferta, no despues.

Tratar la comunicacion escrita como habilidad opcional. Tuvimos a un senior engineer brillante tecnicamente que escribia PRs con descripciones de una linea y nunca documentaba sus decisiones. En una oficina, habria funcionado porque le preguntas directamente. En remoto, creo un silo de conocimiento alrededor de un microservicio critico que nadie mas entendia. Cuando esa persona se fue, tardamos tres semanas en entender completamente lo que habia construido. Ahora la comunicacion escrita es un criterio de contratacion no negociable.

Escalar el equipo antes de que los procesos soporten el crecimiento. Pasamos de 8 a 20 personas en cuatro meses porque teniamos presion de la ronda de inversion. Los procesos que funcionaban para 8 personas (basicamente, todo en un canal de Slack) colapsaron. Las code reviews tardaban 3 dias, la gente no sabia quien tomaba que decisiones, y la calidad del codigo bajo visiblemente. Tuvimos que frenar la contratacion durante seis semanas para reestructurar procesos. Esas seis semanas nos habrian costado cero si hubiesemos montado los procesos antes de escalar.

Lo que nadie te cuenta sobre liderar ingenieria en remoto

Liderar un equipo tecnico distribuido es un trabajo profundamente solitario si no lo gestionas bien. Como CTO, eres la persona que tiene que transmitir energia y direccion a traves de una pantalla, y eso consume mas que hacerlo en persona. Tres cosas que haria diferente si empezara de nuevo:

Habria invertido en mi propia red de CTOs remotos desde el primer dia. Las decisiones que mas me costaron fueron las que tome en solitario porque no tenia a nadie con experiencia similar a quien consultar. Unirme a una comunidad de CTOs de startups distribuidas cambio la calidad de mis decisiones de forma notable.

Habria contratado al engineering manager antes. Lo hice cuando teniamos 15 personas, deberia haberlo hecho con 8. Esos meses gestionando directamente a 15 ICs me dejaron sin tiempo para la estrategia tecnica y la arquitectura, que es donde un CTO aporta mas valor.

Y habria documentado la cultura desde el primer dia, no cuando ya teniamos problemas. Los valores del equipo, los comportamientos esperados, como tomamos decisiones, que hacemos cuando no estamos de acuerdo. Todo eso deberia estar escrito antes de la persona numero 5, no despues de la persona numero 20.

Si estas montando o escalando un equipo tecnico distribuido y quieres evitar los errores que a nosotros nos costaron meses, hablemos sobre tu situacion concreta. Despues de haber pasado por todo esto, lo mas valioso que puedo hacer es ahorrarte el camino de ensayo y error.