El verdadero significado de "terminar" un trabajo en una empresa big tech

• En big tech, terminar de verdad un trabajo significa llevarlo hasta un estado que satisfaga a la empresa y seguir adelante, dentro de un sistema que puede mejorarse infinitamente
• Un ingeniero capaz pero con poca iniciativa sigue repitiendo pequeñas mejoras y termina perdiendo los resultados realmente importantes
• Para que se reconozca que sí hiciste el trabajo, debes entregar resultados claros y visibles para quienes toman decisiones
• Siempre hay que revisar si lo que haces está en una forma que la alta gerencia pueda leer y evaluar
• No es posible dejar todo perfectamente ordenado; llegado cierto punto, la capacidad de "declarar la victoria e irse" se vuelve una habilidad clave

---

El "trabajo" tiene una naturaleza que no puede completarse del todo

• A diferencia de un problema de matemáticas o una tarea, el trabajo en el mundo real es un sistema abierto que puede mejorarse infinitamente
• Desarrollar un servicio es como plantar un árbol: después también requiere un proceso de mantenimiento continuo

El ingeniero capaz que cayó en la trampa

• Un ingeniero que carga con todo por su cuenta y solo repite mejoras pequeñas y continuas puede sentir que sí está logrando cosas, pero
• desde la perspectiva de la alta gerencia, se juzga que no hay una "creación de valor visible para la empresa"
• Como resultado, puede ser malinterpretado como una persona ocupada pero sin resultados

El significado real de "terminar" algo

• Llevarlo hasta el punto en que la empresa (quienes toman decisiones) quede satisfecha y pasar a lo siguiente
• En lugar de seguir refactorizando o repitiendo mejoras menores, hay que crear una lista clara de resultados
• Es importante tener la determinación de declarar "ya está terminado" y pasar al siguiente trabajo

Asegurar la "legibilidad" del trabajo

• Los proyectos que la gerencia ya conoce o pidió, y las respuestas a incidentes importantes, tienen alta legibilidad
• En general, la mayoría del trabajo técnico no es más que ruido técnico difícil de juzgar para la gerencia
• Por eso, hay que ajustarlo para que pueda leerse, por ejemplo volviendo visibles los resultados o destacando el impacto económico

"Terminar" es un concepto social

• Desde un punto de vista filosófico, la idea de "estar terminado" también es una construcción social, pero en la práctica tiene una fuerza muy real
• Si se ignora, puedes no ser evaluado correctamente y, en última instancia, incluso podrían despedirte

Resumen

• Trabajar no significa necesariamente haber terminado
• La mayoría de los trabajos no pueden terminarse y pueden continuar indefinidamente
• Hay que dejar de ser jardinero y convertirse en un táctico orientado a resultados
• El criterio de "terminado" es la satisfacción de la empresa o de la gerencia
• "Declarar la victoria → irse → pasar al siguiente trabajo" es la estrategia clave

[aer0700]

Parece que también es una habilidad importante elegir un trabajo con el que realmente se pueda declarar la victoria.

[elbanic]

A limitar el alcance se le llama scoping. La capacidad está en hacer bien el scoping para poder ganar.

[bakyeono]

Hanshin vs. Soha

[doolayer]

No son los detalles, sino resultados visibles y cuantificables

[GN⁺]

Opiniones de Hacker News

