Las grandes empresas | Original, traducido por IA
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 eso necesitan revisar 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 para valer 300 mil millones o 1 billón de dólares; deben haber cometido toneladas de errores y haber crecido 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 lograrlo. En Silicon Valley, hay tantas startups, algunas de las cuales tienen éxito incluso al 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 valen 5 mil millones o 10 mil millones de dólares solo cuando tienen unos pocos meses de antigüedad.
Se dice que el laboratorio de máquinas pensantes de Mira Murati vale $12 mil millones en la ronda de semillas. Y la superinteligencia segura 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 en solitario, solo necesito usar 1 minuto para desplegar mi servidor backend y 5 minutos para arreglar 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 las comprobaciones de salud.
Aunque el tiempo real invertido pueda ser de 8 horas, si lo medimos, sigue siendo 1 semana desde la preparación del despliegue hasta la comprobación de salud final.
Para arreglar 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 lo 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 devolvérselo 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. No está 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 llevaban de seis meses a un año en la empresa no pudieron hacer contribuciones significativas. El cronograma típicamente incluía dos meses para aprender lo básico, tres meses para familiarizarse con los proyectos, tres meses navegando por 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.
Parecía 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 llevaban poco tiempo en la empresa, 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 obtuvo mucha información de la situación, ya que este era solo uno de tres departamentos bajo su supervisión y su compensación permaneció sin cambios. Incluso dentro del equipo, aquellos que no fueron 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 realmente es serio. Algunos de los fundadores que pierden o fracasan están pasando 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, quizás 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 plugin Spotless o Checkstyle para ayudar. Estos plugins 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 la universidad. 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 está bien.
Pero como el AI, en realidad, muchos usuarios están bien con productos que no son tan estables al principio, como Deepseek. Sabemos que Deepseek tuvo muchos problemas alrededor de febrero y marzo de 2025 cuando ganó mucha atención. Pero después de un tiempo, se vuelve mejor y los usuarios no parecen tener muchos problemas con eso.
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 para 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 código para aprobar o rechazar las solicitudes automáticamente?
Porque todo es lento allí, es poco probable que los trabajadores cambien las cosas. El cambio de un proyecto monolítico grande a microservicios para un proyecto que ha estado en funcionamiento durante una década podría tomar dos años.
Para el software, el código y la lógica están estrechamente entrelazados, especialmente en sistemas bien diseñados. Por lo tanto, el desarrollo, las pruebas o la colaboración involucradas pueden ser sustanciales.
Por eso escalar un equipo de repente a menudo no funciona. Si hay una arquitectura de microservicios que está débilmente acoplada, entonces la producción del equipo puede ser proporcional al número de miembros del equipo. Si hay un proyecto monolítico que está fuertemente acoplado, entonces la producción del equipo puede aumentar solo en un 30% si duplicamos el tamaño del equipo que trabaja en él.
Debido a su ritmo lento, a veces puede ser difícil determinar si un empleado o contratista es incapaz o si el sistema es demasiado complejo y engorroso para los nuevos miembros. En un caso que observé, alguien llevaba cuatro meses en la empresa 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 múltiples miembros del equipo trabajando en tareas duplicadas. Por ejemplo, para la tarea A y la tarea B, no asignan a dos ingenieros del equipo a 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 ello.
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. Esto es probablemente lo más importante que priorizan. Han aprendido esto de la manera difícil y lo han incorporado a 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 se basan en la velocidad, sino en su tamaño, recursos y marca.
¿Cómo sobrevivir en las grandes empresas? Una es hacer más, hablar menos. Esto es lo que me 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.