¿Por qué contratarías ingenieros para decirles lo que tienen que hacer?
Comentamos las razones culturales que llevan a pagar sueldos desorbitados para decirle a alguien lo que tiene que hacer.
La semana pasada publicaba comunicación efectiva con ingenieros de software, donde el aspecto clave en esa relación era que a un equipo de ingeniería no se le propone una solución, se le brinda un problema.
Un ingeniero me preguntaba por vía interna por qué cuesta tanto entender esto. ¿Por qué pagarías los sueldos que se están pagando hoy en día a los ingenieros de software para decirles lo que tienen que hacer?
En mi opinión es un tema cultural. Desde luego no se puede decir que la mayoría de sistemas educativos actuales fomenten la creatividad. A todo lo que aspiran es a crear uniformidad en las huestes de chavales que, años más tarde llegarán a la universidad para en muchos casos encontrarse más de lo mismo.
Así, muchos salimos de la facultad, en especial los propios ingenieros, con una mentalidad Taylorista del mundo. Bajo esta visión, tendemos a pensar que desarrollar software es un proceso similar a fabricar coches, en los que puedes alinear a trabajadores uno tras otro esperando a que salga un producto terminado al otro lado de la cadena de montaje.
Hablo por experiencia propia. Cuando concluí mi periodo universitario, mi visión no podía ser más mecanicista. Y así fue que cuando creé mi primera empresa hace ya 20 años, me convertí en un micromanager de manual tratando de optimizar todos los flujos de trabajo. Eso incluía redactar complejas y muy detalladas especificaciones que cualquier ingeniero sólo tenía que “picar”.
Sólo a través de la experiencia, y tras darme unas cuantas veces de bruces con la realidad, fue que empecé a entender que el desarrollo de software se parece más a pintar un cuadro o a escribir un libro que a construir un coche. En otras palabras, es más un proceso creativo/iterativo, que un proceso que se pueda industrializar.
A este condicionamiento previo por sobreoptimizar, se le une la falta de experiencia creando productos de software. En este aspecto llevamos 30 o 40 años de retraso respecto a EEUU, quienes cuentan la ventaja de haber pasado ya por el ritual taylorista y tener además casos de éxito de empresas que no han seguido estos patrones.
La parte buena es que todo esto está cambiando a pasos agigantados en forma de un sistema que se retroalimenta:
Los mejores ingenieros de producto buscan oportunidades de trabajar en equipos y empresas que les permitan trabajar en la definición de la solución.
Las mejores empresas compiten en salario y condiciones para atraer a estos ingenieros.
De esta forma, las empresas que no propicien estas condiciones, pierden a sus mejores ingenieros, lo cual les deja dos opciones: adaptarse o morir.
Mi pronóstico es que toda aquella empresa que no se adapte a los nuevos tiempos morirá. Al menos toda aquella que parta con la intención de crear producto digital competitivo, porque los ingenieros capaces de hacerlo se irán a empresas que los traten como lo que son, y no como meros peones en una cadena de montaje.
Las cadenas de montaje seguirán existiendo, probablemente en consultoras especializadas en sacar proyectos por el arte de la fuerza bruta. Las consultoras absorberán a todos esos ingenieros que no necesitan participar de la solución y están perfectamente satisfechos con implementar ciegamente lo que otro ha definido. Obviamente, la escala también es una ventaja aquí, y aquellas más potentes capaces de ofrecer mejores condiciones se llevarán a toda esta clase de ingenieros.
Si las mismas consultoras terminarán remplazando a esos mismos ingenieros por otros en países más baratos en cuánto tengan la oportunidad, ya es algo que dejo a vuestra imaginación.
🙌 ¡Comparte!
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes contribuir a que esta lista llegue a más gente compartiendo directamente en Twitter o LinkedIn.
Muchísimas gracias de antemano, Simón.