22 - Trabajando en Big Tech - Tecnología Informal Para ser manager en Big Tech, hay que ser un técnico sobresaliente. Por eso es importante trabajar en la narrativa personal. Bienvenidos a Tecnología Informal, un espacio para hablar de carrera, inversión, producto, cultura y todo lo relacionado con startups. Yo soy Gabriel Benmergui, y soy programador con más de una década de experiencia viviendo y trabajando en California, Estados Unidos. Trabajar en startups es muy distinto que trabajar en consultoría, y trabajar en startups grandes, en las empresas más grandes del mundo, también es distinto a trabajar en cualquier otra startup. En el episodio de hoy vamos a hablar de cómo se trabaja en startups con miles de empleados, cómo funciona la tecnología, la organización, la cultura y el día a día. Big Tech es el nombre de las empresas de tecnología más grandes, que además son las empresas más grandes del mundo, como Microsoft, Meta y Google. Estas empresas, a pesar de estar en el top diez del tamaño mundial, no tienen tantos programadores. Se estima que Google tiene 20 mil programadores, Amazon 35 mil y Meta 30 mil. Coordinar como 30 mil programadores ponen código en unos pocos sitios web de la empresa es un desafío totalmente novedoso, no solo en tecnología, sino en organización humana. Las empresas más grandes pusieron los estándares en cómo crecer una organización, y eso va derramando en empresas de menor tamaño, poniendo un tono y un paradigma para todas las startups. Yo me uní a Robinhood cuando estaba creciendo mucho, no solo en su producto, sino en su equipo de ingeniería. Robinhood, en 2020 y 2021, pasó de tener cientos de empleados a miles y cientos de programadores. El contraste con mis experiencias anteriores fue muy grande, ya que siempre había trabajado en startups con menos de cincuenta empleados. Lo primero a considerar es la tecnología. Para trabajar en Big Tech tenés que estar al corriente con tecnologías modernas y populares. La mayoría de las tecnologías en empresas grandes se eligen para conseguir talento, no para encontrar una solución óptima. Si estás en web, tenés que usar React. Si estás en backend, tenés que saber Python o GoLang. Si estás en DevOps, tenés que saber Kubernetes y AWS. Las empresas que eligen stacks poco populares sufren enormemente en su capacidad de crecer personal. Una vez adentro, una gran parte del stack de tecnología son herramientas internas. Es inevitable que se creen abstracciones que resuelvan problemas específicos de la empresa, construidas sobre tecnologías populares y open source. Como los programadores somos nerds y vanidosos, todo lo que construimos tiene nombres artísticos e indescifrables. Yo mismo en Scribd creé un set de herramientas llamadas Marla, Durden y Tyler, por mi fanatismo de Fight Club. En empresas grandes, encontrás proyectos llamados Galactus, Teddy Bear, Dark Water y no se entiende nada. Además, ninguna herramienta tiene calidad open source ni está bien documentada. La hizo Jorge hace seis meses, pero se cambió de equipo. Las empresas grandes presentan oportunidades de desarrollo únicas. Escalar un producto técnico, sea en cantidad de usuarios, velocidad o infraestructura. Te puede tocar hacer un nuevo sistema de infraestructura cada seis meses. En una startup chica, lo que tenés es lo que tenés por años. Otra sorpresa técnica en empresas grandes es el nivel de costo de la infraestructura y operaciones. Se gastan montos astronómicos en correr servidores, sistemas intermedios, monitoreo o soporte empresarial. En Robinhood una vez me dijeron que había más de 500 proveedores de servicios de tecnología. Es famoso el caso de una persona que estafó a Google y a Meta con una estrategia muy sencilla: mandaba facturas como si fuese un proveedor y las empresas le pagaban sin chistar. El servicio no existía y llegó a cobrar decenas de millones de dólares antes de ser descubierto. La realidad es que se manejan los fondos con un cierto grado de irresponsabilidad, que una startup chica no podría permitirse jamás, y requiere mucha madurez organizacional mantener el costo a raya. Otro tema absolutamente propio de empresas grandes es la especialización. Yo siempre fui un generalista, algo de backend, infraestructura, frontend, pero en empresas grandes no existe nadie que haga todos los roles; casi todos son hiperespecializados. Esto es importante porque implica que hay un recambio de personal a medida que la empresa crece. Los generalistas van siendo desplazados por especialistas. Hay un sinfín de detalles técnicos sobre cómo se organizan las empresas grandes, y quiero enfocarme en la organización humana. Es realmente muy difícil en una industria tan abstracta lograr que los programadores siempre tengan algo para hacer, estén motivados, y que el trabajo sea de calidad y valioso para la empresa. Por eso se invierte mucho a nivel de organización para dar mucho soporte y acompañamiento a los programadores. Trabajar en tecnología tiene mucho conocimiento blando. Uno entra a la empresa y tiene que entender cómo funciona el producto, las prácticas de trabajo y de negocio, las peculiaridades del mercado. Las big tech tienen un proceso de bootcamp de semanas, con presentaciones, conferencias, ejercicios interactivos y más. Luego del bootcamp, uno ya empieza a contribuir en algún equipo. Los equipos son entre dos y ocho programadores y un manager. Tienen su propio charter, una página de documentación que aclara cuáles son los objetivos y metas del equipo, que delinea las responsabilidades, los miembros y los procesos con los que se maneja. Con la escala de una empresa, se vuelve muy importante la documentación y la interfaz de un equipo con otro, porque hacer cualquier cosa puede tocar un sinfín de áreas. En una startup de veinte programadores, los equipos son muy obvios, están delineados casi exclusivamente por su naturaleza técnica. A medida que crecen los equipos, se requieren más personas de producto, operación y legal, y cómo interactuar entre estos equipos se vuelve una tarea más sutil y más compleja. Los managers de equipos generalmente no programan. Se pasan una parte del tiempo pensando en lo que hay que hacer, cómo llegar a los objetivos del equipo, articularlos en la organización, escribirlos y repetirlos incesantemente con los programadores. Ojo, todos los managers son programadores. Para ser manager hay que ser un técnico sobresaliente. En este sentido, los equipos son como mini startups, tienen un desafío asignado, pero ¿qué hacer? ¿Cómo hacerlo? Lograr los objetivos tiene flexibilidad y es responsabilidad máxima de la persona de producto primero y luego del manager del equipo. El proceso de planeamiento más común es el OKR, objectives and key results. El OKR planning se inventó en Intel hace décadas y la industria lo adoptó religiosamente. El proceso requiere definir objetivos abstractos, la dirección en la que uno quiere ir, como crecer en más mercados o ser ocasionalmente eficientes, y luego metas con las que se evalúa concretamente el éxito o fracaso, como conseguir mil usuarios o gastar menos de determinada cantidad de plata. En el planning de OKRs, los distintos equipos trabajan internamente en lo que les parece importante, y juntan consenso de producto y liderazgo para evaluar prioridades, mientras se negocia con otros equipos para esfuerzos que sean multifuncionales. El proceso dura pocas semanas y lo manejan los líderes técnicos junto con los de producto. Los OKR además se utilizan para la evaluación de personal o el liderazgo, a veces se usan para decidir dar bonos que pueden llegar hasta el 20% de un salario anual. En las empresas grandes reina el famoso performance review, un proceso semestral donde se evalúa el desempeño de los programadores, con feedback de los pares, los managers, los objetivos cumplidos y más. En las perf review, uno se saca una nota entre uno y cinco, y para escalar en los distintos niveles de la empresa hay que demostrar consistentemente tres o cuatro para arriba. Sacarse un dos o menos implica que estás en problemas. Dos semestres seguidos con esta nota y te van a despedir. Las notas más altas de los perf review están vinculadas al impacto evaluado en la empresa y son notas relativas. Las contribuciones se miden en una distribución y solo el top recibe las notas más altas. La nota máxima la recibe menos del 5% del staff. Performance review es para mí un proceso lógico y perverso. Es lógico porque las empresas quieren proveer procesos repetibles y mensurables en la organización. Perverso porque cualquier métrica se puede truchar. El progreso se mide más por lo que puedas poner en la perf review sobre lo que puedas hacer en un producto. Esto genera incentivos para la creación de nuevos proyectos, con nuevos nombres e ideas modernas y marketineras, pero que no son necesariamente mejores y no van a ser bien mantenidos, sino reemplazados por futuros proyectos también a medio hacer. La pelea para quedar bien para las perf review es uno de los primeros pilares de lo llamado coloquialmente office politics. Por ejemplo, existe el cookie licking, en referencia a pasarle la lengua a las galletitas para que nadie más las coma. Cuando en planning aparecen proyectos que parecen buenos para las performance review, los managers se pelean para tenerlos asignados, aun cuando no los pueden hacer y los van a retrasar. Hay peleas mezquinas por los buenos proyectos y tener atribuidos éxitos a tu nombre. Es mucho más fácil tener éxito por tener un proyecto asignado fácil con un impacto fácil de mostrar, que por un proyecto difícil con un impacto más abstracto. Además, como manager, vos tenés que abogar por tus programadores y tu equipo, que no siempre queda alineado con la empresa. El interés de los managers es conseguir más recursos para hacer más proyectos y crecer una organización, por lo que siempre están abogando por crecer el equipo. Los managers no pierden plata por sobrecontratar, pero sí pierden oportunidades subcontratando, un problema clásico de incentivos. Las escalas para conseguir promociones suelen estar bien documentadas. Se crea el concepto de bandas para simplificar la clasificación del personal y la remuneración. En Big Tech, la nivelación se compara entre las empresas. Un L5 de Google es un E6 de Meta. A grandes rasgos, la escala empieza con pasantes, sigue con recién graduados, early career, senior, staff y principal. Cada banda suele cobrar un 50% más que la anterior y el stock va subiendo como parte de la remuneración total. El manager novato equivale a un senior engineer, y el manager más propiamente dicho equivale a un staff engineer en términos de remuneración. Para ser promovido dentro de la empresa, el manager tiene que hacer un promo package. Esto es importante para trabajar en la narrativa personal. Vos querés que en esa reunión sea obvio para todos los participantes que la nueva banda te corresponde, que sería un sacrilegio que no te lo den. Y para eso tienen que saber tu nombre y qué hiciste antes de leer el promo package. Las promociones y la necesidad de usar las comunicaciones internas es otro pilar del office politics. Es muy común la mezquina pelea por visibilidad, las ganas de tener tu nombre pegado a cualquier cosa que pueda llegar a llamarle la atención al liderazgo, independientemente del valor de tu contribución. En esta situación, se considera una grave traición no reconocer a gente que haya contribuido en tu proyecto en cualquier mensaje celebratorio que pueda ser leído por los grandes jerarcas. En comparación con las startups más chicas, las empresas de este tamaño expresan una cultura muy fuerte. En las startups se considera que la cultura de la empresa es el activo más valioso que puede crear el equipo ejecutivo. Es más, Sam Altman, el expresidente de Y Combinator, le da la recomendación a las startups que contraten más por los valores que por la capacidad técnica. Los trabajadores remotos tienen mucha dificultad en entender la cultura americana, y a veces pasan arduos procesos de selección técnica para fallar en las entrevistas de valores y cultura. Hay que estudiar a las empresas específicamente para saber qué historias quieren escuchar y si es un lugar donde te sentirías cómodo trabajando. Las startups tienen algunos valores que comparten entre todas, como enfocarse en el bienestar del consumidor, armar ambientes de trabajo saludables y responsabilidad individual. En el episodio diez de “Cultura de Trabajo”, hablo más sobre ese tema. Sin embargo, es imposible abordar la cultura en empresas grandes sin hablar de política. Silicon Valley es de izquierda. En la división de partidos políticos en Estados Unidos, los demócratas están a la izquierda y los republicanos a la derecha. En una encuesta sobre donaciones a partidos políticos, empresas como Twitter, Netflix o Meta tenían más del 95% de las donaciones al partido demócrata. Esto viene con muchas consecuencias en el día a día. El ambiente es altamente hostil a expresiones no conformistas o de derecha, y varios casos individuales llegaron a los medios. Peter Thiel, por abogar por Trump en las elecciones, fue presionado para ser despedido de Y Combinator. Palmer Luckey, el creador de Oculus, fue despedido por donar indirectamente a la campaña de Trump. James Damore, despedido de Google por presentar una idea controversial sobre prácticas de reclutamiento en la empresa. La expresión más cotidiana de esto viene en las all hands, una reunión periódica donde toda la empresa participa y se hacen anuncios, presentaciones y un espacio de preguntas para que la gente pueda preguntar directamente al CEO cosas incómodas y difíciles. Este proceso está totalmente copado por preguntas sobre la empresa como una plataforma de sus ideas políticas personales. La empresa como una plataforma de sus ideas políticas personales se volvió tan problemático que Brian Armstrong, el fundador de Coinbase, decidió prohibir comunicaciones políticas en los canales públicos de Slack, y le ofreció una indemnización a toda la gente que no estaba de acuerdo con la idea. El 5% del staff renunció. Por ahí el resabio más particular de todo este proceso es lo popular que se volvió el concepto de diversity and inclusion. En parte, se basan en un estudio que decía que la diversidad de puntos de vista daba mejores resultados en los procesos creativos que los monobloques de pensamiento. En este proceso, las empresas agregan prácticas y procesos que aseguren que haya diversidad sexual y racial en el staff. Como toda métrica que se puede truchar, diversity es un codeword para la alineación política más que la auténtica variedad de opiniones y puntos de vista en un ambiente rico de variedad de ideas. Los extranjeros estamos un poco favorecidos, ya que contamos como diversity hires dentro de la cultura de trabajo americana. Trabajar en empresas grandes es muy distinto a trabajar en pequeñas startups. Por un lado, hay recursos aparentemente infinitos y desafíos técnicos y de producto innovadores y constantes. Por otro lado, viene con una alta burocratización y desafíos de organización humana que trascienden las responsabilidades profesionales y crean ambientes de trabajo que requieren más adaptación. Si les gustó el podcast de hoy, se vienen muchos más. Suscribite al podcast en Spotify o seguime en Twitter, en @Conanbatt, para estar al tanto de todo el contenido. Hasta la próxima.