- Un texto que presenta estrategias prácticas para que los ingenieros participen de forma efectiva en la política organizacional de las empresas tecnológicas, y aborda cómo superar la sensación de impotencia política que tienen muchos ingenieros
- Los ingenieros no son jugadores del juego político sino herramientas, pero pueden ejercer influencia política apoyando activamente el éxito de proyectos de alto nivel o proponiendo ideas técnicas alineadas con cambios en las prioridades de la organización
- Como los intereses de la organización cambian como olas, la estrategia clave es tener preparados de antemano programas técnicos en distintas direcciones, como estabilidad, experiencia de desarrollador y mejoras de rendimiento, y proponerlos en el momento adecuado
- Cuando chocan la necesidad política y la ausencia de buenas ideas, se toman las peores decisiones técnicas, y los ingenieros senior tienen la responsabilidad de presentar la idea correcta en el momento oportuno
- Visto con cinismo, esto significa convertirse en una herramienta para luchas de poder; visto con optimismo, es una forma de cumplir tus objetivos técnicos mientras respetas la definición de prioridades de la dirección
La creencia común sobre la impotencia política de los ingenieros
- Muchos ingenieros de software tienen una actitud fatalista frente a la política de la empresa y creen que participar no sirve de nada
- Las decisiones técnicas a menudo se toman por motivos completamente egoístas, así que un ingeniero de buena fe no puede influir
- Las partes interesadas con poder son demasiado incompetentes y disfuncionales, por lo que entender sus demandas y ofrecer soluciones es prácticamente imposible
- El juego político depende de información privada que los ingenieros no tienen, así que intentar participar solo termina en torpeza
- Mientras gerentes y ejecutivos dedican la mayor parte de su tiempo a la política, los ingenieros dedican el suyo a la ingeniería, así que parten con una gran desventaja política
- Es cierto que los ingenieros de software no pueden jugar al mismo nivel que los verdaderos operadores políticos
- Que un ingeniero empiece a intrigar como en Game of Thrones es un error terrible, y ese tipo de maniobras se detectan enseguida y se usan en su contra
- Para tramar intrigas hacen falta práctica y poder, y los ingenieros de software no tienen ninguna de las dos
Formas prácticas de participar en la política
- En una gran empresa, la realidad simple es que los ingenieros de software no son jugadores del juego político sino herramientas, pero aun así hay muchas formas de participar en política sin recurrir a intrigas
- La forma más fácil es trabajar activamente por el éxito de proyectos de alto perfil
- Eso se parece mucho a lo que de todos modos habría que hacer como parte del trabajo normal
- Si la empresa está invirtiendo mucho en un nuevo proyecto (hoy en día probablemente uno de IA), usar tu capacidad de ingeniería para hacerlo exitoso es un movimiento políticamente favorable para el VP o ejecutivo que lidera ese proyecto
- A cambio, recibirás recompensas que un ejecutivo puede dar en una empresa tecnológica: bonos, ayuda para ascender o puestos en futuros proyectos de alto perfil
Usar ideas técnicas en campañas políticas
- Un enfoque un poco más difícil, pero que te da más control, es hacer que tus ideas preferidas sean útiles para una campaña política ya existente
- Supongamos que quieres separar una funcionalidad existente en un servicio independiente; hay dos maneras de hacerlo
- La manera difícil: gastar tu capital político para reunir apoyo, convencer a tu gerente de su importancia y persuadir poco a poco a los escépticos para conseguir aprobación para el proyecto
- La manera fácil: permitir que un ejecutivo gaste su propio capital político (mucho mayor) en el proyecto
- Esperar hasta que haya una directiva de toda la empresa sobre un objetivo alineado con el proyecto (por ejemplo, énfasis en estabilidad después de un incidente importante)
- Luego sugerirle a tu gerente que tu proyecto podría encajar ahí
- Si evaluaste bien la situación, la organización apoyará el proyecto y, en vez de gastar capital político, lo aumentarás
Surfear las olas de interés de la organización
- El interés de una organización llega en olas
- Cuando toca una etapa de estabilidad, los VP están desesperados por hacer algo y quieren encontrar proyectos de estabilidad que suenen convincentes para mostrarle a sus jefes, pero no tienen la capacidad de hacerlos por sí mismos
- Por lo general, están dispuestos a financiar casi cualquier cosa que proponga el equipo de ingeniería
- En cambio, cuando la atención de la organización está centrada en otra cosa (por ejemplo, el lanzamiento de un gran producto nuevo), no quieren que los ingenieros gasten tiempo en refactors internos centrados en estabilidad que no son visibles para el cliente
- Para completar trabajo técnico en una empresa tecnológica, hay que esperar la ola adecuada
- Es buena idea tener preparados por adelantado programas técnicos en varias direcciones distintas
- Los ingenieros sólidos suelen detectar esto de forma automática en el trabajo cotidiano
- Planes de ejemplo:
- Migrar el código de facturación desde llamadas a API en caché a datos almacenados que se actualizan por webhooks
- Eliminar un viejo pipeline de build hecho a mano y reemplazarlo con Vite
- Reescribir en Golang un servicio desordenado de Python con mucho tráfico
- Reemplazar un frontend lento de CMS que da soporte a documentación pública por un sitio estático rápido
La importancia de proponer en el momento adecuado
- Cuando los ejecutivos estén preocupados por la facturación, puedes presentar un refactor de facturación como una mejora de estabilidad
- Cuando estén preocupados por la experiencia de desarrollador, puedes proponer reemplazar el pipeline de build
- Cuando los clientes se quejen del rendimiento, puedes presentar la reescritura en Golang como una buena opción
- Cuando el CEO revise el estado de la documentación pública y entre en pánico, puedes argumentar a favor de reconstruirla como un sitio estático
- Lo importante es tener listo un programa de trabajo detallado y eficaz, ejecutable de inmediato, sea cual sea la moda del mes
El momento en que se crean las peores decisiones técnicas
- Aunque no sigas este enfoque, algunos programas igual recibirán presupuesto, pero si no lo haces, no podrás controlar cuáles serán
- Aquí es exactamente donde una empresa toma las peores decisiones técnicas: cuando choca la necesidad política de hacer algo con la ausencia de buenas ideas
- Si no hay buenas ideas, se termina usando una mala, pero nadie prefiere ese resultado
- Es malo para los ejecutivos: tienen que vender un resultado técnico decepcionante como si fuera un éxito
- Es malo para los ingenieros: tienen que gastar tiempo y esfuerzo construyendo una mala idea
- Si eres un ingeniero muy senior, los VP te lo reprocharán en silencio, y tendrán razón
- Tener lista la idea correcta en el momento oportuno es tu responsabilidad
Dos perspectivas
- Perspectiva cínica: esto puede leerse como una propuesta para convertirte en una herramienta conveniente para sociópatas que dirigen la empresa y la usan en una interminable lucha interna por el poder
- Perspectiva optimista: puede leerse como una propuesta para dejar que los ejecutivos definan las prioridades generales de la empresa (porque ese es su trabajo) y alinear con eso tus propios planes técnicos
- En cualquiera de los dos casos, si impulsas el plan correcto en el momento indicado, podrás lograr más objetivos técnicos
Reacción en Hacker News y citas relacionadas
- Este artículo llamó la atención en Hacker News y recibió una reacción mucho más positiva que otros textos sobre política
- Un comentario mencionó una cita de Milton Friedman y aplicó la idea del artículo a la política pública en general
- "Solo una crisis (real o percibida) produce un cambio verdadero. Cuando esa crisis ocurre, las acciones que se toman dependen de las ideas que están dando vueltas. Esa es nuestra función básica: desarrollar alternativas a las políticas existentes y mantenerlas vivas y disponibles hasta que lo políticamente imposible se vuelva políticamente inevitable"
- Algunos comentarios criticaron este enfoque por parecer demasiado calculador y egoísta, pero el autor considera que eso depende del objetivo
- Un comentario resume muy bien la idea central del artículo: "En lugar de esperar instrucciones, ser cínico ante las malas ideas cuando aparece un vacío y no hacer lo que quieres, el autor mantiene un backlog de ideas buenas e importantes para plantearlas cuando una persona importante diga que algo es prioridad. Cede en el timing para poder lograr lo que quiere"
1 comentarios
Comentario en Hacker News
El punto de esta publicación es el siguiente
El primer punto puede sonar obvio, pero es algo sobre lo que he tenido que orientar muchas veces a gente al inicio de su carrera Muchas personas que iban rumbo a tener problemas o incluso a un PIP lograron dar un giro solo con ejecutar bien este ciclo
Interpreto el punto 2 como preparar mi propia agenda. Por ejemplo, si quiero que el codebase sea más minimalista, preparo un PoC y los detalles relacionados para poder proponerlo de inmediato cuando se presente la oportunidad Gracias a esa preparación, si estallan problemas de velocidad del sitio, SEO o bugs, también puedo proponer esa idea minimalista como solución El concepto me parece interesante, aunque todavía pienso mucho en cómo aplicarlo en la práctica. A menudo me pregunto si debería dejar preparados documentos para usar en el futuro. Algo así como documentar de forma continua mi trabajo, como si llevara un blog, y esperar la oportunidad Mucho de ese trabajo extra puede terminar siendo en vano, pero la verdad es que siento que ya hago bastante de eso de todos modos
Otra cosa que quisiera agregar es: no hagas a la ligera cosas a las que se opongan personas con más poder político que tu gerente. La excepción es si alguien todavía más poderoso les da una instrucción pública No digo que necesariamente hagas lo que esas personas quieren, sino que es importante tener cuidado de no hacerlas enojar sin necesidad Casi nunca vale la pena ganarse enemigos, y la mayoría de los gerentes, en una crisis, también pueden convertirte en chivo expiatorio para protegerse
Yo prefiero proponerle directamente a mi gerente “qué deberíamos hacer”. Pongo temas importantes sobre la mesa y explico por qué Hay que ser proactivo para que el gerente se beneficie de mi experiencia Yo tampoco tengo tantísima experiencia en esto, pero sí he tenido algunos casos exitosos
Este consejo se vuelve más importante conforme subes de nivel. También aplica para engineering managers, y yo trataba de aplicar este principio incluso cuando era director y reportaba directamente al CTO
Una de mis citas favoritas es esta: "Solo una crisis real, o una crisis percibida, produce un cambio verdadero. Las acciones que se toman en ese momento dependen de las ideas que andan circulando alrededor. Nuestra función básica es desarrollar políticas alternativas, mantenerlas vivas y disponibles hasta que lo políticamente imposible se vuelva políticamente inevitable" - Milton Friedman Escribir 1 Pagers y documentos técnicos, compartirlos por adelantado y volver a citarlos cuando llega una crisis me ha servido para impulsar mis ideas Hubo veces en las que fui empujando gradualmente la dirección de arquitectura que quería, acercándome cada vez más a la meta, y fue importante ir construyendo consenso Claro, también muchas veces me ganaron VP o directores con mucha más habilidad política que yo Pero me resultó mucho más efectivo tener preparada una biblioteca de 1 Pagers, compartirlos sutilmente y seguir “esparciéndolos” en el ambiente hasta que surgiera la motivación para ejecutarlos
Me identifiqué con la parte de “perdí la pelea política”. Una de las cosas sorprendentes que noté al convertirme en gerente de nivel medio o más arriba es lo visibles que resultan las maniobras políticas de los empleados de niveles inferiores Muchos IC o EM de primer nivel sobreestiman su sensibilidad política o su IQ social Además, la profundidad y amplitud de la comunicación dentro de la organización es distinta, así que, aunque creas que te estás moviendo para convencer a alguien, ese stakeholder luego puede ir a comentarle discretamente el contexto a su gerente Mientras nosotros, desde el equipo de management, intentábamos controlar en silencio maniobras políticas torpes, vi muchas veces escenas así
Me gustaría entender de forma más concreta qué significa eso de “dejar circulando 1 Pagers y documentos técnicos”
Coincido con esa cita y creo que este método puede funcionar. Pero en la realidad, la escala de tiempo puede ser absurdamente larga, al punto de desgastar Además, muchas veces las crisis simplemente se ignoran, así que ni siquiera se reconocen como tales o terminan normalizándose
Tengo curiosidad por saber si esos 1 Pagers te ayudaron a ganar reconocimiento y ascensos en tu carrera, o si solo sirvieron para que las ideas se hicieran realidad
Esta me parece la mejor forma
Desplegar seguido a producción (más entrega real que trabajo teórico)
Lograr resultados significativos (wins) con métricas acordadas
Tener a alguien en management o en PM que sepa vender bien mis éxitos Pero aun así siguen apareciendo problemas. Siempre llega un VP o líder nuevo queriendo mostrar innovación. Al equipo que mantiene los sistemas existentes lo etiquetan como el equivocado, y el nuevo VP marca su línea con ideas progresistas como la IA. Desde el momento en que mi código se despliega, ya lo tratan como “legacy” Entonces el VP empieza a lanzar promesas brillantes sobre el futuro, y desde mi rol de sostener la realidad actual no tengo forma de competir. La realidad no es sexy ni divertida. Así terminas convertido en la vieja guardia Al final, la esencia es la relación de patrocinio: ayudar a que el VP que está por encima de ti tenga éxito y crear una posición para irte con esa persona cuando cambie de empresa
Me parece totalmente cierto. Si vamos un nivel más abajo, como staff engineer es importante dejar muy claro que “yo no soy el código en sí”. Desde el momento en que se despliega, el código ya es deuda/legacy Lo mejor es posicionarme no como “defensor del código”, sino como un EQUAL PARTNER de liderazgo, producto, tomadores de decisión, etc. Esto es simplemente una cuestión de perspectiva o framing. Puedes hacer exactamente las mismas acciones, pero si te ven como “socio del negocio”, los líderes te perciben como un colaborador activo; si no, te convierten en un obstáculo que hay que convencer a la fuerza, y la diferencia es enorme
Coincido muchísimo con eso de “necesitas a alguien en PM que sepa vender bien tus logros”. Viéndolo en retrospectiva, una de las cosas que más pudo cambiar mi carrera fue la rapidez con la que me alejé de PM malos Un buen PM mejora todo, pero es difícil de encontrar. En cambio, cuando un PM marca mal la dirección, todo se descompone, y en cuanto esa persona desaparece, el ambiente cambia por completo
Me encantó la expresión “no puedes competir con promesas sobre el futuro”. Eso pasa demasiado seguido. Incluso si esa promesa nunca se cumplió las 26 veces anteriores, el “futuro glorioso” siempre parece impresionante
En el trabajo real, la idea de desplegar seguido a producción (rep = ejecución, nada de teoría) es buena, pero me pregunto por qué las promesas vagas de futuro de un VP se valoran más que la viabilidad real
Nunca había oído el término “trabajo teórico”, pero claramente hay lugares donde despliegan todos los días. Aun así, no creo que desplegar seguido sea necesariamente ideal. Me pregunto qué cosa sustancial se puede desplegar en un solo día. Los proyectos que generan ingresos adicionales para la empresa, al menos en mi caso, no pueden terminarse en un día. Si el trabajo se pudiera cerrar en un día, sería como decir que solo se necesita un ingeniero cuatro veces al año. Por eso, ese “desplegar seguido” puede terminar siendo más bien una vanity metric
Como nunca he trabajado en una empresa dysfunctional, no conecto para nada con la primera parte de este texto En mi experiencia, siempre hubo mucha comunicación top-down, y aunque desarrolláramos en una dirección con la que yo no estaba de acuerdo, antes se conversaba lo suficiente como para que me resultara interesante entender por qué colegas inteligentes veían las cosas distinto que yo No sé si es porque solo he trabajado en empresas fundadas por ingenieros o si simplemente he tenido suerte
Los VP senior en empresas grandes tienen metas más amplias, y también una noción más amplia de los medios. Eso no es necesariamente malo. Les da la posibilidad de probar varios caminos antes de fijarse en una tecnología o metodología específica. Claro, hay desperdicio, pero también puede ser eficiente para reaccionar de inmediato a cambios sísmicos en la industria y cumplir la misión del equipo ejecutivo
Tengo curiosidad por saber en empresas de qué tamaño has trabajado
“Una ruta un poco más difícil, pero que te da más control, es alinear tus ideas con una campaña política que ya exista” Yo aprendí la habilidad de colgarme bien de proyectos impulsados por un VP. Es amargo, pero funciona
Una frustración muy común en este campo es: “hice perfectamente el refactor completo del código y nadie lo reconoce” Hace tiempo, un conocido se jactaba de haber limpiado a la perfección un pipeline de datos durante meses, pero nadie entendió el valor de eso, y me hizo pensar varias cosas Como ingeniero, yo sé que ese trabajo tiene valor, pero desde la perspectiva de un PM o un EM, me parece parecido a que un PM dijera que pasó un mes poniendo puntitos y ordenando todos los documentos internos de ingeniería, y que la reacción fuera: “¿y eso qué impacto tuvo en la empresa?” Desde la óptica de un PM, se vuelve ambiguo cómo distinguir entre un ingeniero influyente y uno que solo hace “trabajo de formato” Al final, lo importante es explicar con claridad, de antemano y en un formato adecuado para una audiencia no técnica, qué es lo que estás planeando hacer Antes impulsé unit tests e integration tests, pero como faltaba voluntad política, una y otra vez quedaban fuera de las prioridades. Cuando finalmente ocurrió un SEV grande, dije: “necesitamos tests para evitar esto”, y recién ahí todos estuvieron de acuerdo con el valor. Ahora cualquiera entiende por qué hacen falta tests
Totalmente de acuerdo. Si yo estoy en la posición de empujar una acción como prioridad, necesito explicarla usando la lógica y el lenguaje de quienes toman prioridades para que mi argumento funcione Por ejemplo, los PM normalmente piensan en términos monetarios. Si presento mi objetivo técnico, como ampliar el test coverage, diciendo que requiere 200 dev hours al año pero puede ahorrar 400 dev hours al año, reducir 15% los support tickets o habilitar escenarios futuros de negocio, entonces convencer se vuelve mucho más fácil Un truco que me gusta es empaquetar el trabajo de tech debt no como “trabajo técnico”, sino como un efecto claro para el negocio, y hacer que el PM lo meta al roadmap por iniciativa propia Este enfoque se vuelve más fácil con la experiencia. Al principio puede haber escepticismo, pero con el tiempo se construye confianza en mis estimaciones y resultados, y cosas que antes requerían varias reuniones ahora se resuelven en una conversación de 10 minutos
También estoy de acuerdo con este comentario. Pero siento que también se puede pensar al revés Por ejemplo, en una obra de construcción, aunque alguien revise y mantenga cuidadosamente los sistemas de seguridad para prevenir accidentes, muchas veces management no reconoce ese valor ni da recompensas por ello El hecho de que no se reconozca ningún beneficio si no puede expresarse cuantitativamente como ROI ya es en sí mismo una falla enorme de management, y cuando la seguridad está directamente ligada a vidas humanas, también es una falla moral De hecho, esto es exactamente lo que está pasando hoy en Boeing
La clave es explicarlo en términos de valor que la audiencia pueda entender. Al final, eso es una habilidad de ventas, y creo que a la mayoría de los desarrolladores les falta experiencia para notarlo. Lo ideal es que un buen gerente lo apoye bien, y cuando además trabajas con un staff dev o un engineering manager alineado contigo, de verdad se logran grandes resultados Siempre agradezco cuando colaboro con colegas así
Si necesitas explicar la necesidad de lavarse las manos para conseguir inversión y aprobación, entonces algo anda mal en ese equipo. Igual que un chef de restaurante de primer nivel no debería necesitar convencer a nadie de comprar jabón, siento que entrar a una organización donde eso es obvio ya es un escalón en la carrera. Un SWE exitoso trabaja en equipos donde ese nivel es la base
De acuerdo. El refactoring es una responsabilidad natural del desarrollador. Si lo haces de forma natural junto con el desarrollo de features y actualizas el calendario de entrega, entonces basta con coordinarte entre técnicos y persuadir se vuelve mucho más fácil, mientras la calidad del codebase mejora drásticamente en el largo plazo. Como resultado, el mantenimiento se vuelve más fácil y desarrollar nuevas funcionalidades se acelera
El mayor capital político que puedo acumular es mi comprensión técnica y mi capacidad. Pero ese poder solo sirve cuando puedo aconsejar y entregar de forma concreta dentro del contexto y la estrategia general de la empresa Si doy buenos consejos y actúo por el bien de la empresa, la gente empieza a escucharme y a depender de mí. Al final, eso crea autoridad para influir en la dirección Tener preparado un plan B apropiado, una opción de gestión de riesgos, y proponerlo y ejecutarlo cuando haga falta es la mejor forma
Hay un libro de carrera bastante radical, pero con buenos puntos Uno de ellos es que la habilidad técnica puede incluso perjudicar mi carrera y mi poder. Si uso mi tiempo y mi energía en hacer realmente cosas, un gerente competente hará activamente lo posible por dejarme atado a mi puesto para que no gane demasiada influencia política En cambio, si me convierto en gerente, no debo hacer nada real por mí mismo y solo debo iniciar la mayor cantidad posible de iniciativas (proyectos, políticas, cambios), maniobrando con destreza el poder político que tengo No importa si esas iniciativas realmente generan valor, ni siquiera hace falta preocuparse por eso. Yo ya habré salido del tablero, y quienes siguen aquí obsesionados con el éxito y el valor real serán los que se queden atrás Si hace falta, el gerente incluso puede atribuirse el crédito después de los hechos y decir “eso lo hice yo”
“Se necesitan equipos dedicados a girar según la flavor of the month para que las cosas se muevan” — esa es mi teoría política. En Washington DC pasa igual. No existe un gran plan; lo que hay es una tropa siempre lista para hacer el pitch apenas aparece la oportunidad
Si tienes que practicar peleas políticas y acumular poder, lo correcto es buscar otra empresa Puede que suene ingenuo, pero no todas las empresas son así. La mía no lo es