19/07/2018Artículo original
Tras muchos años trabajando en empresas de software, he llegado a la conclusión de que hay dos departamentos que luchan por la hegemonía en la empresa: programación y ventas.
La gestión de estos departamentos es complicada, tanto por los CEO’s a nivel global, como por los mandos intermedios responsables de cada uno de ellos.
La gestión de perfiles de ventas: todo por la pasta
Profesionalmente siempre he estado ligado a empresas tecnológicas de desarrollo de software pero nunca he gestionado a un equipo de programadores, aunque sí he tenido mucha relación directa con ellos. Mi ámbito siempre ha sido el de las ventas, el marketing y la comunicación en los que sí he tenido personas a mi cargo.
En las reuniones con los responsables de otros departamentos tienes la oportunidad de saber qué es “lo que se cuece” en cada uno de ellos, y en muchas ocasiones servimos los unos de paño de lágrimas de los otros ya que es un foro donde los mandos intermedios podemos desahogarnos y decir lo que está pasando en nuestros departamentos en busca de consejo en algunos casos, y como terapia de grupo la mayoría de las veces.
En los departamentos de venta los motivos de despido son en el 90% de los casos muy claros. El comercial no llega al objetivo de venta. Por lo general los buenos comerciales tienen mucho ego, tienen la necesidad de sentirse importantes y les gusta que se les reconozca no solo económicamente su valor, sino públicamente y de manera expresa en reuniones, cenas, eventos y demás contextos en grupo. Las empresas toleran estoicamente el comportamiento individualista y narcisista de sus comerciales y ejecutivos de cuentas bajo una sola condición muy fácil de medir: superar el objetivo de ventas, sí, la facturación obtenida de conseguir nuevos clientes. Vamos, que si un comercial tiene una conducta algo excéntrica y especial se le permite siempre y cuando sea capaz de vender mucho. He visto como juntas directivas enteras y dueños de empresas más pequeñas han pasado por alto conductas que a otros miembros de la empresa les hubiera costado más que una reprimenda.
Como gestor de personas que se dedican a la venta tienes que saber cómo llevar esas situaciones sin que la situación llegue a mayores o afecte a otras personas de tu equipo, y sin que tampoco trascienda el ámbito del departamento. Con algunos perfiles comerciales ese trabajo desgasta mucho a nivel emocional.
La gestión de perfiles de programación: un caso real
En los departamentos de programación, la gestión de las personas es totalmente diferente a pesar de los paralelismos que hay entre los buenos profesionales de la venta y los buenos desarrolladores; porque al fin y al cabo, somos todos personas y nos parecemos mucho entre nosotros.
La capacidad de tolerancia del ego, la ambición y el individualismo es completamente diferente en función de si gestionas comerciales o programadores.
Voy a contar una historia que viví en una de las empresas en las que trabajé con nombres ficticios y sin entrar en detalles que atenten contra la privacidad.
Mi compañero “Javier” acababa de ser ascendido a responsable del departamento de programación de la empresa. El departamento estaba compuesto por varios ingenieros de software y perfiles técnicos de programación, creo recordar que eran unas 10 diez personas en total.
En el equipo había un programador muy curioso (“Álex”), ávido de conocimiento y que era un especialista en buscar soluciones creativas a los problemas de desarrollo. Javier y Álex tenían una buena relación y Javier tenía en alta estima las habilidades técnicas de Álex y su forma de enfocar las tareas de programación, ya que en este ámbito aportaba mucho a la empresa y al departamento.
Pero Álex tenía la costumbre de criticar las políticas de empresa, desde los sueldos y los “extras” hasta la política de recursos humanos, y muchas veces ponía sus quejas por escrito enviando interminables correos electrónicos al CEO de la empresa. Álex además tenía algunos problemas con sus compañeros porque su actitud era de “programador estrella”, y no solo criticaba a sus compañeros programadores, también cargaba contra los arquitectos y los diseñadores de UX del software. Javier lo veía como algo positivo ya que para él era bueno tener personas con espíritu crítico en el equipo.
Un buen día Javier recibió la llamada del jefe de tecnología de la empresa (su jefe directo) y le encomendaron la misión de directamente “cargarse” a Álex. Con solo el apoyo del recién llegado Javier y un par de compañeros del equipo, las continuas quejas habían colmado el vaso. Al parecer las quejas de Álex estaban consumiendo la paciencia de la dirección y habían decidido ponerle fin a este monólogo: le pidieron a Javier que tenía que despedirlo.
Javier se puso en contacto con el departamento de recursos humanos y le dijeron que, como responsable directo, era su obligación despedirlo aunque no tuviera muchas ganas de hacerlo. Javier no llevaba ni seis meses en el cargo y era la primera vez que iba a despedir a alguien.
Pasaron varios días, la presión desde dirección era cada vez mayor. Javier, como buen mando intermedio recién nombrado llamó a Álex a su oficina y le despidió, con el guión que le habían preparado desde recursos humanos.
Álex salió de la empresa algo deprimido y contrariado pues nunca se esperaba ser despedido por enviar emails a dirección. Pero fueron un cúmulo de circunstancias las que desembocaron en su despido.
¿Por qué se despide a un programador?
Recientemente pensando en esta historia, me pregunté a mi mismo ¿Por qué motivos se suele despedir a un programador o a un ingeniero de software?
Creo que es una buena pregunta porque, desde mi experiencia, existen miles de razones por las que despedir a cualquier tipo de empleado, y también hay miles de razones por las cuales los mandos evitan despedir a empleados que sí deberían despedir.
Sin embargo, para desarrolladores de software e ingenieros, siempre hay un conjunto de motivos que destacan sobre el resto. Al igual que a un comercial se le despide por no llegar a la cifra de venta, o por tratar mal a un cliente o quitarle cuentas a sus compañeros, los programadores tienen sus propios motivos de despido “tipo”.
En algunas empresas de software la relación entre los perfiles técnicos y el personal no técnico no son todo lo fluidas que deberían ser y en ocasiones se tensan tanto que se van a la quiebra. Yo soy un perfil no-técnico y con este artículo pretendo humildemente contribuir a que los nuevos equipos humanos en empresas de software se entiendan un poco mejor.
Pero antes…
Un consejo para perfiles no técnicos
Para aquellos miembros no-técnicos del equipo como lo soy yo, entender cómo a veces se les “etiqueta” a los desarrolladores y otros pequeños puntos débiles comunes que suelen tener puede resultar de gran ayuda. Por ejemplo, en ocasiones a los programadores les cuesta cumplir con los plazos por muchas razones perfectamente válidas y razonables. Muchas veces se desconoce realmente la dificultad o los retos que presenta el problema que tienen enfrente. Pero como ingenieros de software y programadores que son, buscan la perfección y a menudo les cuesta reconocer cuando decir basta, ya que siempre hay margen de mejora cuando te sientas a programar un sistema.
Los no-técnicos tenemos que entender que esa es la naturaleza de los perfiles técnicos que son buenos en su trabajo. Si como perfil no-técnico aprendes a llevar bien esta necesidad de “mejora continua” y no verlo como que están rehuyendo de sus responsabilidades en relación con los plazos, verás que se te va a dar mucho mejor trabajar con tus compañeros técnicos.
Un consejo para perfiles técnicos
Para los perfiles técnicos, que en esta web sois mayoría, y, obviando el hecho de que estoy generalizando, espero que estas palabras sirvan para que tengáis información sobre cómo vuestras conductas y personalidades son percibidas por terceros. Por ejemplo, si sabes que lo que está pidiendo el cliente no es lo que realmente necesita y no lo sabes transmitir con buenas palabras, o si le dices a tus compañeros de trabajo que son idiotas por no ver algo muy obvio, aunque tengas razón, vas a quedar de engreído y lo único que vas a conseguir es enfadar a todo el mundo.
Si caes en este tipo de comportamiento de forma habitual, tenlo claro: te van a despedir. Elige tus batallas, y aprende cómo venderles a los demás tus brillantes ideas. Pero no te limites a simplemente decirles a los demás que están equivocados. Averigua lo que quieren en realidad, lo que necesitan, y busca un camino que te lleve a ello. Al final les podrás convencer y te entenderán mucho mejor, y estarán de acuerdo contigo al completo. Te convertirás así en un activo útil y no en un abusón incomprendido.
He visto cómo despedían a varios perfiles técnicos, ya fueran programadores o jefes de programación. Si quitas las causas objetivas de despido tipo por robar o por mentir en los CV, y quitas también los casos en los que la empresa se ha equivocado de candidato, cuando no se verifican las referencias o el proceso selección se hace sin el debido rigor, se limita bastante el número de causas por las cuales un perfil técnico es despedido, y se pueden resumir en las siguientes categorías:
Principales causas de despido de desarrolladores
- Incapacidad de cumplir compromisos. Muchos programadores son incapaces de parar o de limitar el alcance de su trabajo, y siempre buscan la solución perfecta. Cuando esto hace que todo el mundo o el proyecto en su conjunto se retrase de forma repetida, termina en despido. Más de un proyecto sólido de software ha fracasado por la incapacidad/imposibilidad de despedir a este tipo de programador, que en muchos casos era el CTO fundador.
- Incapacidad de trabajar en equipo por ego: hay algunos desarrolladores que no entienden que los días del programador “vaquero solitario” han terminado. La mayoría de los proyectos hoy en día exigen trabajo en equipo y la colaboración interdepartamental. Aquellos que no sean capaces de trabajar en equipo porque “saben mejor que nadie” lo que hay que hacer sencillamente tienen sus días contados en las empresas. Esto no tiene nada que ver con aquellos programadores que sí ponen toda la buena voluntad del mundo a la hora de trabajar en equipos pero que carecen de habilidades de comunicación o de empatía. Cualquier buen responsable de departamento puede gestionar a este perfil, pero los perfiles con mucho ego y narcisistas es mucho más complicado.
- Incapacidad de trabajar en un producto por ego: a veces un desarrollador de software discuten con clientes o con los diseñadores del producto pensando que sabe más y mejor que los clientes o que los diseñadores de producto lo que hay que hacer, y no hacen lo que se les pide, o lo hacen a regañadientes. Y luego todos los demás son idiotas porque la funcionalidad que ellos proponían y que ya habían diseñado es claramente superior: ¡despedido!.
- Misoginia: esto no es muy popular decirlo, pero existe cierto sentimiento despectivo hacia las mujeres en la profesión de desarrolladores de software. ¿Por qué? Los motivos son varios y recientemente tratamos en este blog las estadísticas de mujeres en programación y las cosas no pintan bien. Al margen de los motivos, un buen líder en una empresa o un departamento no tolera conductas en este sentido, y en especial cuando van dirigidas en contra de una clase entera de compañeras por su género. Al final este tipo de conductas son inadmisibles por muy buen programador que sea. Si no lo despide el responsable del departamento, lo normal es que RRHH despida tanto al responsable del departamento como al programador que incurre en comportamientos discriminatorios. La empresa no se puede permitir esa actitud bajo ningún concepto, caiga quien caiga.
- Incapacidad de estar al día: cuando se programa software, las herramientas de desarrollo evolucionan relativamente rápido. Un desarrollador hoy en día utiliza más de un lenguaje, entorno y plataforma. Es bueno tener una base sólida en un lenguaje, pero también lo es tener la capacidad de aprender aquellas tecnologías que pueden ser útiles para empresa y no quedarse anclado. La clave es saber cuándo es el momento, y no caer en modas pasajeras. Si vas a arrancar con un proyecto y exige nuevas tecnologías por motivos de calidad y de mantenimiento, o simplemente sabes que tu empresa va a contratar personal mejor cualificado, lo mejor es que te actualices. Si no estás dispuesto a estar al día de forma sensata sin caer en modas, lo más probable es que te despidan.
- Introducir nuevas herramientas en la empresa sin consentimiento: una variante del punto anterior es el caso de aquellos programadores que introducen en la empresa nuevas tecnologías a escondidas en contra del criterio de la empresa. Es muy común querer hacerlo, pero es algo que en términos de política de empresa está muy mal visto aunque al final resulte que técnicamente se tenga razón.
- Fomentar el mal ambiente por frustración: si un responsable de departamento escucha decir “sí, claro, lo que quieras jefe” en tono sarcástico, ya saben de antemano no solo que no se van a cumplir los plazos de desarrollo, sino que encima el software va a ir incompleto y de mala calidad. ¿Cómo lo sabe? Porque si hay discrepancias en torno al diseño del producto, conjunto de funcionalidades, etc. y eso significa que hay miembro del equipo que no está remando en la misma dirección y que encima se cree que sabe más de lo que realmente sabe. La inmadurez y el comportamiento poco profesional no forjan buenos equipos de trabajo. En empresas de programación este motivo de despido es muy común.
- Código de mala calidad: si alguien sigue metiendo bugs y no hace pruebas con la diligencia debida, el coste de tenerlo en la empresa se vuelve demasiado alto en muy poco tiempo. Sobre todo si sus errores los encuentra el cliente a modo de fallos en el software. Incluso si el equipo de desarrollo no asume el coste del servicio de soporte, sí lo hace la empresa y al final el equipo paga los platos rotos y pierde la confianza del resto de la empresa.
Hay otras razones específicas que causan el despido de un programador, pero yo diría que estas son las más comunes, al menos en mi experiencia, quitando la de una mala contratación por parte de RRHH.
Habiendo dicho todo esto, liderar equipos de desarrollo de software es una tarea complicada y exige empatía, flexibilidad y una dosis de creatividad, de una forma especial y distinta a la gestión de otro tipo de equipos de trabajo. Por esta razón, los malos jefes también son un motivo muy común en el despido de los programadores. He visto salir a grandes técnicos de empresas de programación por motivos ridículos y todo ello por culpa de una pésima gestión. Entremos a valorar los más comunes despidos de este tipo.
Despidos por culpa de la mala gestión
- Incapacidad de gestionar a los “pesimistas”: hay muchos perfiles técnicos que siempre ven el lado negativo y que se han entrenado para identificar problemas y puntos críticos. Este tipo de programadores son muy valiosos y es responsabilidad del jefe tirar de ellos y obtener información sobre lo que sí va a funcionar o sobre cómo arreglar las cosas para que sí funcionen y sacarles del estado “esto nunca va a funcionar” en el que están instalados. Hay algunos responsables de departamento que no saben gestionar esto o que no saben “tirar” del equipo, así que optan por despedir al negativo.
- Usar las medidas equivocadas: algunos gestores que vienen de otros sectores buscan métricas y objetivos sencillos para medir el rendimiento. En una de las empresas en las que trabajé con una programadora que escribía menos líneas de código que el resto, y el jefe se creía que producía menos que el resto. ¡Y quería despedirla! En esa ocasión fue la propia programadora la que se fue a una empresa mejor.
- Ego o narcisismo por parte del responsable: a los desarrolladores de software hay que dejarles seguir su propio camino de vez en cuando, y hay que saber qué momentos son buenos para que lo hagan. Si un responsable de departamento va siempre de que sabe más y no es capaz de aprender de su equipo, habrá conflictos graves y despidos a la vista. La gestión de equipos de software requiere mucha capacidad de escucha y la capacidad de saber rectificar y cambiar de opinión.
- Centrarse en el cómo y no el qué: algunos jefes de programación se centran mucho más en cómo se hacen las cosas que en qué se está haciendo. Se pierde visión y se incurre en micro-gestión de la mala, ya que le resta criterio y conocimiento al equipo de desarrollo y los transforma en programadores de libro. Conflictos y cartas de despido a la vista.
- Incapacidad de interpretar y traducir: le corresponde a los responsables de proyecto y de desarrollo interpretar y traducir las necesidades empresariales al equipo, y a la inversa, traducir las posibilidades reales de programación y sus tiempos a la empresa. Muchas veces, cuando el responsable no es capaz de hacer esto bien, se instala el caos. ¿Quién paga los platos rotos? Normalmente el programador más vulnerable y no el responsable.
Hay más motivos y podría escribir otras tres mil palabras sobre el tema, pero ahora te dejo a ti. ¡Cuéntanos tu historia en la zona de comentarios!
