Cómo convencí al CEO para que despidiera a su amigo
Hace años entré en una empresa y me pusieron a trabajar en un proyecto donde mi compañero, era amigo del dueño de la empresa.
Las primeras semanas trabajé solo.
El dueño me dijo que como mi compañero iba a una velocidad de crucero, mejor dejarle avanzar mucho solo. Ya cuando yo alcanzara su velocidad, trabajaríamos juntos.
Sí, te juro que esto me lo han dicho.
Bien, pues ese día llegó y empecé a trabajar junto al yate ultrarápido. Solo que resultó ser el barco de Chanquete (si no eres de España, un barquito pesquero) y además el código que dejaba era chapapote.
El dueño no tardó en darse cuenta y acabé revisando todo lo que hacía.
Como persona era increíblemente bueno y todo corazón, pero como desarrollador todo lo contrario. Muy mala actitud, sin ganas de mejorar y justificando todo lo que hacía.
Estar a cargo de una persona así, donde tu día es prácticamente recoger todas las mierdas que va dejando y apagando todos los incendios que va provocando, acaba por quemar.
Y me quemé.
No será porque no intenté que mejorara. Hice pair programing con él y posiblemente sea la persona a la que más tiempo he dedicado, pero todo tiene un límite.
Al final llegué a la conclusión que el código no era lo suyo.
Me tocaba ser claro con el dueño y le convencí de que no podía seguir en el proyecto.
Bueno, no lo despidió realmente, lo reubicó en tareas alejadas del código, algo que no le importó y confirmó mi teoría.
¿Cómo le convencí?
Seguro que en tu trabajo has tratado de convencer a tus jefes de alguna cosa sin mucho éxito.
No es porque tus propuestas no sean buenas. Simplemente, te estás olvidando de lo más importante.
Las personas no queremos hacer cosas, y mucho menos despedir a un amigo.
Lo importante es entender como funciona el cerebro.
Por ejemplo: nadie quiere entrenar, queremos haber entrenado. Nadie quiere leer, queremos haber leído.
Las personas nos movilizamos cuando pensamos que haciendo tal cosa vamos a obtener un beneficio. Nos movilizamos por el beneficio, pero no por lo que tenemos que hacer.
Por ejemplo: Nadie quiere hacer testing o refactoring, queremos los beneficios que vamos a obtener cuando ya hayamos mejorado el diseño o ya tengamos tests.
Es desde esa parte desde donde lo tienes que proponer.
Qué beneficios vamos a obtener o qué problemas vamos a dejar de tener cuando lo hagamos.
¿Qué es lo que hice?
Saque un informe de tiempos, de las tareas en las que estaba él involucrado y en las que no estaba de los últimos 6 meses.
Al día siguiente habló con él.
Tengo una newsletter principal donde cuento historias que me han pasado desarrollando software en los últimos 20 años. A veces son historias más del lado del código y otras veces del lado de la persona o del negocio.
Además, es la única forma de acceder a mis cursos sobre diseño de software, testing y saber trabajar con código legado.
Si te interesa, puedes suscribirte desde aquí:
https://xurxodev.com/#/portal/signup
Pd: Si te gustan mis emails, habla bien y comparte xurxodev.com para que otros lo disfruten.
Pd2: Si no te gustan mis emails, habla mal y comparte xurxodev.com para evitar que otros lo sufran.