Las grandes empresas | Original, traducido por IA
Sobre Grandes Empresas
Las grandes empresas son como grandes programas. Para una gran empresa con 100,000 empleados y 50,000 contratistas, son como un gran programa con 150,000 métodos.
Dario Amodei dijo que la densidad de talento es mucho más importante que el número de talentos. Dos cientos de personas muy talentosas pueden vencer a 1,000 personas talentosas con 800 personas ordinarias.
Dario Amodei también mencionó que las grandes empresas tienen tantos procedimientos y procesos porque no confían en sus empleados o contratistas. Por lo tanto, necesitan verificar mucho y controlar mucho.
Una cosa sobre las grandes empresas es que les da miedo cometer errores. Una razón es que han crecido tanto hasta valer 300 mil millones o 1 billón de dólares; deben haber cometido toneladas de errores y haberse desarrollado a partir de eso. Sin embargo, cuando son exitosas, son reacias a tomar riesgos y cometer errores nuevamente.
Es como un gran programa que no le gustan los errores y trata de eliminar cualquier error, especialmente los errores de seguridad, particularmente en los grandes bancos.
Las startups son rápidas, pero los recursos de una startup son mucho menos, y la marca de una startup no está establecida; no tienen la confianza de las grandes empresas.
En China, los jóvenes talentosos aún quieren ir a las grandes empresas después de graduarse y luchan por hacerlo. En el Valle del Silicio, hay tantas startups, algunas de las cuales tienen éxito desde el principio con solo ideas.
Algunas empresas duran 20 años y aún luchan, probablemente hayan sido eliminadas del mercado de valores, y algunas empresas son valoradas en 5 mil millones o 10 mil millones de dólares solo cuando tienen unos pocos meses de antigüedad.
Se dice que el laboratorio Thinking Machines Lab de Mira Murati vale $12 mil millones en la ronda de semillas. Y Safe Superintelligence de Ilya Sutskever recaudó $2 mil millones con una valoración de $32 mil millones.
Por lo tanto, usar el tiempo establecido para medir una startup no es un buen indicador; es mejor medirla por lo que es el equipo, quiénes son los fundadores y en qué área están.
En mi startup individual, solo necesito usar 1 minuto para desplegar mi servidor backend y 5 minutos para corregir un error menor y desplegar. Es directo y rápido. Para las grandes empresas, toma 1 semana preparar la solicitud de despliegue, obtener aprobaciones de los gerentes, hacer el despliegue con el equipo de TI y hacer verificaciones de salud.
Aunque el tiempo real invertido podría ser de 8 horas, si lo medimos, sigue siendo 1 semana desde la preparación del despliegue hasta la verificación final de salud.
Para corregir un error menor y desplegar, toma dos semanas hacerlo. Obtienes el ticket para investigar, hacer análisis y pruebas, luego revisar, fusionar el código, informar a los equipos de prueba para que prueben y luego desplegar.
Las grandes empresas les gusta imponer sus políticas en todos los equipos o proyectos. Porque para una gran empresa con 200,000 personas, esas políticas o procesos internos que se aplican solo a 10,000 personas no tienen mucho significado o resultado. Para algunos procesos internos, las grandes empresas necesitan invertir personas o dinero para desarrollar herramientas que los apoyen. Por lo tanto, si solo sirve a una pequeña proporción del personal, el retorno no justifica la inversión.
Otra desventaja de las grandes empresas es que a menudo nadie es castigado por grandes errores.
En mi startup, una vez obtuve una inversión de medio millón para contratar a 9 personas, y después de 2 meses, tuve que despedirlas y perder ese dinero. Hice 50 pequeños proyectos de software con ingenieros a tiempo parcial para recuperar ese dinero y devolverlo al inversor.
Esa es una memoria muy intensa y dolorosa. Y eso me hizo recordar esa lección todo el tiempo.
En un caso notable dentro de una gran corporación, se observó que no hubo consecuencias significativas para los involucrados. Algunos gerentes senior y muchos de los empleados recién contratados fueron despedidos. Sigue sin estar claro si esto estaba relacionado con una contratación rápida y sustancial.
Un factor contribuyente a este resultado son los procesos engorrosos y numerosos dentro de las grandes empresas. Los ingenieros que habían estado en la empresa durante seis meses a un año no pudieron hacer contribuciones significativas. El cronograma típicamente incluía dos meses para entender lo básico, tres meses para familiarizarse con los proyectos, tres meses navegando a través de procedimientos tediosos o pruebas, y finalmente, dos meses de trabajo productivo que impactó a los usuarios.
Asumiendo una jornada laboral de ocho horas, dos meses de trabajo productivo real no produjeron resultados sustanciales. El presupuesto del departamento se agotó y la base de usuarios no se expandió como se esperaba, lo que llevó a más despidos.
Parece que no se aprendieron lecciones valiosas de esta experiencia. Inicialmente, un grupo de gerentes decidió una estrategia de contratación rápida y extensa, que en ese momento parecía innecesaria. Culpar a todo el grupo de gerentes no era factible, ni era práctico despedir solo a aquellos que habían estado en la empresa por un corto período, especialmente cuando otros gerentes y líderes técnicos habían sido parte del equipo durante seis a ocho años.
El director general no ganó mucha comprensión de la situación, ya que este era solo uno de tres departamentos bajo su supervisión y su compensación se mantuvo sin cambios. Incluso dentro del equipo, aquellos que no eran directamente responsables no pudieron aprender de la experiencia, lo que refleja los comentarios de Steve Jobs sobre la consultoría. Por lo tanto, nadie absorbió la lección necesaria para formar un equipo excepcional capaz de entregar resultados sobresalientes para los usuarios.
Para las startups, parece un caso mucho mejor. Porque es realmente serio. Algunos de los fundadores que pierden o fracasan están pasando por un momento muy difícil, especialmente los honestos.
Para las personas con integridad, puede ser profundamente desalentador perder fondos de inversión sustanciales, desde millones hasta cientos de millones de dólares, y terminar con poco que mostrar, tal vez solo un producto rudimentario o una base de usuarios que, a pesar de su tamaño, genera ingresos mínimos.
Paul Graham escribió un ensayo antes, Hiring is Obsolete.
Pero, ¿qué hacen bien las grandes empresas? Una es el largo plazo. Tienden a hacer las cosas a largo plazo. Para algunas buenas grandes empresas, sus diseños de proyectos son bastante buenos; usan microservicios para evitar el error de convertirse en un gran programa monolítico después de una década. Y tienen equipos de gobernanza para hacer algunos marcos fundamentales y unificar las prácticas de desarrollo para todo el equipo.
Los procesos o procedimientos no son inherentemente malos. Pero a menudo hacen las cosas complicadas y lentas. No encontramos desagradable el formato de código unificado de Java porque hay un complemento de Spotless o Checkstyle para ayudar. Estos complementos tienen un buen diseño y son fáciles de usar.
Otra cosa es que las grandes empresas tienden a hacer algunas herramientas o proyectos para uso interno, para los oficiales de primera línea. Pero esa base de usuarios es solo cientos o 10,000. Esa base de usuarios es muy limitada.
Creo que es mejor usar herramientas externas para ese propósito. Si una herramienta es realmente buena para un banco, probablemente sea buena para 200 bancos. Y eso puede hacer que esa empresa sea una unicornio.
Tiancheng Lou, fundador de Pony.ai, dice que la razón por la que las empresas necesitan ser independientes es que es más eficiente. Eso es cierto.
Y las grandes empresas tienden a usar la experiencia para dar recompensas a los empleados. Mientras que el mercado recompensa el resultado o la ejecución para los equipos de startups. Son realmente muy diferentes.
Trabajar en grandes empresas es como aprender en la escuela. Avanzas de la escuela primaria a la secundaria, luego a las universidades. En las startups, sin embargo, hay más altibajos, y hay más flexibilidad a medida que te mueves de una idea o mercado a otro.
Para las grandes empresas, el beneficio de ser aversas al riesgo es que sus productos son relativamente estables sin errores aparentes o tiempos de inactividad. Eso es bueno.
Pero como el AI, en realidad, muchos usuarios están bien con los productos que no son tan estables al principio, como deepseek. Sabemos que deepseek se cayó mucho alrededor de febrero y marzo de 2025 cuando ganó mucha atención. Pero después de algún tiempo, se vuelve mejor y los usuarios no parecen tener muchos problemas con eso.
Por lo tanto, depende. A veces, para productos innovadores, necesitamos llevarlos al mercado rápidamente, incluso si tienen algunos problemas. Los usuarios pueden entender.
Si pensamos en el proceso, podemos ser más cuidadosos. Deberíamos categorizar mejor nuestros tipos de despliegue. Algunos tipos de cambios están bien para desplegar rápidamente, mientras que otros no. Para las pruebas, deberíamos categorizar qué partes de las pruebas necesitamos realizar para las pruebas de regresión para el código cambiado, y qué partes no. Lo mismo aplica a las comprobaciones de SonarQube.
En las grandes empresas, es cierto que muchas comprobaciones, pruebas o aprobaciones son innecesarias. Podríamos dejar que los ingenieros hagan su trabajo, y ya que el sistema tiene todos los registros, podemos seleccionar algunos para revisar.
También deberíamos eliminar todas las aprobaciones de los gerentes. ¿Qué conocimiento tienen los gerentes que los ingenieros no tienen? ¿Podría este conocimiento escribirse en el código para aprobar o rechazar las solicitudes automáticamente?
Debido a su ritmo lento, a veces es difícil determinar si un empleado o contratista es incapaz o si el sistema es demasiado complejo y engorroso para los recién llegados. En un caso que observé, alguien había estado en la empresa durante cuatro meses y había logrado muy poco, cambiando solo unas pocas líneas de código para enviar una solicitud de extracción. Además, la calidad del código era pobre ya que no lo entendía bien. Su inglés también era muy débil y solo podía comunicarse pegando capturas de pantalla y usando inglés básico para hacer preguntas.
En cuanto a la estabilidad, veo que las grandes empresas tienden a tener que varios miembros del equipo trabajen en tareas duplicadas. Por ejemplo, para la tarea A y la tarea B, no asignan a dos ingenieros del equipo para trabajar por separado en la tarea A y la tarea B. En su lugar, hacen que ambos trabajen en partes de la tarea A y la tarea B para que estos dos ingenieros sepan lo que hace el otro. Esto hace que el equipo sea más estable, ya que evita una situación en la que solo una persona sabe mucho sobre grandes partes del código y ha estado trabajando en eso durante varios años sin colaboración. Luego, si esa persona deja la empresa, nadie más puede trabajar en eso.
Otra cosa que las grandes empresas hacen bien es mantener el flujo de caja y la disciplina de ganancias. La razón es que a medida que crecen más, a menudo enfrentan crisis financieras sustanciales. Probablemente esta es la cosa más importante que priorizan. Han aprendido esto de la manera difícil y lo han incorporado en sus operaciones. Incluso cuando están haciendo ganancias de 10 mil millones de USD o 30 mil millones de USD al año, siguen optimizando su fuerza laboral y realizando despidos.
Uno de mis colegas me dijo que las grandes empresas operan con un monopolio en ciertos productos que requieren mucha mano de obra o tiempo para construir. Eso tiene sentido. No dependen de la velocidad, sino de su tamaño, recursos y marca.
¿Cómo sobrevivir en las grandes empresas? Una es hacer más, hablar menos. Así me lo dijo mi gerente de entrega en un proveedor de outsourcing.
La segunda cosa es seguir lo que hacen los demás; es seguro. Convertirse en un ingeniero promedio en el equipo es seguro, como ser una persona promedio en la calle, ni demasiado destacado ni demasiado descuidado, sino justo en el medio.
Tengo que decir que hay muchas grandes empresas. Algunas tienen más de 200,000 empleados, mientras que otras tienen alrededor de 20,000. Hay buenas grandes empresas y otras de bajo rendimiento. La apariencia o la capitalización de mercado a veces no revelan mucho. Pueden aumentar significativamente en unos pocos años, como Nvidia ha hecho recientemente, o pueden colapsar de repente, como Credit Suisse.
Ingeniería en Grandes Empresas
Las grandes empresas son buenas en su control estricto de políticas y gestión. Las grandes empresas son buenas en realizar verificaciones cuidadosas y evaluaciones exhaustivas de lanzamiento de software.
Pero mucha ingeniería no puede resolverse en reglas simples. La simplicidad del diseño y la optimización para cada método o cada clase de Java no son fáciles de verificar con reglas.
El escaneo de SonarQube es algo bueno, y una alta cobertura de pruebas es algo bueno. Pero mucho del diseño de software o la ingeniería no puede medirse tan simplemente.
La calidad de las APIs y la facilidad de uso de las funcionalidades no pueden evaluarse fácilmente.
Los parámetros de los métodos no pueden evaluarse fácilmente. El diseño de las funciones, la estrategia de ramificación, la estrategia de desarrollo no son fáciles de medir, y tampoco el nombramiento.
Alibaba tiene su guía de Java, y Google y Plantier tienen sus formatos de Java. Es bueno. Pero no todas las cosas en un proyecto de Java pueden verificarse automáticamente con código.
Sobre las pruebas, es cierto. Hay muchas herramientas de prueba automática. Pero no todas las estrategias, diseños, filosofías o técnicas de prueba tienen reglas fijas.
Sobre los productos, es cierto. Hay muchas pruebas A/B y desarrollo de productos impulsado por datos. Pero no todas las habilidades técnicas o conocimientos de los productos pueden medirse con reglas fijas.
¿Por qué quiero discutir esto? Porque significa que nuestro valor está en estos sectores. ¿Qué cosas no hacen bien las grandes empresas? Para que podamos ayudarlas a hacer esas cosas.
¿Por qué menciono la ingeniería en grandes empresas en lugar de la ingeniería en empresas? En realidad, no se trata solo de grandes empresas o pequeñas startups. Están formadas por personas; solo el número de empleados tiene alguna diferencia.
La ingeniería en grandes empresas es menos diversa que en startups.
Sobre la Colaboración
La colaboración es un desafío. Implica trabajar juntos para lograr metas comunes. Consideremos esto desde una perspectiva de codificación.
En esencia, cada individuo es como un programa complejo, construido a partir de experiencias de vida, historial laboral, visiones del mundo, relaciones cercanas, crianza y interacciones digitales.
El desafío radica en lograr una meta como equipo. ¿Cómo debería colaborar un grupo de manera efectiva? ¿Cómo pueden trabajar juntos los microservicios para funcionar en armonía?
Para proyectos personales, uno posee y maneja todo sin necesidad de colaboración. Hoy en día, las personas suelen usar numerosas herramientas de IA para lograr sus objetivos.
En un equipo pequeño de pocas personas, las responsabilidades se dividen. Por ejemplo, una persona puede encargarse del diseño mientras otra se enfoca en el desarrollo. Alternativamente, uno podría ser responsable del backend y otro del frontend.
En las grandes empresas, a menudo hay preocupación por los empleados que se van, lo que crea vacíos de conocimiento en los proyectos. Una persona nueva que asume las responsabilidades puede necesitar meses o incluso un año para ponerse al día, lo que ralentiza o estanca el proyecto.
Sin embargo, en la era de la IA, creo que deberíamos adaptar nuestro enfoque. El concepto del “mito del hombre-mes” sigue siendo cierto.
Abogo fuertemente por la colaboración natural. Para beneficio del equipo, a medida que avanza el proyecto, ciertos hábitos de colaboración se forman naturalmente dentro del equipo.
Esto es similar a la modularización natural del código. Después de algún desarrollo, podemos tener 50 clases de Java, que luego organizamos en paquetes. De manera similar, con 100 archivos de Python, usamos módulos para gestionarlos.
La separación de tareas debe considerar las fortalezas de cada persona. En la era de la IA, las personas pueden destacar en múltiples áreas. Por lo tanto, deberíamos replantearnos cómo dividir grandes tareas entre los miembros del equipo.
Creo que cada miembro del equipo debería ser responsable de una tarea relativamente grande a la vez. Este enfoque minimiza la necesidad de comunicación o alineación frecuente con otros. La tarea grande debe ser relativamente independiente, permitiendo que las personas busquen ayuda de los miembros del equipo senior que tienen más experiencia cuando sea necesario. De esta manera, más personas pueden estar involucradas, pero la tarea sigue siendo principalmente propiedad de la persona asignada.
Si dos personas colaboran para editar cada línea de código o trabajar en cada detalle juntas, puede ser engorroso. Necesitarían alinearse en cada paso, lo cual es difícil. En la computación, hay numerosas formas de lograr un objetivo. Siempre que el resultado sea de buena calidad y cumpla con el objetivo, deberíamos aceptar diferentes métodos o herramientas, ya sea un IDE específico, un cliente SQL, scripts de Python o procesos manuales.
Otra mejora en la colaboración es asegurar que los registros de trabajo sean lo más transparentes posible. En mi trabajo reciente, compartí mis scripts, registros y notas con los miembros del equipo. Puedo compartir las consultas que he realizado a Copilot, los problemas que encontré en el camino y los registros relevantes. Esta transparencia facilita la comunicación con los miembros del equipo.
Al hacer esto, es similar a grabar mi pantalla de computadora mientras realizo tareas. Aunque estamos usando texto aquí para compartir información, el objetivo de una mejor comunicación se logra.
¿Por qué falla la colaboración? ¿Qué tipos de escenarios llevan a que la colaboración no funcione? Una razón es las expectativas no coincidentes entre los miembros del equipo. El resultado posible es que el proyecto se retrase o el trabajo no cumpla con los requisitos de calidad.