Las 48 leyes del poder para programadores
Lecciones del libro de Robert Greene releídas para ingenieros de software que quieren más influencia y respeto en su trabajo.
El poder dentro del código
Seguramente conoces "Las 48 leyes del poder", el polémico libro de Robert Greene. Suele leerse como una guía de dinámicas sociales en entornos donde hay mucho en juego. Buena parte de esas leyes, escritas pensando en cortes y reinos, encaja también en el mundo tecnológico. Incluso en un sector que se considera meritocrático, leer bien las dinámicas de poder forma parte de cómo la gente gana influencia y acaba liderando.
No te estoy proponiendo montar intrigas maquiavélicas en la próxima daily. Se trata de percibir las fuerzas que ya operan en cualquier organización y actuar con intención. Aquí van cuatro de esas leyes, releídas para quienes pasamos el día dentro de un repositorio.
Ley 1: nunca eclipses al maestro, o a tu tech lead
En nuestro mundo el "maestro" es tu tech lead, tu responsable o alguien del equipo de arquitectura. Querer enseñar una solución ingeniosa es natural, pero hay momentos en los que conviene dejar que la victoria sea de quien está por encima.
Puedes pensar: "pero si de verdad soy bueno en esto, ¿por qué esconderlo?". No se trata de esconder tu talento, sino de cómo lo presentas. Si señalas los fallos de tu lead delante de todo el mundo, o despliegas una solución que se salta su criterio, no estás sumando aliados. Estás creando rivales.
En la práctica eso significa proponer soluciones en vez de limitarte a encontrar defectos. "Tu código es ineficiente" suena muy distinto a "he estado mirando una optimización para esta función que podría mejorar el rendimiento". También significa reconocer cuándo la idea de otra persona desbloqueó tu trabajo, y apoyar la dirección de tu lead durante un proyecto grande en lugar de intentar taparla.
Alguien seguro de sí mismo valorará lo que aportas. Alguien inseguro puede leerlo como una amenaza. Distinguir entre los dos y ajustar tu forma de actuar es una habilidad útil.
Ley 7: consigue que otros hagan el trabajo, pero llévate el mérito
Fuera de contexto suena duro. Releída para programadores va de delegar, acompañar a otros y ejercer influencia: sacar más adelante habilitando a la gente en lugar de escribir tú cada línea.
Cuando pasas a roles senior o de liderazgo, ya no escalas echando más horas de código. La palanca está en el acompañamiento. Si guías a alguien junior a través de un problema y esa persona entrega, tú te llevas el mérito de haber construido un buen equipo y ella se lleva la experiencia. Con las revisiones de código pasa igual: en vez de arreglar tú el fallo, lleva a quien lo escribió hasta la corrección. Sus habilidades crecen y el código mejorado refleja el trabajo del equipo.
Lo mismo aplica a la arquitectura. Tú defines la forma de un sistema complejo, el equipo implementa los módulos y, cuando eso llega a producción, la dirección que marcaste se ve en el resultado.
La idea no es holgazanear, sino multiplicar. El mérito que dura viene de proyectos ambiciosos terminados por un equipo bien dirigido.
Ley 11: haz que dependan de ti
Suena posesivo, pero en un contexto profesional significa volverte realmente valioso y difícil de reemplazar: habilidades, conocimiento o relaciones que te convierten en una pieza clave.
Una parte de eso es estabilidad laboral. La otra es influencia. Cuando la gente depende de lo que sabes, tu opinión pesa más.
Ocurre por varias vías. Te conviertes en la persona de referencia para un sistema crítico o poco atractivo que los demás evitan. Entiendes la lógica de negocio que hay detrás del código mejor que nadie, así que cuando alguien necesita saber por qué algo funciona de determinada manera, acude a ti. Acumulas ese conocimiento no escrito sobre cómo se conectan los sistemas heredados, las rarezas de una API antigua o el motivo de una decisión de arquitectura. O te vuelves el puente entre desarrollo, QA, producto y operaciones, y tu capacidad de traducir entre ellos es lo que hace avanzar los proyectos transversales.
La distinción importante: no acapares información. Sé quien resuelve los problemas que otros no pueden, o los resuelve más rápido.
Ley 18: no construyas fortalezas para protegerte
Es fácil desaparecer dentro del editor con los cascos puestos. El trabajo concentrado es bueno. El aislamiento total no lo es, al menos para tu influencia y tu crecimiento.
"Es que yo solo quiero escribir código" es una postura legítima. Pero si únicamente hablas con tu equipo inmediato, te pierdes oportunidades y puntos de vista, y tu reputación se detiene en el borde de ese equipo.
Ofrecerte para proyectos que cruzan varios equipos amplía tu red y demuestra que sabes trabajar fuera de tu terreno. Los grupos internos, las charlas técnicas y los meetups te permiten compartir lo que sabes y conocer gente. Las revisiones de código también son un espacio social: pregunta, ofrece ayuda, aprovéchalas para ver otras partes del proyecto. Estar disponible cuando alguien necesita una mano, aunque no sea tu tarea, se acumula con el tiempo.
Mantenerte conectado es lo que hace que te enteres de las oportunidades, ganes aliados y tu trabajo se vea más allá de tu círculo inmediato.
Código y contexto
"Las 48 leyes del poder" es una fuente inesperada de consejo profesional para programadores, pero si le quitas el decorado histórico queda una descripción de dinámicas organizativas corrientes. La habilidad técnica es lo primero, y rara vez basta por sí sola para llegar al nivel donde se toman las decisiones.
Entender cómo funciona la influencia en el día a día de tu equipo te hace más efectivo. No es jugar a nada, es ver el tablero.