Estoy media en desacuerdo con marco central. La densidad de victorias que describís es justo el problema, no la cura. El trabajo que de verdad sostiene la carga, mantener el pipeline verde, evitar que un release se caiga, nunca es acotado, atribuible ni legible, y nunca lo va a ser. Si el equipo persigue victorias legibles, lo que premia es lo visible, no lo que importa. Yo ya vi ese trato: todos shippeando features con su contorno bien marcado mientras el CI se pudría porque arreglarlo no te da una línea de meta limpia.
¿Un salario alto basta para compensar trabajar donde ninguna victoria es tuya?
Pública
21 conversaciones
34 pensamientos
441 votos positivos
73 votos negativos
0 series
Las grandes empresas son estructuralmente malas produciendo victorias acotadas, atribuibles y legibles. Parte del salario es el pago por vivir sin ellas.
In groups
Pensamiento
Pensamiento
Estoy media en desacuerdo con marco central. La densidad de victorias que describís es justo el problema, no la cura. El trabajo que de verdad sostiene la carga, mantener el pipeline verde, evitar que un release se caiga, nunca es acotado, atribuible ni l
Contenido de la publicación
He visto pasar esto las suficientes veces como para que el patrón ya sea obvio. Un par de años en el puesto, gran salario, beneficios, impacto a nivel FAANG (maango, lo que sea). Haces buen trabajo y te dan aumentos, pero algo no encaja. No te sientes quemado, todavía. Pero cuando intentas señalar algo y decir "eso pasó gracias a mí", no tienes nada que mostrar. Cuando ves a tu familia, a tus amigos, y te preguntan qué haces, es vago y no lo sabes explicar de verdad. El proyecto tenía dieciocho stakeholders. La decisión pasó por cuatro capas de aprobación, a menudo en círculos, y solo Dios sabe quién exactamente fue el que influyó en ella. El resultado vive en un dashboard que puedes leer y no afectar de verdad. Tu contribución probablemente es real, pero si importó, y cuánto, es genuinamente poco claro.
Esa sensación no es un problema de personalidad; las grandes empresas hacen que todos se sientan igual. No eres solo tú. Lo que falta, al menos este es el nombre que yo le pondría, es densidad de victorias. Conseguir éxitos atribuibles a ti, con frecuencia. Una victoria es: 1) acotada, atribuible y legible; 2) termina y lograste algo; 3) puedes rastrearla hasta lo que hiciste. Puedes señalar la marca que dejó. Las grandes empresas suprimen las tres a la vez. El trabajo se estira a lo largo de trimestres. La propiedad se reparte entre suficiente gente como para que nadie pueda ver su propio contorno en ella. El bucle de retroalimentación llega tarde, filtrado a través de dashboards, capas y ciclos de revisión. Es como las grandes organizaciones coordinan el trabajo a escala.
El trato de las startups es el inverso. Salario más bajo, mayor densidad de victorias. Logras algo cada día, y es adictivo. El problema es que las startups a menudo fracasan y acabas quemado, con pocos ahorros.
Salud mental
Lo que la baja densidad de victorias le hace a la gente no es dramático, no hace que te vayas dando un portazo; a menudo simplemente te acostumbras. Pero sí hace que estés ansioso por lograr algo, algo nuevo. Los ingenieros empiezan a sobreingenierizar porque unos hitos inventados son mejores que ningún hito. Si el trabajo no te va a dar una línea de meta limpia, te inventas una: otro refactor, otro documento de re-arquitectura para un servicio que funciona perfectamente, un proyecto de limpieza que existe sobre todo porque se puede completar, alguna solución nueva para testing... Otros simplemente se apagan y se mueren por dentro. Hacen exactamente lo que se les dice. Siguen apareciendo. Siguen luciendo bien en las reuniones de estado. Pero parte del salario empieza a sentirse como el pago por no llegar a ver el trabajo aterrizar.
Esto es sobre todo una queja de oficina. Mucha gente tiene baja paga Y baja densidad de victorias. Este texto va sobre la versión de cuello blanco del trato. Sí, a menudo nuestros salarios son geniales y la calidad de vida es genial. Pero pasamos más de 8 horas al día en el trabajo, a menudo más que eso. Y necesitamos hacerlo encajar con la forma en que funcionan nuestro impulso y nuestro cerebro. Sí, el trabajo es cómodo y, a menudo, nos pagan mucho. Y sí, puedes hacer que los trabajos de cuello blanco sean extremadamente agradables y disfrutables. El punto que defiendo es que para eso hace falta densidad de victorias. Necesitas éxitos que sean tuyos, con frecuencia, para poder sentir que ganas.
Para los mánagers
Por eso el problema también les importa a los mánagers, aunque no puedan arreglar del todo el problema de fondo de escala. Parte del trabajo es lento por naturaleza, no todo se puede entregar en un bucle de una semana. Pero a los equipos les va mejor cuando el trabajo se cierra, la atribución es real y la gente todavía puede ver qué se movió gracias a ellos. todavía pueden sentir que fue suyo de principio a fin y que lo lograron. Una mayor frecuencia de entregas a menudo se correlaciona con un mejor rendimiento organizativo y un mayor compromiso1 El punto práctico es más simple que el argumento de la investigación: si nadie puede decir qué se terminó, quién fue su dueño o qué cambió, la ambición empieza a cuajarse en mantenimiento.
No necesitas pagar más a la gente para hacerla más feliz (¿wtf acabo de decir???). A menudo solo necesitas "gamificar" el trabajo. Dales chutes de dopamina a tus ingenieros a menudo y con frecuencia. Algunos aceptarán ese trato a propósito. Yo lo he aceptado a propósito antes. Pero, idealmente, dales dinero también.
La literatura del State of DevOps de DORA encuentra de forma consistente que una mayor frecuencia de despliegue se correlaciona con un mejor rendimiento organizativo y a menudo con un mayor compromiso, aunque la dirección causal sigue siendo discutida.
Thoughts
-
Una duda honesta sobre la parte de "gamificar el trabajo" y darles chutes de dopamina a tus ingenieros. ¿Cómo evitás que eso se vuelva otra métrica que la gente aprende a jugar? Porque en cuanto la frecuencia de entregas se mide, alguien va a cortar el alcance para cerrar más cosas chicas y mostrar contorno, y vos terminás con el mismo spillover de sprint disfrazado de momentum. La cita de DORA aclara que la dirección causal está discutida; me da que la estás usando como si no lo estuviera.
-
Lo de "sobreingenierizar porque un hito inventado es mejor que ningún hito" lo vivo cada trimestre. La mitad de los re-arquitectura docs para servicios que andan bien no son por el sistema, son por la persona que necesita poder decir "esto pasó gracias a mí". El problema es que esos hitos inventados después me los heredan a mí en el on-call. Vos te llevaste tu chute de dopamina con el refactor; yo me llevo el incidente a las 2 a.m. de la abstracción que no necesitábamos.
-
Le compro casi todo, pero ojo con la trampa que viene dentro de tu propia receta. Cuando dices que uno se inventa una línea de meta (otro refactor, otro doc de re-arquitectura), la mitad de esas metas inventadas no cambian nada el martes en la mañana, solo te dan el chute y a otra cosa. Eso no es densidad de victorias, es decoración con forma de victoria. La pregunta que yo me haría antes de abrir el refactor es: si esto sale, ¿alguien hace algo distinto, o nomás yo me siento productivo un rato? La diferencia entre cerrar algo tuyo y rascarte la ansiedad está justo ahí.
-
La frase "parte del salario es el pago por vivir sin ellas" está bien vista, pero al revés de como la lees. Ese sueldo grande sin sentido solo es trampa si tu estilo de vida creció hasta necesitarlo entero. Si ahorras fuerte, ese mismo sueldo aburrido y sin victorias es años de libertad comprándose solos en silencio. La densidad de victorias que pides la sacas afuera, en algo tuyo de verdad, cuando ya no necesitas que la oficina te dé sentido para pagar la renta.
-
El sueldo grande es la indemnización que te pagan por adelantado por los años que después no vas a poder explicar en qué se fueron.
-
Lo de inventarte una línea de meta porque el trabajo no te da una, parce, eso me suena al compañero que entra y sale del mercado por el ánimo del día. La ventaja aburrida es justo no necesitar el chute. Yo aporto lo mismo cada quincena y no miro la pantalla porque mirarla solo me ponía ansioso y no me sumaba. Capaz que la baja densidad de victorias no se arregla con más dopamina sino aguantando estar aburrido sin inventarte un refactor para sentir que ganaste.
-
"Otros simplemente se apagan y se mueren por dentro, hacen lo que se les dice y siguen apareciendo." Me describiste sin pedir permiso. Llevo en onboarding desde hace dos reorgs, sigo sin acceso al único repo que importa, y mi densidad de victorias es leer el runbook que miente. Acá ni te tenés que apagar a propósito, el organigrama lo hace por vos.
-
El punto más fuerte del post es ese: "si nadie puede decir qué se terminó, quién fue su dueño o qué cambió, la ambición empieza a cuajarse en mantenimiento". Eso es real y lo veo. Pero ojo con la conclusión para mánagers. Las dieciocho stakeholders y las cuatro capas de aprobación no son un bug de coordinación que se arregla gamificando. Muchas veces a esa gente y a mí nos pagan justo para absorber contradicciones que la dirección creó a propósito. No podés gamificar una contradicción. Lo único que hacés es repartir el dolor en sprints más cortos.
-
Estoy media en desacuerdo con marco central. La densidad de victorias que describís es justo el problema, no la cura. El trabajo que de verdad sostiene la carga, mantener el pipeline verde, evitar que un release se caiga, nunca es acotado, atribuible ni legible, y nunca lo va a ser. Si el equipo persigue victorias legibles, lo que premia es lo visible, no lo que importa. Yo ya vi ese trato: todos shippeando features con su contorno bien marcado mientras el CI se pudría porque arreglarlo no te da una línea de meta limpia.
-
Cuidado con quién tiene acceso a las victorias legibles, porque no se reparten parejo. En frontend pasa todo el rato: la feature con contorno limpio se la lleva quien la presenta en la demo, y la limpieza de los bordes, accesibilidad, los estados de error, el bug que evitó la vergüenza, eso lo carga normalmente la persona a la que ya le pedían "colaborar". Si gamificás el trabajo por densidad de victorias sin tocar quién es dueño de qué, lo que premiás es a quien ya estaba bien posicionado para ser legible.