Qué está pasando con la ingeniería de Meta

Meta no está teniendo un problema de talento puro. Lo que se ve, más bien, es un problema de diseño organizacional: demasiados cambios de estructura, demasiadas capas de coordinación y una presión constante por mover equipos como piezas para responder a prioridades que cambian rápido. Cuando eso pasa, la ingeniería deja de optimizar por producto y empieza a optimizar por supervivencia interna.

La pregunta no es solo si Meta está “haciendo las cosas mal”. La pregunta útil para ti, si lideras un equipo técnico, es otra: qué señales aparecen cuando una organización grande empieza a degradar su capacidad de construir software de forma sostenida. Ahí está la lección real, porque lo que le pasa a Meta hoy se parece mucho a lo que puede pasar en cualquier empresa que crece sin cuidar su sistema operativo interno.

Qué cambió en la ingeniería de Meta

El primer cambio que suele sentirse es la reorganización continua. En una empresa como Meta, mover personas entre equipos no es un detalle administrativo: cambia relaciones, dependencias, ownership y hasta el criterio de éxito. Cuando una organización se reordena con frecuencia, el costo no aparece solo en el organigrama. Aparece en semanas perdidas entendiendo contexto, en decisiones que se vuelven a tomar y en roadmap que se fragmenta.

También hay un segundo factor: la mezcla entre presión por eficiencia y presión por velocidad. Meta, como muchas big tech, ha empujado recortes, consolidación de funciones y más exigencia sobre cada manager y cada ingeniero. Eso puede mejorar el ratio de gasto por empleado en el corto plazo, pero si se hace sin proteger la autonomía de los equipos, la organización termina con más coordinación y menos ejecución real.

Y hay un tercero, menos visible pero igual de caro: la pérdida de continuidad. Cuando cambian los líderes, los scopes y las prioridades, los equipos dejan de acumular aprendizaje sobre el producto. En software, la memoria organizacional importa tanto como el código. Si la rompes, cada trimestre vuelves a pagar el precio de volver a explicar por qué existe un servicio, quién es dueño de qué y qué decisión técnica se tomó antes.

Reorganizar no es lo mismo que mejorar

Una reorganización puede ser útil si corrige límites mal definidos, elimina duplicación o alinea equipos con un producto concreto. Pero si se vuelve la herramienta principal para resolver problemas de ejecución, entonces el síntoma ya es otro. El problema no es la forma del organigrama, sino que la empresa está usando estructura para tapar falta de foco, mala priorización o incapacidad de cerrar decisiones.

Meta ha sido un caso especialmente visible porque su escala hace que cualquier cambio tenga efectos en cadena. Si un equipo pierde ownership, otro tiene que absorberlo. Si una iniciativa se redistribuye, aparecen dependencias nuevas. Si el liderazgo cambia el mensaje cada pocos meses, la gente aprende a esperar antes de comprometerse. Ese comportamiento es racional para el individuo y costoso para la empresa.

En términos prácticos, eso se traduce en más tiempo en reuniones, más revisiones cruzadas y más trabajo de coordinación que de construcción. El resultado no siempre se ve en un dashboard, pero sí en la experiencia diaria: tickets que avanzan lento, decisiones que suben de nivel demasiado pronto y managers que pasan más tiempo alineando que desbloqueando.

Cómo se rompe la productividad

La productividad en ingeniería no cae de golpe. Se erosiona en capas. Primero, se pierde claridad de ownership. Luego, se duplican aprobaciones. Después, los equipos dejan de asumir riesgos porque cada cambio puede ser reubicado, revertido o cuestionado por otra área. Cuando llegas ahí, el problema ya no es la capacidad técnica individual. Es el sistema alrededor de esa capacidad.

En organizaciones grandes, el costo de coordinación crece más rápido que el número de personas. Eso está bastante documentado en literatura de management y software. Si quieres una referencia clásica, el libro The Mythical Man-Month sigue siendo útil para entender por qué sumar gente no resuelve automáticamente la entrega. Y si quieres ver cómo piensa una empresa grande sobre estructura y escalado, la documentación pública de Google sobre equipos y prácticas de ingeniería también es una buena referencia contextual: https://rework.withgoogle.com/.

