He estado en más engagements de agencia de los que me gustaría contar, en ambos lados de la mesa. Los patrones de cuáles tienen éxito y cuáles fallan son casi independientes del trabajo técnico. El código es usualmente fino. Lo que varía es la forma del engagement alrededor del código — y cuatro hábitos específicos parecen hacer la diferencia, cada vez, en cada dominio.
Estos son los cuatro alrededor de los cuales construimos nuestro estudio. Ninguno es ingenioso. La mayoría son ligeramente incómodos.
Hábito uno: demo real al final de cada sprint, en una URL real
No screenshot. No video. No localhost walkthrough. Una URL que el cliente puede abrir desde el teléfono de camino a casa y romper clickeando lo equivocado.
Es el hábito más importante, y el que la mayoría de agencias sutilmente evitan. Es incómodo. La cosa no está hecha. Está áspera en los bordes. La mitad de los botones no van a ningún lado. No queremos shippearla bajo nuestro nombre.
Shipea de todos modos — en el cierre del sprint, no antes.
Hacíamos esto cada viernes. Lo dejamos. Demos semanales suenan geniales hasta que vives dentro de uno: para el miércoles el team está performance-coding para que la demo del viernes se vea bien, no construyendo lo correcto. El trabajo se dobla hacia el espectáculo. Movimos a sprints estrictos de dos semanas con la demo al final del todo, y la calidad subió en todos los frentes. La demo es el artefacto del sprint, no algo separado que el team tenga que fabricar encima del trabajo.
El end-of-sprint demo sigue haciendo las tres cosas que nada más puede. Atrapa misalignment en dos semanas en vez de un trimestre — clientes a veces no saben qué quieren hasta verlo casi-correcto. Construye hábito de terminar, en el sentido original: llevar algo al estado donde un humano puede interactuar. Y crea record inequívoco de progreso que el cliente puede mostrar a su board, sus co-founders, sus inversores.
La disciplina también fuerza al team a pensar en deployment desde semana uno. Sistemas que se deployan en cada cierre de sprint raramente tienen días de cutover de pesadilla.
Hábito dos: escribe cada decisión arquitectónica
No en Slack. Slack es para ephemera; decisiones arquitectónicas no son ephemeral. En un markdown en el repo, fechado, dueño un ingeniero, estructurado como ADR corto: qué decidimos, por qué consideramos otras opciones, qué elegimos, qué esperamos perder.
ADR = documento de una pantalla. Escribimos uno por semana al menos. Viven en docs/adr/ junto al código, y se review en el mismo PR que la implementación. Future-us está agradecido ~80% del tiempo, y debug "¿por qué hicimos esta decisión rara?" se reduce a la mitad.
La disciplina es el valor. El artefacto es side effect. Si no puedes escribir por qué hiciste un choice, no entendiste el choice — vibes-coding architecture, y pagarás.
Hábito tres: throwaway-Slack, durable-everything-else
Intercambiamos mucho context con clientes en Slack. El context es irreemplazable. Los threads no. Tratamos Slack como throwaway by design.
Si una pieza de información importa más de un día, va a algún lado durable. Decisiones a ADR. Bugs al issue tracker. Long-form feedback a PR comments. Roadmap shifts al project plan con fecha y owner.
Suena burocrático. Ahorra enorme tiempo. Mes tres del engagement, "¿dónde acordamos eso?" nunca debe resolverse a "tengo que scrollear Slack una hora". Debe resolverse a "mira el ADR, segundo párrafo".
Hábito cuatro: un ingeniero accountable por superficie
Agency teams tienen enfermedad crónica: ownership difuso. Tres ingenieros tocaron el auth system; ninguno owna. Cuando auth se rompe el sábado, on-call slack'ea "¿quién sabe auth?" y respuesta es "todos un poco, pregúntale a Jamie, no espera Jamie está de vacaciones".
Eliminar. Cada superficie significativa del sistema — auth, payments, search pipeline, deploy process, DB schema — tiene exactamente un ingeniero cuyo nombre está atado. No el único contribuidor. El que responde el ping de on-call a las 2am y el único que aprueba cambio estructural.
No es sobre silos. Es sobre accountability sin ambigüedad. Cuando Jamie de vacaciones y auth se rompe, team sabe: ping a Jamie, no decisiones hasta lunes, escalate a arquitecto si algo debe shippearse ya.
También produce mejores ingenieros. Ingenieros que ownan superficies crecen más rápido que los que pinballean. Los lifelong learners son los con responsibility profunda. Los que nunca se vuelven excelentes son los que nunca ownaron nada.
Lo que estos cuatro tienen en común
Son todos formas de reducir slack — en sentido engineering, el gap entre intención y realidad. Sin ellos, el gap se acumula silenciosamente. Con ellos, se surface semanalmente y se cierra.
Ninguno se trata de ser más smart. Se trata de ser más honesto, más seguido, por escrito, con la gente que paga. Eso resulta ser la ventaja competitiva durable de cualquier agencia operando en este espacio.
Buenas noticias para clientes evaluando: estos cuatro hábitos son fáciles de preguntar. "¿Con qué frecuencia obtenemos demo real?" "¿Dónde viven decisiones arquitectónicas?" "¿Quién owna auth?" Las respuestas te dicen todo en cinco minutos.
Buenas noticias para agencias considerando adoptarlos: compound. El primer engagement corre más difícil. El quinto se corre solo.