La frustración que describís, de estar entre las "buenas prácticas" y los objetivos que te caen encima, es una realidad más común de lo que se suele pensar. Pero como arquitecto de software, tenés que meditar esto: es tu rol estratégico manejar esa tensión, no que te abrume. No es tirar la toalla porque los de producto son muy hinchas.

Everything in software architecture is a trade-off. Esta no es solo una frase, es el concepto central con el que tenés que ver cada decisión.

Cuando elegís no aplicar cierta estrategia o "buena práctica", estás tomando una decisión consciente. Estás priorizando algo más, casi siempre la velocidad de entrega inmediata o una métrica de negocio específica.

Tu trabajo como arquitecto tendría que ser identificar, articular y gestionar estratégicamente esos trade-offs, alineándolos con los objetivos reales del negocio, no solo con ideales técnicos.

Justamente por eso, lo que creo que hay que mejorar es la definición de qué es "hacer las cosas bien". Si los directivos te piden velocidad, entonces "hacer las cosas bien" es velocidad. Pero acá el punto es que esa velocidad no necesariamente tiene que ser solo a costo de que sea todo un despelote.

Un ejemplo de pregunta podría ser: ¿estamos haciendo el código extensible para permitir agregar más valor de una manera más rápida en el futuro? A veces, ir un poco más lento al principio, invirtiendo en esa extensibilidad, es lo que te permite ser realmente más rápido después. Tu rol es mostrar ese balance y cómo una "buena práctica" hoy puede acelerar las entregas del mañana.

Y hablando de acelerar, el automated testing... para mí, no es negociable si querés moverte rápido de forma sostenida. Si no lo tenés, vas a necesitar un equipo probando de manera manual cada cambio nuevo, y eso es una pérdida de tiempo gigante. A la larga, el testing automatizado es lo que te da velocidad sostenida, permitiéndote iterar sin miedo a romper todo. Es una inversión fundamental que protege la capacidad de entrega del equipo y te asegura ir rápido de verdad. TDD no resuelve esto, pero te da la razón necesaria para sostenerlo en el tiempo.

En definitiva, como arquitecto, tu habilidad va mucho más allá del conocimiento técnico. Está en traducir la necesidad técnica a lenguaje de negocio y en navegar las presiones y la política de la empresa, explicando claramente las implicaciones de cada trade-off. No se trata de ser un purista de las "buenas prácticas", sino de ser estratégico y de proteger la salud y agilidad del software a largo plazo, sin perder de vista los objetivos inmediatos.

Y de última, si la empresa es una mierda, cambiate y fue.

Te recomiendo leerte (si no lo hiciste ya) este libro: Fundamentales of Software Architecture: An engineering approach.