Engineering Momentum: la fuerza silenciosa que condiciona el cambio
El reto, en ingeniería, no siempre es tecnológico, sino la resistencia natural al cambio que tienen los equipos.
Las últimas semanas están siendo muy interesantes, porque están empezando a encajar muchas ideas que llevaba tiempo rumiando. Cuando uno está metido en el día a día —apagando fuegos, resolviendo dependencias, empujando proyectos, tomando decisiones rápidas—, rara vez levanta la vista para observar el sistema en su conjunto. Pero cuando te permites hacerlo, cuando analizas con cierta distancia, empiezas a ver problemas que siempre estuvieron ahí… solo que no tenías nombre para ellos. Con esto de escribir Crafting Platform, uno se tiene que parar a pensar y analizar bien lo que va a escribir. Y empiezan a aparecer patrones.
Uno de esos problemas me ha acompañado en todos los equipos donde he trabajado y aparece cada vez que intentas introducir una práctica nueva en un equipo de ingeniería: una plataforma, un modelo de QA, una cultura DevOps o cualquier cambio profundo en la forma de trabajar.
Yo lo voy a a llamar resistencia al cambio causado por el Engineering Momentum. Otros autores se pueden referir a algo parecido como fricción o arrastre, pero creo que eso tiene una connotación más cultural que lo que voy a tratar hoy.
El paralelismo con la física
En física, el momento (o cantidad de movimiento) es proporcional a la masa y la velocidad de un objeto .
Un tráiler cargado a 90 km/h tiene mucho momento: no puedes girar 90° de golpe sin que el vehículo intente seguir recto, y de cuatro vueltas de campana. Para cambiar su dirección, a esa velocidad, necesita aplicar una fuerza suave, pero constante, en la dirección a la que quieres ir, y durante más tiempo.
En los equipos de ingeniería pasa exactamente lo mismo.
Los equipos de desarrollo tienen una masa:
personas
hábitos adquiridos
procesos heredados
herramientas legadas
stack tecnológico
interdependencias entre equipos
decisiones históricas que nadie recuerda del todo
Y tienen también una velocidad:
roadmap agresivo
deadlines
presión de negocio
promesas hechas
carga operativa
Cuanto mayor es la masa y la velocidad, mayor es el momento del equipo. Y, por tanto, más difícil es cambiar su trayectoria.
Esto no es una mera metáfora simpática. Es exactamente lo que sucede con cualquier transformación, concretamente en equipos de ingeniería.
Ignorando el problema subyacente
Aquí es donde muchos equipos de plataforma ―y muchas iniciativas de mejora― se estrellan. Se asume que, si la solución es buena, la adopción llegará por sí sola. Pero se está ignorando el momento del equipo. La dificultad intrínseca de cambiar su trayectoria.
En la práctica, nunca partes de una pizarra en blanco sobre la que diseñar una plataforma ideal. Siempre hay un ecosistema legado y enredado de sistemas, expectativas, procesos y rutinas. Y precisamente los problemas en ese ecosistema son los que motivaron a crear la plataforma en primer lugar. Para simplificar, para estandarizar… Por lo tanto, no se puede empezar a desarrollar una plataforma ignorando esos problemas y prometiendo que se solucionarán cuando, mágicamente, todo se migre a la plataforma.
Una plataforma introduce fricción organizacional, aunque esté perfectamente diseñada.
Da igual lo buena que sea la plataforma. Si exige esfuerzo en un momento de alta carga, el equipo que tiene que adoptarla ofrecerá resistencia.
Y a veces esa resistencia ni siquiera es consciente. Es cultural. Es fricción. Es el propio momento del equipo.
La fuerza correctiva
He experimentado este problema varias veces. Y visto con perspectiva, es uno de los desafíos más complejos y fascinantes del trabajo de plataforma. Puede llegar a ser incluso más agradecido y reconfortante que el propio reto tecnológico.
Porque una plataforma va a cambiar la forma en que trabajan los equipos. Introduce nuevos flujos, nuevas herramientas, nuevas reglas. Y eso afecta a la velocidad, al esfuerzo mental y a la seguridad psicológica de los equipos. No es extraño que aparezca lo que algunos llaman change fatigue (cansancio acumulado ante cambios constantes).
Por eso no puedes desaparecer durante un año, construir “la plataforma ideal” y volver diciendo: “Ya podéis migrar”. Si en un mes no estás dando soluciones, tu mánager puede invitarte a salir por la misma puerta por la que entraste. La inversión en el equipo de plataforma no tiene sentido.
La plataforma debe nacer acompañando, no imponiendo.
Tenemos que empezar ayudando en los problemas actuales, incluso si “no son de plataforma”. Tenemos que ganar credibilidad resolviendo fricción real. A medida que esa credibilidad crece, podemos aplicar esa “fuerza suave pero constante”:
guía
empatía
documentación clara
ejemplos
golden paths
soporte humano
colaboración
pequeños wins
Poco a poco, el momento del equipo cede. La trayectoria empieza a cambiar. Y el cambio deja de sentirse como una obligación para convertirse en una mejora evidente.
Escuchar, respetar, acompañar
Hay que escuchar más que imponer.
Hay que respetar su carga antes de pedirles un esfuerzo.
Hay que demostrar valor antes de exigir adopción.
Los equipos de plataforma no somos los policías de los procesos de ingeniería. Ni dictadores que imponen ideales. Somos socios estratégicos.
Y con el tiempo, esa combinación de respeto, constancia y colaboración tiene un efecto inevitable. El momento del equipo de ingeniería deja de ser una barrera y se convierte en energía que empuja en la misma dirección.
Cuando eso ocurre, todo empieza a fluir.
¡Muchas gracias por leerme!


