Eres desarrollador, has entrado en una empresa donde te muestran un trozo de código y te comentan algunas tareas de cómo implementar ideas no muy claras a alto nivel pero muy bien detalladas a bajo nivel. Se espera el trabajo entregado en una fecha predeterminada, no hay margen de cambio, ¿te suena esta historia?
Como decía, tu supervisor contacta contigo. Una reunión improvisada delante de una hoja de cálculo para revisar algunas ideas. Es tu primer día en la empresa pero no como desarrollador, tienes interés por aprender lo antes posible y lanzarte a proporcionar valor a la empresa. En la hoja de cálculo aparecen tareas muy concretas. Realmente son tareas a muy bajo nivel, muy pequeñas y sin dar idea alguna de a qué parte del puzzle pertenecen.
La primera conversación gira en torno a cómo implementar esas tareas. Son muy sencillas y alguien con tu experiencia no debería tener problemas en realizarlas en una o dos horas. ¡A ello! ¿Pero y la charla sobre cómo funciona el sistema? ¿qué hacen exactamente estos cambios? ¿qué requisitos complacen? ¿cuál es la historia de usuario ligada? ¿existe algún hito relacionado? y mucho más importante, ¿por qué se decidió hacer de esta forma?
Hemos topado con un supervisor que adora la microdirección o el micromanagement. El trabajo se basará en la premisa de falta de transparencia, tendremos pleno desconocimiento de la plataforma y trabajaremos como animal de carga con anteojeras. También suele asociarse a una falta de libertad. Los supervisores controlan al mínimo detalle qué se hace y cómo se hace además de controlar más a los empleados que las tareas. Steve Jobs decía, muy en relación con este tipo de prácticas:
No tiene sentido contratar a personas inteligentes y después decirles lo que tienen que hacer. Nosotros contratamos a personas inteligentes para que nos digan qué tenemos que hacer.
Warren Buffet también decía acerca del mismo tema:
Puedes contratar gente buena y dejarles trabajar o puedes contratar gente barata y decirles lo que tienen que hacer.
Además, estos supervisores tienden a irritarse cuando un paso no es seguido según sus directrices, o el desarrollador toma una decisión sin su consulta. Aunque sea buena. El problema para este tipo de supervisores es la cadena de mando. No importa si tienes o no razón. Nicolás del canal de Youtube HolaMundo también habla de estos temas y acuñó el nombre jefe gaviota a este tipo de jefes tóxicos que podemos encontrar. Obviamente, puedes tener un jefe gaviota sin necesidad de que haga microdirección, no obstante sí es muy probable que un jefe que te microdirija sea además un jefe gaviota.
El problema con tener este tipo de relaciones laborales es principalmente tener la sensación de menosprecio, una desvinculación completa de la empresa al trabajar para ellos pero no con ellos y la inutilidad del trabajo realizado, sobre todo si terminamos escribiendo una y otra vez correcciones de código sobre decisiones con las que no estamos muy conformes y que finalmente terminan mostrando lo que ya avanzábamos.
Es normal ver cómo muchos desarrolladores terminan abandonando empresas e incluso tomando otras opciones con menores beneficios sociales o económicos con tal de sentir que pertenecen a una empresa, creando un proyecto apasionante y teniendo voz y voto en las decisiones de la misma. Tan solo permitir al desarrollador conocer la empresa, los productos en los que está involucrado e incluso poder emplearlos a nivel de usuario (si es posible) ya constituye una fidelización en sí misma.
En nuestra historia, nuestro desarrollador que está siendo vigilado de cerca sobre cada una de sus tareas, presionado para obtener cada una de esas tareas en un plazo de tiempo impuesto y dirigido para implementarlas siguiendo unas indicaciones de cómo hacerlo solo tiene dos opciones:
-
Puede seguir trabajando en esta empresa aceptando las órdenes, sin necesidad de pensar en qué está haciendo, sin importarle mucho si su trabajo es bueno o malo y recibiendo su salario a fin de mes.
-
Puede abandonar la empresa y buscar otro proyecto de empresa donde la cultura, valores y forma de trabajo se alineen más a emplear no solo su destreza como programador, sino también sus destrezas como desarrollador y su conocimiento de productos similares que haya empleado.
¿Qué opción elegirías tú? ¡Déjanos un comentario!