• No estoy totalmente en desacuerdo con lo que plantea este artículo, pero por mi experiencia trabajando en big tech, varias startups y unicornios, no me parece un consejo muy práctico. En los últimos 10 años, el trabajo de los desarrolladores se ha especializado tanto que quedó desconectado de quienes toman decisiones y de las necesidades del cliente. Esto pasa porque el Product Manager se mete entre los ingenieros y el resto de la empresa. Yo siempre quiero generar resultados valiosos, pero en la práctica hacerlo implica vivir con estrés constante. Mi aporte inevitablemente se ajusta al pasar por el ego de la persona que habla con quienes deciden. La única vez en los últimos 5 años que sentí un logro real fue cuando asumí temporalmente el rol de Product Manager durante 9 meses. En ese período, nuestro equipo completó con éxito tres proyectos en los que otros equipos ya habían fallado varias veces. El secreto fue hablar de verdad con los stakeholders para entender sus necesidades, no tratar de hacerlo a mi manera. Así que supongo que seguiré entregando solo lo que me pidan, me van a culpar por los bugs y no me van a reconocer por las funciones. Al menos pagan bien. Igual sigo buscando un lugar donde pueda aportar de verdad

  • Esa parte de “al menos pagan bien” se me quedó muy grabada. Tengo mi propia opinión de que estar “estancado” en big tech tampoco está tan mal. Por ejemplo, si trabajas en Google o MS ganando 300 mil dólares al año y te pasas 10 años en el mismo proyecto aburrido, esa experiencia igual será valorada en cualquier lado. Mi yo más ambicioso de antes habría estado inconforme con eso, pero alguien con ese perfil probablemente se iría a una empresa más chica. A medida que uno envejece, su foco cambia de la empresa a la familia y los amigos. Si alguien me dijera que nunca me van a ascender, yo respondería “¿y qué?”. Gano lo suficiente para mi familia y mantengo un buen equilibrio entre trabajo y vida. Si soy honesto, la mejor parte de trabajar en una empresa es el sueldo y cómo eso mejora el resto de tu vida
  • He visto que el rol de Product Manager, en la realidad, no se parece a cómo se describe idealmente: queda atrapado en medio y no representa bien a ninguna de las dos partes. Como resultado, terminé desarrollando por mi cuenta habilidades de gestión de producto, y esa habilidad de verdad sirve muchísimo para evitar trabajo inútil. Por eso me pregunto si, para ser un gran ingeniero, product management también debería ser una habilidad obligatoria
  • Otra cosa que hay que considerar es que, si sigues así, vas directo al burnout
  • Me di cuenta de que la comunicación es el mejor conjunto de habilidades en cualquier organización. Nueve meses en un puesto temporal no bastan para entender todo su valor. El texto se lee como si el autor, igual que otros ingenieros, estuviera demasiado frustrado y pensara que es más inteligente que el resto de la organización. Muchas veces no es así, y esa mentalidad perjudica la colaboración
  • Detrás de cualquier aplicación web que funciona bien siempre hay alguien que actúa como jardinero
  • Me pregunto por qué no siguió como Product Manager
  • Depende muchísimo de la empresa. Hay muchos lugares donde los ingenieros tienen mucha más influencia. Incluso en big tech existen casos donde no están separados del cliente
  • ¿Eso significa que hay que despedir a los Product Managers?
  • Yo hice justamente ese rol de Product Manager, mediando entre los ingenieros y la empresa, y sí, mi aporte también pasaba por el filtro de mi propio ego, así que suena a que te resultó bastante satisfactorio... debió haber sido un trabajo bastante gratificante

• Tengo una objeción de fondo a tomar como única medida del éxito el satisfacer a quienes tienen poder. Vivimos atados a jerarquías ridículas, sí, pero no creo que todo se reduzca a mover un ticket en Jira a “hecho” o eliminar warnings del compilador. Nadie dice “no me arrepiento de haber pasado 40 años satisfaciendo a mis jefes cada vez”

  • Llevo 30 de 40 años trabajando, y sí hubo valor real en satisfacer a mis jefes y a los jefes de mis jefes. Aunque una visión cínica no lo sea todo en la vida, conocer esa perspectiva cínica te acerca más a la verdad
  • De hecho, creo que “satisfacer a tus jefes y a los jefes de tus jefes” es básicamente la definición de empleo. Haces lo que alguien te pide y te pagan por eso

• En general estoy de acuerdo, pero agregaría algo: para entender lo que quiere tu manager, tienes que entender la estructura de negocio de la empresa. Debes averiguar por ti mismo cómo gana dinero la empresa y qué considera valioso. Cuando trabajas en un lugar alineado con tus valores, la compensación es mejor y la satisfacción también. Es importante hablar directamente con clientes, ventas, marketing y, si es posible, con ejecutivos. Incluso si trabajas en sistemas internos, lo clave es entender qué valor o qué protección aporta ese sistema. Si tu área no crea valor de forma clara, deberías pensar en moverte a un equipo que sí lo haga. Trabajar en algo que no se alinea con las necesidades de la empresa siempre fue un gran error

  • A mí me parece válido pensar en uno mismo como carpintero. Desarrollar significa implementar según la especificación, pero si esa especificación es absurda o imposible, hay que señalarlo directamente. Si el lado de negocio no puede explicar claramente su trabajo, entonces ni ellos mismos lo entienden. Además, si de verdad el desarrollador también tiene que entender bien el negocio, eso debería venir con una compensación acorde. Hay un costo de oportunidad: ese tiempo podría usarse para crecer más en lo técnico
  • Muchas veces ni siquiera se sostiene la premisa de que “tu manager realmente va a entender y valorar el negocio”

