- Tras trabajar durante 4 años como desarrollador de software en Google y renunciar el 1 de febrero, el trasfondo fue una experiencia de pérdida de control sobre su carrera debido a la estructura de evaluación de ascensos y a la cancelación repetida de proyectos
- Los ascensos no los decidía el gerente directo, sino un comité de ingenieros y gerentes de mayor nivel que no conocían al candidato y revisaban un promo packet
- Mejorar pipelines heredados, corregir bugs, hacer pruebas, documentar y apoyar al equipo era útil en la práctica, pero era difícil dejarlo como impacto medible, lo que jugó en su contra en la primera evaluación de ascenso
- Después, al elegir solo trabajos que ayudaran al ascenso, recibió Superb, la calificación de desempeño más alta, pero volvió a fracasar en el ascenso por cancelaciones de proyectos y reasignaciones de equipo repetidas
- A través de Indie Hackers descubrió la alternativa de un pequeño negocio de software rentable, y decidió probar durante varios meses KetoHub, un negocio basado en Sia y la monetización de la escritura
Los primeros 2 años en Google y la expectativa de ascenso
- Sus primeros 2 años tras entrar fueron tan satisfactorios que pensaba quedarse mucho tiempo en la empresa
- A su alrededor había ingenieros excelentes, y también contaba con herramientas de desarrollo avanzadas y comida gratis
- Su evaluación de desempeño más reciente había sido Strongly Exceeds Expectations, y su gerente le dijo que estaba cerca del siguiente paso: ascender a Senior Software Engineer
- El gerente consideraba que ya tenía capacidad de trabajo de nivel senior, pero dijo que necesitaba un proyecto adecuado para demostrarlo ante el comité de ascensos
Cómo funcionaba el proceso de ascensos en Google
- En Google, el gerente directo no puede ascender directamente a sus subordinados ni tiene derecho a voto
- La decisión de ascenso la toma un pequeño comité formado por ingenieros de software y gerentes de niveles superiores que conocen al candidato por primera vez ese mismo día
- El postulante crea y presenta un promo packet
- Cartas de recomendación de compañeros de equipo
- Documentos de diseño escritos por el candidato
- Un texto breve que explica por qué su trabajo amerita un ascenso
- El comité revisa juntos los paquetes de varios candidatos y decide durante el día si ascienden o no
- Al principio, veía este método como una forma de reducir sesgos y política interna, y de evaluar de manera justa la calidad del código y el criterio de ingeniería
Por qué la mejora de un pipeline heredado no quedó reflejada en la evaluación
- Su principal responsabilidad era un viejo pipeline de datos heredado
- Llevaba años en modo mantenimiento, pero estaba bajo presión por el aumento de carga
- Era frecuente que muriera silenciosamente o produjera salidas incorrectas
- Después del documento de diseño inicial no había documentación, por lo que diagnosticar incidentes tomaba días
- Para normalizar el pipeline realizó varias mejoras
- Corrigió decenas de bugs
- Escribió pruebas automatizadas para evitar que los bugs se repitieran
- Eliminó miles de líneas de código muerto y de código reemplazable por bibliotecas modernas
- Documentó lo aprendido para que el conocimiento no quedara solo en la cabeza de una persona
- En la evaluación de ascenso, este trabajo volvió como un problema no cuantificable
- Al descubrir bugs, parecía que el número total de bugs más bien había aumentado
- Al cambiar el sistema para que fallara rápido en vez de pasar por alto anomalías silenciosamente, también aumentaron las métricas de incidentes
- El tiempo que los desarrolladores tardaban en reparar incidentes se redujo mucho, pero no había una métrica que lo rastreara
- También postergó su propio proyecto durante semanas o meses para reducir el riesgo de lanzamiento de compañeros de equipo
- Era la decisión correcta para el equipo, pero no se veía impresionante en el promo packet
- Para el comité, los proyectos de sus compañeros parecían trabajos importantes que requerían más coordinación, mientras que su propio trabajo parecía algo fácil de interrumpir
- El resultado de la primera evaluación de ascenso fue que faltaban pruebas de que pudiera manejar complejidad técnica y de su impacto en Google
Cómo cambió su forma de trabajar tras el rechazo
- Después del primer rechazo, pensó que bastaba con seguir haciendo el mismo buen trabajo, pero registrarlo mejor
- Aunque el equipo recibía muchas alertas por correo que eran falsos positivos, no las corrigió de inmediato; primero intentó crear una métrica de frecuencia de alertas para dejar un historial
- Porque en el momento del ascenso podría mostrar una gráfica con la reducción de alertas
- El proyecto asignado después parecía favorable para el ascenso
- Dependía en gran medida del machine learning, un área importante para Google
- Automatizaba tareas que cientos de trabajadores hacían manualmente
- Tenía que liderar a un desarrollador junior, algo que en general suma puntos en las evaluaciones de ascenso
El incidente del regalo de fin de año y la percepción de una “relación de negocios”
- Google puso fin a una larga tradición de regalos de fin de año lujosos y apareció en los titulares por usar el presupuesto de regalos para comprar Chromebooks para estudiantes de bajos ingresos
- En una conversación entre empleados sobre ese tema, un empleado dijo que la relación entre Google y sus empleados era una relación de negocios
- Esa conversación lo llevó a darse cuenta de que Google y él no eran tanto una sola comunidad, sino una relación en la que él recibía dinero a cambio de prestar servicios
- Si el comité de ascensos no recompensaba la corrección de bugs ni el apoyo al equipo, también empezó a reconsiderar por qué dedicaba tiempo a esas tareas
Optimización para el ascenso y cambio en los estándares de calidad
- La lección que sacó del primer rechazo de ascenso después le pareció equivocada
- En vez de empaquetar mejor el mismo trabajo, cambió hacia elegir exclusivamente el trabajo que el comité de ascensos quería
- La nueva estrategia era preguntarse antes de empezar cualquier tarea si ayudaba al ascenso y, si no ayudaba, no hacerla
- También bajaron sus estándares de calidad de código
- Pasó de “¿se podrá mantener durante los próximos 5 años?” a “¿aguantará hasta que me asciendan?”
- No registraba ni corregía bugs que no amenazaran el lanzamiento del proyecto
- Se apartó de las responsabilidades de mantenimiento
- Dejó de participar como voluntario en eventos de reclutamiento en campus
- Redujo de 1 o 2 entrevistas por semana a 0
Cancelaciones repetidas de proyectos y pérdida de control sobre su carrera
- Cuando cambiaron las prioridades, el proyecto que parecía favorable para el ascenso pasó a un equipo hermano en India
- El proyecto que recibió en su lugar no estaba documentado y estaba sobre infraestructura sin soporte, pero era un componente importante en producción
- El nuevo trabajo consistía en separar ese sistema del código del equipo hermano y migrarlo a un nuevo framework, manteniendo al mismo tiempo la operación en producción y las métricas de rendimiento
- Desde el punto de vista del ascenso, era un retroceso de varios meses
- El proyecto cancelado nunca se lanzó, por lo que dos meses de trabajo quedaron sin sentido
- Entender el nuevo sistema requería varias semanas
- Mantener la operación podía sumar tiempo adicional de trabajo repetitivo
- En 6 meses fue la tercera reasignación a mitad de proyecto que experimentó, y cada vez la razón no fue la calidad del trabajo, sino la estrategia de la alta dirección o cambios de personal en los equipos
- Google decía que no podía juzgar el trabajo antes de que un proyecto estuviera terminado, pero al mismo tiempo cortaba proyectos a mitad de camino y asignaba trabajo nuevo, dificultando terminarlos
- Su carrera quedó en una estructura determinada por un comité anónimo que lo revisaba durante más o menos una hora y por decisiones gerenciales en las que él no participaba
Último intento de ascenso y decisión de renunciar
- Como había invertido 3 años en lograr un ascenso en Google, decidió postularse una vez más antes de renunciar
- 6 semanas antes de que terminara el periodo de desempeño, el proyecto volvió a cancelarse, y esta vez se canceló todo el equipo
- En Google esto era lo bastante común como para tener el eufemismo defrag
- El proyecto del equipo se trasladó al equipo hermano en India
- Los miembros del equipo tuvieron que volver a empezar en otras áreas de la empresa
- Aun así, solicitó el ascenso, y el resultado fue Superb, la calificación de desempeño más alta
- Esta calificación se otorga a cerca del 5% de los empleados en cada ciclo
- El comité de ascensos consideró que durante los últimos 6 meses había mostrado claramente trabajo de nivel senior
- Esos 6 meses fueron el periodo en el que trabajó optimizando para el ascenso
- Sin embargo, no lo ascendieron porque 6 meses no eran un historial de desempeño suficientemente largo
- Su gerente le dijo que, si hacía trabajo del mismo nivel durante 6 meses más, tenía muchas probabilidades de ascender, pero como ya llevaba 2 años escuchando que “en 6 meses” podría ascender, decidió irse
Indie Hackers y el plan de desarrollo independiente
- Por una época similar descubrió Indie Hackers
- Indie Hackers era una comunidad en línea de fundadores de pequeños negocios de software
- Más que personas que soñaban con una startup enorme, se centraba en quienes querían crear negocios pequeños y rentables que pudieran cubrir su costo de vida
- Antes pensaba que, para convertirse en fundador de software, había que seguir la ruta de las startups al estilo Silicon Valley
- Lo entendía como dedicar la mayor parte del tiempo a levantar inversión y preocuparse por conseguir el siguiente millón de usuarios
- El enfoque de Indie Hackers era una alternativa distinta
- Muchos miembros empezaban negocios con sus ahorros o como proyectos paralelos junto a su empleo principal
- No tenían que responder ante inversionistas
- Tampoco tenían que demostrarse ante comités anónimos
- Las desventajas también eran claras
- Los ingresos eran menos estables
- Había más riesgos fatales
- Si en Google cometía un error que causara pérdidas de 10 millones de dólares, podía escribir un postmortem y se tomaría como una oportunidad de aprendizaje; para un pequeño fundador, podía significar el cierre del negocio y una gran deuda
- Aun así, los fundadores de Indie Hackers le resultaban atractivos porque tomaban sus propias decisiones, tanto si su negocio crecía rápidamente como si permanecía estancado durante años
- Después de renunciar, planeaba probar varios proyectos durante unos meses cada uno para ver la reacción
- Seguir desarrollando KetoHub para comprobar su potencial de monetización
- Crear un negocio sobre Sia, una tecnología de almacenamiento distribuido
- Dedicar más tiempo a escribir y buscar formas de monetizarlo
- Google fue un buen lugar de trabajo y un sitio donde aprendió habilidades valiosas, pero concluyó que empleadores como Google seguirían existiendo, mientras que la libertad de iniciar su propia empresa no siempre estaría disponible
1 comentarios
Opiniones de Hacker News
El mismo autor también ha publicado una interesante serie de retrospectivas anuales donde resume el proceso de intentar levantar varios negocios de software, y aborda su situación financiera con bastante franqueza.
Si te interesa hacer crecer un negocio de software con bootstrap, vale mucho la pena leerla:
https://mtlynch.io/tags/annual-review/
https://mtlynch.io/i-sold-tinypilot/
Las historias de éxito se escuchan a menudo y, cuando uno tiene éxito, es fácil hablar de ello en grande, pero hay que recordar que la realidad es que la mayoría de las empresas fracasan. Este autor encontró algo que generaba dinero en el tercer año, pero la mayoría no tiene el margen para aguantar tanto tiempo sin ingresos.
Es raro encontrar a alguien que escriba de una forma tan honesta y fácil de empatizar. Lo sigo desde hace años y es una excelente fuente de inspiración.
En cualquier carrera, la lección más importante es que “el cliente no es el cliente”. Los clientes reales son las personas que determinan aumentos de sueldo, bonos y ascensos.
Un cliente es quien paga por un producto o servicio que considera valioso, y normalmente es tu gerente o, como en el caso del texto original, un comité de promoción. Desde esa perspectiva, tiene sentido manejar la carrera como un negocio y moverse para entregar valor más rápido a quienes pueden intercambiar dinero por valor. Que el cliente cambie de opinión, que el mercado cambie sus criterios o que uno se dé cuenta de que estaba enfocándose en lo equivocado también es común en los negocios. Si no le das al cliente lo que quiere, puede irse fácilmente con otra persona, así que hay que seguir ajustando la estrategia y adaptarse al cliente.
Al final, el verdadero cliente ni siquiera es una persona, sino un proceso. Perseguir con pasión ideas excelentes que ayuden a la gente es el mejor punto tanto para la carrera como para la sociedad. La parte del texto original que dice: “Es natural que mi destino esté en manos de un comité misterioso que nunca me ha conocido. Ellos no estarán contaminados por favoritismos ni política, y reconocerán mi código de alta calidad y mis decisiones de ingeniería acertadas”, lo muestra muy bien.
Este patrón lleva a una baja en la calidad del producto y a peores dinámicas de equipo. Es mejor buscar empresas que repriman explícitamente esta deriva inevitable, o donde todavía no haya surgido. Todos se sienten mejor cuando se produce buena calidad y se la reconoce.
Cuando te encargan construir algo, lo que quiere el comprador y lo que realmente necesita pueden ser cosas distintas, y aun llegando hasta el final puede quedar insatisfecho. Si trabajas para un jefe, el jefe también puede convertirse en un obstáculo. No basta con hacer lo que el cliente quiere; el jefe puede decir “hazlo a mi manera”, y eso puede impedir que el cliente reciba lo que quería. Incluso cuando el cliente compra algo para otra persona, esa intermediación puede causar fallas, algo que ocurre a menudo en software empresarial a medida.
Es difícil estar totalmente de acuerdo con este texto. Que un proyecto se caiga antes de completarse es muy frustrante, pero también parece que el autor estaba ahí solo por el ascenso.
Los ascensos están bien, pero no queda suficientemente explicado por qué eso era tan decisivo como para irse. Si la única razón para quedarse en un trabajo es la expectativa de un mejor título, puede ser una mala señal. Después de eso, en 4 años en Google ganó suficiente dinero para toda la vida, y con esa estabilidad financiera tomó una decisión de alto riesgo que la mayoría no podría asumir. En cualquier caso, me alegra que haya encontrado algo que le queda bien, y espero que pueda usar esa estabilidad para crear algo útil e influyente.
Todos estos elementos antes eran muy públicos, y había montones de presentaciones, diapositivas, documentos, etc. Importaba en qué nivel estabas y en qué nivel estaba la persona con la que hablabas. El objetivo no era ser un buen ingeniero ni crear un buen producto, sino hacer únicamente el trabajo que lograra que un comité anónimo subiera ese número mágico. Aunque no hubieras entrado a Google por esa razón, terminabas aprendiendo qué se exigía. Lamentablemente, una generación de ingenieros de software aprendió esa lección.
La presión por generar impacto o mejorar métricas dudosas no termina nunca, y mientras tanto la deuda técnica se acumula. También siempre está la incertidumbre de las reorganizaciones y los despidos, y hay mucha ansiedad por el siguiente ciclo de evaluación. Después de unos años, parece que el dinero es la principal motivación. Eso sí, no quiero ascender porque no quiero más estrés, y como sería muy difícil ganar más en otro lugar, quiero quedarme en esta empresa todo el tiempo que pueda.
La psicología humana no funciona así. Terminas compitiendo con la gente a tu alrededor, y es difícil ser feliz si solo tú te quedas atrás mientras ellos ascienden.
Quedarse mucho tiempo en niveles por debajo de staff podía jugar en contra, y si no ascendías, podían ponerte en un plan de mejora de desempeño con el argumento de que no estabas cumpliendo las expectativas declaradas. Google terminó eliminando esa frase, porque aprendió que en una empresa de 100 mil personas no hay suficientes lugares en la pirámide, y que terminarías perdiendo a la gente que no se autopromociona pero mantiene el sistema funcionando. Si no recuerdo mal, en 2018 todavía no lo sabían.
Soy el autor. Me alegra que este texto haya vuelto a aparecer.
Si tienen preguntas sobre él, puedo responderlas.
Suena como si hubieras observado la corriente y elegido el cauce que parecía mejor, pero a menudo también hay otras opciones. Construir una represa, es decir, cambiar el terreno. Cambiar el negocio de una forma que nadie había querido o podido intentar. Viendo hacia atrás, fui más feliz y tuve más éxito cuando podía decirle a mi jefe qué iba a hacer, en vez de esperar a que mi jefe me asignara algo interesante e influyente. Si no ves esa opción, puede ser momento de irte, pero a menudo valía la pena intentarlo primero. A veces tuve que empujar trabajo sucio para ganarme el derecho a crear mi propio destino, pero cuando existían una estructura de gestión y confianza, podía usar ese capital para proponer algo grande, nuevo e interesante. Me sorprende cada vez que veo que la audacia es recompensada. La semana pasada, un colega le sacó sangre a la piedra del financiamiento con una propuesta ambiciosa y polémica, y esta semana se convirtió en líder técnico de un equipo nuevo. Cada vez que me siento bloqueado, abro un documento en blanco y empiezo a escribir un nuevo diseño. En ese momento no pienso en ascensos, pero al final eso terminó llevando a algún ascenso o a una oportunidad más grande.
Me da curiosidad si estás trabajando en un nuevo proyecto. Vi el texto sobre fuzzing de parsers de PDF, pero no vi el contexto de si estaba relacionado con un proyecto nuevo, o quizá se me pasó.
https://mtlynch.io/i-sold-tinypilot/
Gracias por escribir en público y documentar tu recorrido; seguro que no soy la única persona a la que ayudaste. Además, cada vez que veo tu nombre de usuario siempre lo leo como Mount Lynch.
La conclusión que saco de este texto es lo despiadada que puede ser una estructura que depende de un comité de ascensos.
Entiendo que Google haya implementado ese sistema porque quería crear una cultura centrada en la ingeniería. La intención probablemente era que, aunque tu gerente no te reconociera, si hacías un excelente trabajo de ingeniería, igual fueras reconocido. Pero mientras más difícil de cuantificar es el trabajo, como mejorar la cultura, menos suena a que un comité así pueda reconocer correctamente la buena ingeniería. La vida mejora cuando encuentras a alguien —un cliente o un líder— que reconoce el valor que aportas y puede mostrar ese reconocimiento en una decisión de ascenso. Un comité sin rostro que depende de paquetes no puede, por diseño, crear la relación donde surja un reconocimiento genuino. Si el liderazgo de una empresa no me reconoce, ¿por qué forzarme a quedarme? Mejor encontrar un lugar que sí lo haga. Si Google no aprende que no puede evitar perder buen talento por mala gestión o malos procesos, es su pérdida. Puedes aprovechar evaluaciones de desempeño razonablemente buenas y planear lentamente tu salida. La vida es demasiado corta para trabajar en una organización que bloquea activamente la formación de relaciones profesionales auténticas y de apoyo.
Para mucha gente, un ascenso se parece a ganar un concurso de comer pasteles donde el premio es más pastel. Está bien reconocer que tus intereses y los de tu empleador solo están alineados de forma laxa, y también está bien negarte a jugar el juego de la manera en que la empresa quiere.
Basta de ascensos: quiero hacer un trabajo que me dé motivación intrínseca, es decir, algo significativo, inspirador y en lo que pueda concentrarme, y ganar solo lo suficiente para mantenerme y ahorrar una cantidad razonable.
El problema son tres cosas. Muchas empresas pagan tan mal que necesitas ascender para poder ahorrar algo; el trabajo significativo en sí mismo es como un unicornio; y lo más irritante es que, en las empresas estadounidenses, incluso los trabajadores que desempeñan su rol de forma estable y consistentemente buena inevitablemente son presionados para “crecer” y “desarrollar su carrera”, o se les llama “rezagados”. Tener un desempeño consistentemente sobresaliente en cierto nivel no tiene por qué ser estancamiento; puede ser estabilidad deliberada. El crecimiento infinito en el contexto personal, o al menos la agitación infinita, es una locura difícil de entender de las empresas estadounidenses.
Me llamó la atención la frase del autor: “Para seguir desarrollando mi carrera, necesitaba proyectos de mayor alcance y colaborar con más equipos socios. Pero eso significaba que los proyectos podían fracasar por muchos más factores fuera de mi control, y que meses o años de mi vida podían desperdiciarse”.
Si uno mira hacia atrás y reflexiona, probablemente termine reconociendo que el éxito de una startup también depende de más de 100 factores fuera de tu control. No es una pérdida de tiempo de vida. Es aprender cómo funciona el mundo.
En una startup de alto crecimiento financiada con capital de riesgo, para tener éxito quizá necesites que muchas estrellas se alineen. Pero en un negocio bootstrap, básicamente solo necesitas una cosa para triunfar: encaje producto-mercado. Si construyes un producto que la gente quiere, aunque cometas muchos otros errores, en general es bastante probable que tengas éxito. Cuando empecé TinyPilot no sabía nada de hardware ni de vender productos físicos, y cometí muchísimos errores. Pero encontré un producto por el que la gente estaba dispuesta a pagar, y encontré una buena forma de ponerlo frente a los clientes, así que la empresa funcionó. También hice cosas bien, pero durante el primer año, en general, sentía que los ingresos crecían solos y yo intentaba alcanzarlos. Para encontrar el encaje producto-mercado todavía necesitas suerte, porque muchas ideas que parecen plausibles fracasan. Aun así, no estás esperando que muchas cosas salgan bien al mismo tiempo: solo necesitas tener suerte una vez.
Otro infame artículo de 2018 del tipo “por qué dejé Google”.
Y esos artículos siempre empiezan diciendo que los ingenieros de Google son los más inteligentes del mundo. Están realmente adoctrinados.
Yo también estoy pensando en irme de Google por eso. Estoy sentado en reuniones, tratando de pasarle a otros el trabajo necesario, y casi no me interesa jugar ese juego, mientras que en mi proyecto tengo cientos de tareas pequeñas que debo terminar yo.
Si cambio de trabajo, podría ganar 50 mil a 100 mil dólares más al año. La siguiente empresa realmente valoraría mi experiencia, aunque técnicamente esa experiencia le sería mucho más útil a Google.
Ahora trabajo más rápido y con más eficacia, y gano más dinero, en una empresa pequeña enfocada en un proyecto concreto, en lugar de una empresa de 100 mil personas que hace de todo.
La estructura era: “¿El gerente no te asciende?” “No. Los gerentes de Google no pueden ascender a sus reportes directos. Ni siquiera tienen voto. En cambio, las decisiones de ascenso las toma un pequeño comité de ingenieros de software y gerentes de nivel superior que te conocen por primera vez ese día”.
Según tengo entendido, después de 2022 parece que cambió a un sistema en el que el gerente tiene el único voto.
El ascenso todavía pasa por un comité de ascensos. Solo que ahora intentan ubicar el comité lo suficientemente cerca de la organización como para que haya oído hablar del candidato, y poner en la reunión revisores con mucho contexto que no sean el gerente. Algo que viene del sistema anterior, y que este tipo de textos a veces pasa por alto, es que para cada nivel hay expectativas explícitas sobre las actividades que se confía que una persona de ese nivel pueda realizar de forma independiente. Una decisión de ascenso no es una recompensa por haber hecho bien el trabajo actual, sino una decisión sobre si demostraste lo suficiente que puedes hacer el trabajo del siguiente nivel. Si alguien se queda mucho tiempo en un nivel, normalmente es porque no mostró señales del siguiente nivel. Por supuesto, puede sentirse injusto si es un equipo con pocas oportunidades para mostrar esas señales, o si el impacto de algunos proyectos tarda años en evaluarse y el trabajo no se reconoce hasta que se evalúa el impacto operativo. Aun así, muchas veces no es tan caprichoso como suena.
Como cambia cada año, no juzgaría Google en 2024 por mi experiencia personal, pero en uno de los años en que estuve ahí, mi gerente casi ni sabía dónde estaba mi asiento. Mis paquetes de ascenso a L5 y L6 los evaluó un comité de pares, y ni siquiera sé si vieron la evaluación de mi gerente. Cuando participé en un comité de ascenso a L5, tampoco le dimos mucho peso a la evaluación del gerente. En ese momento tenía sentido, porque los gerentes estaban muy alejados de las áreas que justificaban un ascenso a L5.
Pero eso no es un misterio: al final, la responsabilidad de armar un paquete sólido que deje claro por qué el candidato debe ascender recae en el gerente. El intento de ascenso en sí mismo es el voto del gerente, y después depende de qué tan fuerte impulse el ascenso del candidato. Creo que es la única forma de garantizar consistencia entre ascensos.