Incorporar ingenieros más rápido (no con más documentación)
Cómo incorporar ingenieros más rápido resolviendo el cuello de botella real: el contexto disperso en Slack, GitHub y Linear que ningún wiki captura.
By Ellis Keane · 2026-03-31
Cuando me uní a un equipo que no tenía ni idea de cómo trabajaba
Si te preguntas cómo incorporar ingenieros más rápido, déjame contarte mi propia experiencia de incorporación – porque probablemente es el mejor argumento que tengo.
En 2019 me uní a una startup en San Francisco como su tercer ingeniero. El CTO – un tipo brillante y espectacularmente desorganizado – me entregó un portátil el primer día y básicamente dijo: «El código está en GitHub. Usamos Slack para todo lo demás. Buena suerte.»
Ese era el programa de incorporación.
Pasé mis primeras tres semanas haciendo algo que, en retrospectiva, no tenía nada que ver con la ingeniería: arqueología. Rebuscando en hilos de Slack de hace seis meses para entender por qué el sistema de autenticación estaba construido de esa manera. Desplazándome por PRs cerrados de GitHub para encontrar conversaciones sobre decisiones de esquema de base de datos que nadie había documentado en ningún sitio (porque claro que no). Haciendo preguntas en #general que se respondían con «ah sí, eso – cambiamos de opinión en enero, mira el hilo con nuestro diseñador.»
¿Qué hilo? ¿Con qué diseñador? ¿En qué canal?
No era mal gestor. Trabajaba en un mundo donde el conocimiento institucional vivía exclusivamente en las cabezas de las personas y disperso entre cuatro herramientas distintas – lo cual, si somos honestos, describe a la mayoría de los equipos de ingeniería. Cada pregunta que hacía requería que alguien dejara lo que estaba haciendo, cambiara de contexto al «modo de incorporación», buscara el hilo o documento relevante y luego intentara reconstruir el razonamiento detrás de una decisión que había tomado meses atrás. Casi podías escuchar los engranajes mentales chirriar.
Tres semanas de un ingeniero haciendo arqueología en vez de ingeniería, más el coste acumulado de interrupciones de todos los que respondían mis preguntas – eso es dinero real, aunque nunca aparezca en un balance.
Y esa experiencia tampoco era única. Pasé una década dirigiendo Vulcan, nuestra agencia de diseño e ingeniería, y una cantidad sorprendente de ese tiempo entré en organizaciones que estaban incluso más desorganizadas que yo (un listón bajo, la verdad). Cada cliente, el mismo patrón: el conocimiento existía, solo que vivía en las cabezas de las personas y en herramientas que a nadie se le ocurrió conectar.
Cómo incorporar ingenieros más rápido: resuelve el problema de búsqueda, no el de documentación
La mayoría de los manuales de incorporación tratan el onboarding de ingenieros como un problema de contenido. ¡Escribe mejores docs! ¡Crea un wiki en Notion! ¡Haz una lista de verificación de incorporación con hitos codificados por colores!
Las listas de verificación están bien. No voy a decirte que tires tu plantilla «Día 1 – Día 30». Pero el cuello de botella real no es «no tenemos suficiente documentación». Es que el contexto útil – lo complicado, matizado y real – vive en hilos de Slack, comentarios de PRs de GitHub, descripciones de issues de Linear y la ocasional anotación de Figma que un diseñador dejó seis semanas antes de que llegara el nuevo empleado. Hemos pasado colectivamente dos décadas construyendo wikis que describen qué hace el software, y casi nada de tiempo haciendo que el porqué sea descubrible.
Ningún wiki captura el «porqué». Los wikis capturan lo que alguien consideró que valía la pena escribir – lo cual es algo completamente distinto de lo que un nuevo ingeniero realmente necesita saber.
El verdadero cuello de botella en la incorporación no es la documentación – es que el contexto útil vive en herramientas que a nadie se le ocurrió buscar. attribution: Chris Calo
Cuando desde entonces he incorporado ingenieros – primero en una agencia de diseño, luego construyendo Sugarbug – he observado el mismo patrón repetirse. Las preguntas que hacen los nuevos empleados caen en aproximadamente cuatro categorías, y solo una de ellas está cubierta por los docs de incorporación tradicionales:
Lo que cubren los docs
- Visión general de arquitectura – diagramas del sistema, límites de servicios, topología de despliegue
- Configuración local – cómo clonar, construir, ejecutar y probar
- Estándares de código – reglas de linting, convenciones de PRs, patrones de nomenclatura
Lo que los docs omiten
- Historial de decisiones – ¿por qué esta arquitectura y no las tres alternativas discutidas en Slack?
- Conocimiento tribal – ¿quién es realmente responsable del módulo de facturación? ¿quién tomó esa decisión de CSS?
- Cadenas de contexto – un issue de Linear vinculado a un PR vinculado a una discusión de diseño vinculada a una especificación de producto
- Estado activo – ¿en qué se está trabajando ahora mismo y por qué?
La columna «Lo que cubren los docs» es para lo que optimizan la mayoría de los equipos. En mi experiencia, la columna «Lo que los docs omiten» es donde los nuevos ingenieros pasan la mayor parte de su tiempo de adaptación – ahí es donde viven las respuestas reales, y ahí es donde nadie piensa en dirigir a los nuevos empleados.
Esa información no falta porque nadie la haya escrito. Fue escrita – en un mensaje de Slack, un comentario de revisión de GitHub, una actualización de issue de Linear. El problema es la descubribilidad, no la documentación.
El impuesto de interrupciones que nadie presupuesta
Cada vez que un nuevo ingeniero pregunta «¿por qué lo construimos así?» y un ingeniero sénior deja lo que está haciendo para responder, suceden dos cosas. El nuevo empleado obtiene una respuesta (bien), y el ingeniero sénior pierde un trozo significativo de concentración productiva – no los 2 minutos que tardó la pregunta, sino los aproximadamente 15 minutos que lleva encontrar el hilo relevante, recordar el razonamiento y volver a enfocarse en lo que estaba haciendo antes.
stat: "Varias al día" headline: "Interrupciones de un solo ingeniero en período de adaptación" source: "Basado en nuestros propios patrones de incorporación en Sugarbug"
Cuando contratas dos ingenieros en el mismo trimestre (lo cual, si eres una startup en crecimiento, probablemente haces), tu equipo existente absorbe un número genuinamente irrazonable de interrupciones durante semanas. Las personas que contrataste para aumentar la velocidad la están, temporalmente, reduciendo. Nadie lo presupuesta porque nadie lo mide – simplemente aparece como una vaga sensación de que «el equipo parece más lento este trimestre» sin que nadie lo conecte con la incorporación.
Y la parte que más duele: las respuestas a estas preguntas ya existen en algún lugar. Están en Slack, en GitHub, en Linear. La información fue capturada en el momento en que se tomó la decisión. Solo está en una herramienta que nadie le dijo al nuevo empleado que buscara, en un canal que no sabe que existe, bajo un título de hilo que no tiene sentido fuera de contexto.
Contexto conectado: qué significa en la práctica
El contexto conectado en la incorporación de ingenieros significa que un nuevo empleado puede buscar en todas las herramientas que usa tu equipo – Slack, GitHub, Linear, Notion – desde una sola interfaz. No solo búsqueda por palabras clave (la búsqueda de Slack es, seamos honestos, adecuada en el mejor caso y activamente hostil en el peor), sino búsqueda contextual que entiende las relaciones entre las cosas.
«Muéstrame todo lo relacionado con la refactorización del módulo de facturación» devuelve: el epic de Linear, los seis PRs en GitHub, el hilo de Slack donde el equipo debatió el enfoque y el documento de arquitectura de Notion – todo conectado, todo en orden cronológico, sin arqueología.
Ese es el concepto: un grafo de conocimiento que mapea las relaciones entre el trabajo de tu equipo en todas las herramientas, creando un índice dinámico de quién decidió qué, dónde y por qué.
Ben y yo construimos esto porque llevábamos años viviendo la alternativa. En Vulcan, gestionábamos equipos de diseño e ingeniería en varias organizaciones a la vez, y sin excepción, nuestras especialidades reales se reducían a una sola cosa: routers humanos glorificados de información. Dos personas que deberían haber estado diseñando y construyendo pasaban sus días respondiendo «¿dónde está eso?» (un descubrimiento desolador, créeme). Tenía que parar.
El contexto conectado no se trata de escribir más documentación – se trata de hacer que el contexto que ya existe en tus herramientas sea descubrible, buscable y vinculado. Los nuevos ingenieros no deberían necesitar saber en qué canal de Slack buscar ni qué repositorio de GitHub revisar.
Esto es lo que estamos construyendo con Sugarbug. El grafo de conocimiento conecta issues de Linear con PRs de GitHub, con conversaciones de Slack, con docs de Notion, y hace todo buscable. Cuando se une un nuevo empleado, tiene el historial de decisiones del equipo disponible desde el primer día. (Todavía estamos perfeccionando los flujos de trabajo específicos de incorporación, honestamente – pero el grafo subyacente es la base.)
Un marco de incorporación de ingenieros de 3 semanas
Bien, aquí está el marco que ojalá hubiera tenido cuando me entregaron ese portátil y me desearon «buena suerte». Si estás intentando descubrir cómo incorporar ingenieros más rápido, esto funciona porque aborda el cuello de botella real (descubribilidad) en vez del imaginario (volumen de documentación).
Semana 1: Orientarse
Empareja al nuevo empleado con un «compañero de contexto» – no un mentor, sino alguien que sepa bien dónde vive la información (no necesariamente la persona más senior – a veces es la persona que más preguntas ha hecho recientemente y tiene el mapa más actualizado de dónde están las cosas). El trabajo del compañero de contexto no es responder cada pregunta. Su trabajo es decir: «Esa decisión se tomó en el canal #backend alrededor de febrero, déjame ayudarte a encontrar el hilo.»
Si usas una herramienta de contexto conectado como Sugarbug, el trabajo del compañero de contexto se vuelve considerablemente más fácil: «Busca "refactorización del módulo de facturación" y verás la cadena de decisión completa.»
Semana 2: Navegar
El nuevo empleado debería estar haciendo sus primeros PRs ya, pero más importante aún, debería estar construyendo su modelo mental de cómo se comunica el equipo. ¿Qué discusiones ocurren en Slack? ¿Cuáles en comentarios de Linear? ¿Cuáles en revisiones de PRs de GitHub? Entender la topología de comunicación importa tanto como entender el código – posiblemente más, en el primer mes. (He visto ingenieros que entendieron el código en una semana pero seguían sin saber dónde encontrar las decisiones tres semanas después.)
Semana 3: Contribuir
En la semana tres, si el problema de contexto está resuelto, un nuevo ingeniero debería estar haciendo contribuciones significativas – no porque haya memorizado el código, sino porque sabe cómo encontrar lo que necesita sin interrumpir a nadie.
- [x] Día 1: Entorno local funcionando, acceso a todas las herramientas concedido
- [x] Día 2–3: Compañero de contexto asignado, introducción a la topología de comunicación
- [x] Semana 1: 2–3 «buenos primeros issues» completados con apoyo del compañero de contexto
- [ ] Semana 2: Haciendo PRs independientes, buscando contexto antes de preguntar
- [ ] Semana 3: Contribuyendo a discusiones de diseño, revisando PRs de otros
- [ ] Mes 2: Productivo de forma independiente, revisiones semanales con compañero de contexto
Por qué esto se multiplica (y los wikis no)
La diferencia entre resolver la incorporación de ingenieros con contexto conectado y resolverla con un wiki de Notion de 47 páginas que nadie mantiene (ya sabes cuál – actualizado por última vez hace ocho meses por alguien que ya se fue) es que el contexto conectado se multiplica. Cada conversación que tu equipo tiene en Slack, cada revisión de PR, cada actualización de issue de Linear – todo se indexa, vincula y hace buscable. El grafo de conocimiento se enriquece con el tiempo sin que nadie haga trabajo adicional.
Tu segunda contratación se beneficia de todo lo que las preguntas de incorporación de tu primera contratación descubrieron. Tu quinta contratación tiene un grafo aún más rico. En la décima, el conocimiento institucional que antes vivía exclusivamente en la cabeza de tu CTO está distribuido, buscable y conectado.
Y esa es la parte que genuinamente me entusiasma de este enfoque. No solo la ganancia de eficiencia – aunque de nuestras conversaciones tempranas con equipos que prueban el contexto conectado, la compresión del tiempo de adaptación es real. Y aquí está la parte que no esperaba: Ben y yo somos muy habladores, y la mitad de nuestras mejores ideas desaparece en el ruido del día a día antes de que alguno de los dos las escriba (muy profesional, lo sé). El grafo sigue sacando a la superficie atajos e ideas genuinamente útiles de nuestras propias conversaciones que habíamos olvidado por completo. Si puede rescatar contexto de las dos personas que lo construyeron, imagina lo que hace por un nuevo empleado que entra en un equipo de quince.
El valor más profundo, para equipos que genuinamente intentan incorporar ingenieros más rápido, es que dejas de perder conocimiento institucional cuando la gente se va. La cadena de contexto de sus decisiones se queda, buscable, para todos los que vengan después. Eso no es una ganancia de eficiencia. Eso es memoria organizacional.
Recibe inteligencia de señales directamente en tu bandeja de entrada.
Preguntas frecuentes
Q: ¿Cuánto tiempo debería tardar la incorporación de un nuevo ingeniero? A: Según nuestra experiencia y las conversaciones con otros equipos de ingeniería, 2–3 meses es lo habitual antes de que un nuevo ingeniero sea completamente productivo. El cuello de botella rara vez es la habilidad técnica – es aprender dónde viven las decisiones, quién es responsable de qué y cómo se comunica realmente tu equipo entre herramientas. Los equipos que usan herramientas de contexto conectado informan de una reducción significativa de este tiempo, aunque la mejora exacta depende del tamaño del equipo y la complejidad de las herramientas.
Q: ¿Ayuda Sugarbug con la incorporación de ingenieros? A: Sí. Sugarbug crea un grafo de conocimiento dinámico en tus cuentas de Linear, GitHub, Slack y Notion, para que los nuevos ingenieros puedan buscar en todas las herramientas decisiones pasadas, contexto sobre por qué se construyeron las funcionalidades y a quién preguntar sobre qué, sin interrumpir a nadie.
Q: ¿Qué es el contexto conectado en la incorporación de ingenieros? A: El contexto conectado significa vincular información entre herramientas para que un nuevo empleado pueda rastrear una decisión desde el issue de Linear, pasando por el PR de GitHub, hasta el hilo de Slack donde el equipo debatió el enfoque. Cuando esa cadena es buscable, el tiempo de adaptación se reduce porque el nuevo empleado puede encontrar respuestas por sí mismo sin interrumpir a los compañeros.
Q: ¿Por qué los wikis de incorporación tradicionales no funcionan para ingenieros? A: Los wikis capturan lo que alguien consideró que valía la pena escribir – visiones generales de arquitectura, guías de configuración, estándares de código. El verdadero cuello de botella en la adaptación es el material complicado y contextual que vive en hilos de Slack, comentarios de PRs e issues de Linear. ¿Por qué se construyó esto así? ¿Quién tomó esa decisión? Ese contexto ya está capturado en tus herramientas – el problema es encontrarlo, no escribirlo.
Q: ¿Se integra Sugarbug con GitHub y Linear para la incorporación? A: Sí. Sugarbug se conecta a GitHub, Linear, Slack, Notion, Figma y Google Calendar mediante API, indexando conversaciones, issues, PRs y documentos en un grafo de conocimiento buscable que los nuevos ingenieros pueden consultar desde el primer día.