• El autor dijo que “hay que producir resultados visibles para quienes toman decisiones”, y conecto con esa mentalidad de “negocio”. A muchos desarrolladores les cuesta explicar cuál es la utilidad de negocio de su trabajo. El refactoring también entra ahí. Mejorar el código puede no parecer tener ningún valor en el corto plazo, pero según el contexto puede generar un beneficio enorme para la organización. Al final, lo importante es pensar cómo conectar tu trabajo con ingresos o ahorros para la organización, y cómo comunicarlo

  • Los desarrolladores tienen que aprender el lenguaje del negocio y enmarcar los problemas de una manera que la gente de negocio entienda y considere importante. Si ves la mayoría de las decisiones de negocio, casi todo termina siendo costo vs beneficio. De hecho, mucha gente de negocio también trata al software simplemente como un costo. Es decir, a diferencia de lo que muchos desarrolladores consideran obvio —“¿cómo que el software no está en el centro de generar ingresos?”—, al negocio no le importa el software en sí. Si pudieran venderlo gratis, como todos los costos serían 0, el margen sería infinito: eso es lo que en verdad quiere la gente de negocio. Ventas es un terreno donde pesan más el ambiente, las relaciones e incluso los sobornos que la razón. Puede sonar irracional, pero hay que entenderlo sí o sí

• Me pregunto si “esta forma de pensar es la razón por la que tantos ingenieros no se preocupan por la calidad del código, las pruebas y la documentación”. Si solo te enfocas en la satisfacción inmediata de la gente de arriba, ¿quién va a esforzarse por escribir código mantenible a largo plazo? No hace falta calidad por encima de lo requerido, pero incluso una inversión mínima puede ahorrar miles de millones

  • Cada vez más gente deja de preocuparse por la artesanía y la calidad. Se escucha mucho eso de “yo trabajo solo por lo que me pagan”. Antes existía más la idea de hacer bien el trabajo sin importar el sueldo, pero eso parece haberse perdido bastante
  • Todos tienen una razón para ocupar el rol que ocupan. Como en una producción de cine, los ingenieros también pueden tener objetivos distintos. Si impides que los ingenieros mantengan viva su motivación, al final solo te queda gente que se mueve por dinero. Eso es riesgoso
  • No creo que alguien escriba mal código a propósito. Cuando la apatía o el burnout aparecen en entornos donde el esfuerzo extra nunca se recompensa, nadie va a poner energía adicional. Y también muchos desarrolladores simplemente no son muy buenos. No es una profesión ultracompetitiva como la actuaría, así que puede entrar gente de cualquier origen, y además no es tan fácil volverse realmente competente
  • Muchos Product Managers solo quieren velocidad. Nosotros queremos pruebas y documentación, pero los CFO ven ese trabajo adicional como algo innecesario porque “no es una funcionalidad”
  • Como no se asume que un ingeniero vaya a quedarse mucho tiempo en la empresa, no siente responsabilidad por el futuro. Si cambias de trabajo constantemente, nunca sufres tú mismo los problemas del código que escribiste en tu empleo anterior, así que no aprendes del fracaso y repites el patrón. Yo llevo casi 20 años en la misma empresa y he visto los mismos errores una y otra vez. También me cansa ver cambios que solo maquillan la superficie mientras el problema esencial sigue intacto. Si no arreglas el problema real, el cambio no tiene sentido. Mi objetivo es resolver el problema de verdad

• He vivido esta realidad y estos problemas muchas veces, y aunque los entiendo, sigo en desacuerdo. Muchos proyectos arrancan y, cuando alguien dice “resuelto, ¡done!”, desarman el equipo. Pero el producto todavía tiene problemas, todavía necesita nuevas funciones, y la empresa sigue cambiando. Al final, por mala gestión, solo se acumula deuda técnica. Llega un nuevo manager, reconstruye un proyecto viejo y repite los mismos errores. Esa manera de trabajar es ineficiente. Si lo explicamos con la analogía del aire acondicionado: es más eficiente mantener una temperatura constante que apagarlo y volver a enfriar una y otra vez. De hecho, una herramienta de gestión que yo hice no le importaba a la dirección, pero más de 500 usuarios internos sí la necesitaban. Era importante mantener su confiabilidad continua sin invertirle demasiado tiempo de mantenimiento. Si la dejas abandonada, se fragmenta y se pierde la confianza en la herramienta. Unos pocos minutos bastaban para conservar la consistencia

  • La analogía del aire acondicionado en realidad está mal desde el punto de vista termodinámico. Apagarlo y luego volver a enfriar sí es más eficiente