En Meta, la combinación de cambios de estructura y presión por resultados puede generar un patrón claro: más reuniones de alineación, menos tiempo profundo de desarrollo, más dependencia de managers para destrabar y más fricción para lanzar. El ingeniero senior termina actuando como traductor entre capas, no como constructor de producto.

Señales concretas de caída de productividad

Si tú lideras ingeniería, estas son señales que vale la pena medir o al menos observar de cerca:

1. El tiempo entre una idea y un primer experimento crece trimestre a trimestre.
2. Los equipos necesitan más aprobaciones para cambios pequeños.
3. Aumenta el número de reuniones de sincronización sin que baje el número de bloqueos.
4. Los PRs pasan más tiempo esperando revisión que en desarrollo activo.
5. Los managers reportan más “alineación” y menos entregas cerradas.
6. La gente nueva tarda mucho más en entender quién decide qué.

No necesitas un panel sofisticado para notar esto. Muchas veces lo ves en cosas simples: un feature que antes tomaba dos sprints ahora toma cuatro, un bug crítico se queda esperando a que otro equipo confirme ownership, o una migración técnica se posterga porque nadie quiere cargar el costo político de tocarla.

Retención: por qué se van los mejores

La retención no se rompe solo por salario. En empresas como Meta, el dinero ayuda a sostener la permanencia, pero no compensa indefinidamente la sensación de que tu trabajo pierde impacto o que la estructura cambia antes de que puedas construir algo sólido. Los mejores ingenieros suelen tolerar complejidad, pero no suelen tolerar inutilidad organizacional.

Cuando una compañía manda señales de que el foco cambia demasiado rápido, los perfiles más fuertes hacen una lectura muy simple: si no puedo ver continuidad en lo que construyo, mi curva de aprendizaje y mi reputación interna dejan de crecer. Y si además el entorno se vuelve más político, con menos claridad de decisión, el costo psicológico sube. En ese punto, otros mercados o empresas parecen una opción más racional.

Esto no significa que toda salida sea por descontento. Muchas salidas son oportunistas, pero la organización las facilita. Si los equipos sienten que su trabajo se reescribe desde arriba, que la promoción depende más de navegar cambios que de generar impacto y que el ownership se mueve sin aviso, la rotación sube. Y cuando se van los mejores, el resto de la organización pierde mentores, memoria y estándares.

Qué pasa con managers e ICs senior

En estas situaciones, los managers intermedios son los primeros en sentir el golpe. Están entre la estrategia que cambia y la ejecución que no puede esperar. Si no tienen poder real para decidir, se convierten en mensajeros de decisiones ajenas. Eso desgasta mucho, porque el rol deja de ser liderazgo y pasa a ser transmisión.

Los ICs senior también sufren, aunque de otra forma. Ellos suelen cargar con la parte más compleja del sistema: arquitectura, coordinación técnica, debugging de problemas cruzados. Si encima el contexto organizacional cambia cada poco, su trabajo se llena de interrupciones. Un ingeniero senior que pasa demasiado tiempo reexplicando contexto termina sintiendo que su impacto real se está diluyendo.

En empresas grandes, la retención de talento fuerte depende de tres cosas muy simples: problemas interesantes, autonomía y percepción de progreso. Si una de esas tres se rompe, la rotación empieza a subir. Si se rompen dos, ya no estás reteniendo por convicción; estás reteniendo por fricción.

Lo que otros líderes técnicos deberían mirar

Si tú lideras una organización de tecnología en Latinoamérica, no necesitas copiar a Meta para aprender de sus errores. De hecho, conviene hacer lo contrario: usar su escala para detectar patrones que en una empresa más pequeña pueden pasar más desapercibidos. La pregunta útil no es cuántos empleados tiene tu compañía, sino si estás construyendo una máquina que mejora con el tiempo o una que se desgasta por dentro.

