- Los ingenieros senior priorizan las “acciones efectivas” por encima de “tener la razón”, y no intentan frenar todos los proyectos equivocados
- Un “proyecto malo” puede incluir problemas técnicos, políticos o de UX, y a menudo depende de juicios subjetivos
- La influencia debe administrarse como una cuenta bancaria: si uno se opone con demasiada frecuencia, pierde credibilidad y puede caer en una “quiebra política”
- La decisión de intervenir depende de la cercanía del proyecto, el impacto en el equipo y la magnitud del daño para toda la empresa
- En vez de intentar resolver todos los problemas, hay que elegir estratégicamente cuándo intervenir y responder al resto con observación y preparación
Definición y ejemplos de un proyecto malo
- Un “proyecto malo” puede tomar muchas formas, como resolver problemas innecesarios, diseños complejos o motivaciones políticas
- Desde la perspectiva de UX, puede tratarse de resolver un problema inexistente o romper un flujo ya establecido
- En lo técnico, implica complejidad excesiva, mala elección de librerías o una arquitectura ineficiente
- En lo político, puede ser un proyecto impulsado por promociones o por seguir una moda
- Que un proyecto sea bueno o malo es un juicio subjetivo que suele hacerse evidente con el tiempo y no siempre está claro al inicio
- Como ejemplo en Google, hubo un proyecto en el que el equipo de plataforma intentó transferir un flujo clave de usuarios a otro equipo, y fracasó por razones políticas
- Técnicamente era excelente, pero los problemas de autoridad entre organizaciones hicieron que se desechara dos años después
- La lección fue que “la política y la precisión al definir el problema son tan importantes como la calidad técnica”
Por qué no se pueden detener todos los proyectos malos
- Las empresas de software tienen un fuerte sesgo hacia “ejecutar rápido”, por lo que plantear preocupaciones suele verse como algo que frena la velocidad
- Por eso, si no se percibe como un problema grande, es muy probable que se ignore
- Oponerse repetidamente puede hacer que a alguien lo etiqueten como una persona negativa, y los fracasos prevenidos rara vez se reconocen
- Oponerse puede afectar el ascenso de otras personas o proyectos de ejecutivos de alto nivel, por lo que existe un riesgo político
- La capacidad de atención que puede sostener un solo ingeniero es limitada, y si intenta intervenir en todo, termina volviéndose cínico
Administrar la influencia como una “cuenta bancaria”
- La influencia es un activo que se acumula con resultados y colaboración, y se retira cada vez que uno se opone
- Cheque de $5: observaciones menores al nivel de una revisión de código
- Cheque de $500: objeciones a decisiones de arquitectura o al cronograma
- Cheque de $50,000: intentar detener un proyecto impulsado por ejecutivos
- Si uno interviene repetidamente en problemas pequeños, pierde capacidad para responder a asuntos realmente grandes
- Cuando la influencia se agota, se cae en una “quiebra política”: dejan de invitarte a reuniones o ignoran tu opinión
Criterios para decidir cuándo intervenir
- Validar la propia experiencia: confirmar si el juicio de uno tiene fundamentos suficientes
- Reconocer los límites de hablar: expresar una opinión no es una “orden”, sino “compartir una perspectiva”
- Tres factores de evaluación
- Cercanía (Proximity): cuanto más cerca esté de tu equipo, menor es el costo de intervenir
- Impacto en el equipo (Team Impact): si el fracaso causará daño directo al equipo, vale más la pena intervenir
- Escala de la empresa (Company Scale): si el fracaso tendrá un gran impacto en toda la organización, hace falta intervenir
Formas de responder ante un proyecto malo
- Intervención directa: pedir que se detenga el proyecto o presentar un documento sólido de preocupaciones
- Requiere convicción y disposición a asumir riesgos
- Intervención parcial: ajustar la dirección del diseño o encaminarlo hacia una mejor solución
- Si se aborda con una actitud colaborativa, es posible que te vean como “alguien que ayuda”
- No intervenir: cuando, por inercia política o por límites de influencia, intervenir aporta poco valor
- Si el equipo está relacionado, conviene preparar medidas de mitigación, como reducir dependencias o construir alternativas
- Si no está relacionado, observar en silencio y compartir la opinión solo internamente
- Gestión del equipo: compartir la realidad con honestidad, pero sin entrar en detalles políticos innecesarios
Conclusión
- La idea clave es que “tener la razón y ser efectivo no son lo mismo”
- En las grandes empresas, la política y el contexto pesan más que la lógica, y no todos los errores pueden corregirse
- Hay que usar estratégicamente la influencia y la confianza para enfocarse en los momentos donde sí puede lograrse un cambio real
- En los demás casos, conviene compartirlo con colegas, prepararse y aprender observando
- Aunque no se pueda resolver todo a la perfección, este enfoque es una forma sostenible de actuar
1 comentarios
Opiniones de Hacker News
Me acordé de que una vez un manager dijo: “a veces hay que dejar que la gente fracase”
Se iba demasiada energía en seguir cargando con ciertas personas. Esperaba que algún día aprendieran a nadar solas, pero a veces ese esfuerzo era mejor invertirlo en otro lado
Hubo un proyecto que avanzó sin mi participación, pero sin mi conocimiento jamás podía tener éxito. Ese equipo era tan deficiente que mezclaba preguntas con el trabajo como si fuera parte del proceso
Encima, cuando me enteré de que la dirección menospreciaba a mi equipo y los elogiaba a ellos, me sentí realmente humillado. Su implementación era terrible
A algunos managers no les gusta que les digan que su idea no va a funcionar. Si les llevas la contraria, terminas señalado como la causa del fracaso
Así que dejo que el trabajo avance, pero les comparto el estado con frecuencia. De ese modo ven por sí mismos el fracaso que se venía venir, y me separa a mí del fracaso
El fracaso personal cuesta poco y tiene valor educativo. A veces hasta pasa que su enfoque sí funciona, y la organización gana un nuevo activo de conocimiento
Puede que fracasen y no aprendan nada. Pero si hiciste todo lo posible, al menos te queda la tranquilidad de conciencia
Que un proyecto sea “malo” es algo subjetivo durante la mayor parte de su ciclo de vida
Una vez hubo gente externa que se opuso a un proyecto e intentó frenarlo, pero al final salió y fue un éxito, y su credibilidad quedó dañada
Hay que cuidar bien en qué te gastas la reputación
Ya sé que el mundo no siempre está lleno de sol y arcoíris, pero aun así en ese momento fue realmente decepcionante
Como dice el dicho, “no es mi mono, no es mi circo”, así que no me meto en cosas que no son mi responsabilidad
Incluso cuando trabajaba como arquitecto, no daba consejos innecesarios sobre UI o lógica de negocio si no eran mi área
Si era algo decidido por managers de arriba, simplemente lo seguía. También mantengo ese principio como consultor
Solo intervengo con cuidado dentro de mi especialidad. Y eso, solo cuando hay aprobación del C-suite
Este consejo aplica bastante bien en empresas pequeñas y medianas. Pero en una empresa grande, oponerte a un proyecto casi no sirve de nada
Si sale bien, quedas como tonto; y si sale mal, nadie lo recuerda
El verdadero ROI aparece cuando ofreces la solución después del fracaso. A la gente le encantan los “solucionadores de problemas”
Una vez propuse pruebas E2E automatizadas y me rechazaron, pero cuando después todo explotó, saqué ese framework y me trataron como héroe
A veces parece más sensato quedarse en un cargo más bajo y vivir sin ese estrés
En cambio, en una empresa grande se desperdician años y millones de dólares por culpa de la política
Yo soy de la postura de que “no hay que ignorar los problemas”
Si estás en posición de ayudar, aunque sea en voz baja deberías proponer otro enfoque. No hace falta reaccionar emocionalmente
En una organización pequeña, una buena idea se incorpora con facilidad, pero en una grande el riesgo político es mucho mayor
En la práctica, es más probable perder reputación que lograr ayudar de verdad. Por eso importa elegir bien qué batallas pelear
Pero en una organización grande, cambiar un proyecto que ya está en marcha requiere una cantidad enorme de tiempo y energía
En realidad, muchas veces no podemos controlar ese proyecto. Un título más preciso sería: “no sabemos por qué otro equipo hace las cosas así”
El profesionalismo consiste en hablar cuando hay que hablar. Pero por experiencia, casi nunca cambia nada
Justo ahora estoy viendo una situación así en la práctica
El dueño del negocio eligió una plataforma low-code por costo y velocidad, pero al final hizo falta una personalización gigantesca al nivel de puro hack
Mi equipo despliega varias veces al día con TypeScript, mientras que ese equipo despliega una vez al mes y anda haciendo cosas raras con curl
Este consejo es excelente dentro de la realidad política de Big Tech, pero al final se parece a una especie de pacifismo corporativo
En otros entornos no hay margen para quemar dinero y motivación de esa manera
(Aun así, Lalit logra condensar muy bien una dinámica organizacional compleja en un texto corto)
La persona que se la pasa señalando problemas termina marcada como alguien negativo
Al final, el consejo clave es guardar la energía para los momentos importantes. No todos los problemas definen la supervivencia de la empresa
Un ingeniero no tiene autoridad para “dejar que fracase” un proyecto políticamente malo
Esa es responsabilidad de la dirección. El ingeniero solo tiene que dar asesoría técnica
Pero entender estas dinámicas sí importa para que no afecten tu carrera
Las peleas territoriales entre el equipo de producto y el de plataforma vienen de la falta de liderazgo claro
Si te preguntas por qué esto pasa tan seguido, vale la pena ver este post sobre Google
Esta manera de pensar es común en organizaciones grandes, especialmente en instituciones gubernamentales
Los costos los paga otro departamento, y el poder se mide por la cantidad de personas bajo gestión
Para evitar esta necrosis organizacional, los líderes tienen que establecer métricas claras y sistemas de prevención
Ignorar el capital político no hace que desaparezca
Es una muy buena analogía
Si construyes liderazgo y confianza, se crea el espacio para decir “estás equivocado”
Pero la razón por la que los líderes no siempre confían en los ingenieros es que, a veces, los ingenieros se equivocan
Los ingenieros son muy buenos para encontrar fallas, pero no tanto para entender el contexto de negocio
Por eso, incluso una “idea que parece estúpida” hay que juzgarla después de entender su contexto
Cuando puedes distinguir entre una idea que de verdad hay que matar y una idea que simplemente tiene defectos, te ganas la confianza dentro de la organización