• Tengo sentimientos encontrados en muchos sentidos. Sin duda, para visibilidad y ascensos este artículo tiene razón, pero en la práctica sigue siendo un consejo centrado en la gestión: simplemente satisfacer al manager. Pero ¿qué pasa si no hay una dirección clara y las prioridades cambian todo el tiempo? Entonces es difícil producir resultados significativos, y la relación manager-subordinado termina convertida en una estructura total de “yes-man”. Ese resultado no es bueno

  • La respuesta es simple. Si sientes que trabajas para un jefe idiota, simplemente renuncia. El sufrimiento es temporal, pero al final las cosas mejoran. Es mucho mejor que perder tiempo tratando de explicarle tu trabajo a un tonto
  • Por el contrario, si de verdad trabajas con un gran manager, “satisfacer al manager” por sí solo puede acelerar mucho tu carrera y también la calidad de tus resultados

• "unagentic engineer" significa un ingeniero sin autonomía. Si un ingeniero trabaja así, puede llevar a ineficiencias y problemas serios, como costos excesivos en la nube, incidentes de seguridad o quejas de clientes. Como ejemplos de trabajo que nunca se termina se mencionan los parches de seguridad, corregir errores, optimizar costos y responder al feedback de clientes. Si la empresa no entiende el valor de eso, la respuesta es cambiarse de trabajo

  • Ese es justamente el punto del texto. Hay organizaciones orientadas a la realidad y otras orientadas al estatus. Las primeras son racionales a largo plazo; las segundas solo buscan satisfacer al jefe. La jerarquía vale más que la calidad del producto o la relación con el cliente. No hace falta que esas organizaciones colapsen, pero a veces igual se derrumban de un momento a otro
  • “Unagentic” se refiere a un empleado sin agency, sin autonomía. Se supone que se espera que actúe con iniciativa, pero en la práctica el desarrollador cae en la trampa de volverse invisible incluso en su propia existencia
  • No tiene por qué ser así, pero si a la dirección no le importa, esa cultura se instala por defecto. Por ejemplo, a mí me gusta concentrarme en los detalles del diseño de interfaces. Pero ese cuidado solo se recompensa cuando la organización lo reconoce como algo valioso. En muchos lugares ni siquiera les importa
  • “unagentic engineer” describe a alguien con poca capacidad de tomar decisiones y empujar las cosas por iniciativa propia, alguien que simplemente se deja llevar por la corriente
  • Se refiere a un ingeniero poco autónomo, es decir, con poco poder de criterio y decisión
  • Es alguien que no tiene “high agency”: puede parecer inteligente y competente, pero siempre espera instrucciones y no toma la iniciativa por sí mismo

• Odio profundamente buzzwords como "alignment". Aun así, sí es un concepto importante en esencia. En un mundo ideal, yo, mi manager y la dirección por encima deberíamos estar de acuerdo en cuál es el trabajo más importante. Si eso no pasa, entonces es un problema para quienes formamos parte de esa organización. Sea correcto o justo o no, tenemos que vivir en función de eso. Al final, hacemos lo que nos dicen desde arriba porque para eso nos pagan. Solo una minoría muy pequeña tiene el privilegio de influir hacia arriba. A eso le llaman "managing up"

• El post original es útil, pero siento que le faltan puntos todavía más importantes:

  • Trabajar en el equipo correcto es más importante que hacer el trabajo correcto
  • Tener un buen PM y un buen manager es más importante que tener buenas tareas
  • Tener una buena cadena de reporte es más importante que el valor del resultado
  • El trabajo alineado con los objetivos del liderazgo se evalúa mucho más que el apoyo real a la operación del negocio
  • Siempre hay que estar preparado para hacerlo todo por cuenta propia, y en la política de las grandes empresas siempre existen desincentivos para colaborar

[heal9179]

Estas opiniones más bien están dando en el clavo.

[roxie]

Tal cual jajaja