Hay tres áreas que te conviene vigilar con especial cuidado: estructura, métricas y narrativa. La estructura te dice quién decide y quién ejecuta. Las métricas te dicen si el sistema entrega o solo aparenta movimiento. La narrativa te dice si la gente entiende por qué existe el cambio o si solo lo obedece.

Si la estructura cambia sin que cambien las métricas de entrega, probablemente solo moviste silos. Si las métricas mejoran pero la rotación sube, quizá estás exprimiendo a la gente. Si la narrativa ya no conecta con el trabajo diario, la organización entra en cinismo.

Señales de alerta que sí importan

Mira estas señales, porque aparecen antes de que el problema se vuelva obvio:

• El roadmap cambia sin una razón técnica o de negocio clara.
• El mismo problema se discute en tres reuniones distintas con tres decisiones distintas.
• El equipo depende de una persona clave para todo.
• Los managers pasan más tiempo en staffing que en desarrollo de personas.
• La promoción se percibe como premio a la supervivencia, no al impacto.

Si ves dos o más de estas señales durante varios meses, no estás ante un incidente aislado. Estás ante un patrón de diseño organizacional. Y los patrones, a diferencia de los bugs, no se arreglan con una hotfix.

Qué puedes hacer antes de que sea tarde

1. Define ownership explícito por producto, servicio y decisión técnica.
2. Reduce cambios de estructura a momentos con justificación clara y métricas de seguimiento.
3. Mide tiempo de ciclo, no solo output. Un equipo puede cerrar más tickets y aun así estar peor.
4. Protege bloques de trabajo profundo para ingeniería. Sin eso, la coordinación se come todo.
5. Revisa rotación de perfiles senior por equipo y por manager, no solo el total de la empresa.
6. Haz postmortems organizacionales, no solo técnicos, cuando un cambio de estructura sale mal.

La clave es que la organización no se evalúa solo por su organigrama, sino por cómo se siente trabajar dentro de ella. Si el sistema obliga a la gente a gastar energía en descifrar quién manda, probablemente ya estás perdiendo capacidad de construcción.

Qué nos enseña Meta sobre escalar mal

Meta sigue siendo una empresa con mucha capacidad técnica, producto masivo y recursos enormes. Eso hace que el caso sea más interesante, no menos. Si incluso una organización con tanto músculo puede entrar en una dinámica donde la ingeniería se siente más frágil, entonces el problema no es la falta de dinero. Es cómo se administra el crecimiento.

La lección para ti es bastante concreta: escalar no significa solo contratar más gente o moverla más rápido. Escalar bien significa mantener claridad, continuidad y confianza mientras aumentan la complejidad y la presión. Si pierdes esas tres cosas, el tamaño empieza a trabajar en tu contra.

También conviene recordar algo incómodo: muchas veces la empresa no nota el deterioro hasta que ya perdió a varias personas clave. La productividad baja primero, la retención cae después y recién entonces el liderazgo reconoce el patrón. Para evitar eso, necesitas mirar indicadores blandos y duros al mismo tiempo. No basta con revenue o entregas. También tienes que escuchar cómo habla la gente de su trabajo.

Si quieres una referencia oficial sobre cómo una organización grande piensa en estructura, revisa la documentación pública de ingeniería de Google mencionada antes. Y si te interesa el marco de gestión de equipos y escalado, la guía de Atlassian sobre team topology y colaboración también ayuda a aterrizar el tema: https://www.atlassian.com/team-playbook. No te da la respuesta exacta para Meta, pero sí un lenguaje útil para evaluar tu propia empresa.

Tabla resumen

La lectura práctica es simple: si tu organización está cambiando demasiado rápido, pregúntate si estás resolviendo un problema de negocio o solo aplazando uno de diseño interno. La diferencia entre ambas cosas se nota en semanas, en retención y en la calidad del trabajo diario.