El gran muro entre management y desarrollo: pereza al comunicar

Normalmente los managers piensan que los desarrolladores no entienden su punto de vista; el de negocio y estrategia. Y viceversa. El desarrollador cree que el manager jamás entenderá su punto de vista técnico. ¿Es esto cierto y lo será forever and ever? ¿Estamos condenados a una lucha constante de intereses sin entendimiento mutuo? Si es una lucha sana donde ambas partes se comunican efectivamente y respetan de igual modo, genial. Pero si no… ¿de verdad no podemos llegar a comprendernos y colaborar sin manipulación de ninguna de las partes?

Dos bandos enfrentados en una guerra diaria

¡Cuidado! Situación tóxica: «Siempre llegamos tarde a todos los proyectos».

Tus managers tienen la firme creencia de que los desarrolladores siempre van a querer hacer lo que les dé la gana sin importarles realmente la rentabilidad de sus decisiones. Y al mismo tiempo, tienes desarrolladores a tu alrededor que creen fervientemente que sus managers solo improvisan, que toman malas decisiones una y otra vez sin contar con ellos.

Desde el punto de vista del manager, los desarrolladores solo miran por su interés en hacer las cosas con la máxima calidad y tranquilidad. No les importa el dinero, solo piden piden y piden. Son caprichosos, porque no reflexionan sobre si realizan un buen trabajo. No hacen autocrítica, solo ven los problemas fuera. Simplemente critican a los managers sin empatizar con ellos, cosa que les hace sentirse muy solos. Por ello, refuerzan su postura de jefes con poder sintiéndose por encima de ellos. «Acabo antes ordenando lo que hay que hacer». Sin explicar el por qué, eso no es relevante. «Solo haz lo que yo te diga, que no tenemos tiempo que perder».

Desde el punto de vista del desarrollador, los managers no tienen ni idea de lo que cuesta hacer las cosas. Y si además de hacerlas hay que mantenerlas, hay que pensarlas bien para que podamos evolucionar el software. Ellos venden proyectos por encima de nuestras posibilidades sin preguntarnos a nosotros si es viable. Y cuando les damos la mala noticia de que algo no es posible hacerlo en el tiempo que piden, en lugar de escuchar y aprender, se enfadan y nos aprietan más.

«Esto es insufrible». «No aguanto más». «No hay manera de entendernos».

¿Te suena?

Mentalidad jefe versus mentalidad de líder

Siendo scrum master han sido muchas las veces que he recomendado el libro de Turn the ship around. O en español, ¡Cambia el barco de rumbo!. Especialmente a roles de management. Roles que han de marcar el camino a seguir y que otros lo sigan. Este libro trata de cómo dar instrucciones a tus subordinados para tener éxito. Habla de cómo delegar, pero sobre todo habla de cómo comunicar lo que quieres que se consiga.

Conozco un patrón de comportamiento en jefes que me resulta muy curioso. La mayoría de los que he tenido el «placer» de conocer, infravaloran la comunicación efectiva. Ven el hecho de dar contexto o propósito como una pérdida de tiempo. Resulta que muchos managers han crecido con un mantra: «da la información justa a tus empleados para la tarea que han de realizar». No sé de dónde puede venir esta forma de pensar, pero realmente hace mucho mucho daño. Quizás de Frederick Taylor y sus fábricas en el 1900.

Además, se peca mucho de decir el cómo hay que hacer algo y no del qué se quiere conseguir. Siento que tiene que ver con querer llevar el control, aunque no sea necesario. Quizás es algo innato a la figura de jefe, algo instintivo en culturas mediocres. Me temo que un jefe que no es consciente de este detalle, nunca conseguirá tener un equipo comprometido. La transparencia es un valor crucial para poder trabajar colaborando, y las personas necesitamos saber por qué hacemos lo que hacemos.

También me he encontrado con jefes que parece no saber lo que quieren. Y seguramente, de nuevo,  sea porque fallan a la hora de comunicar (no cuentan toda la película). O peor, jefes que tienen un jefe superior, el cual no sabe lo que quiere, con lo que ellos van a reacción de las órdenes del jefe supremo. El hecho de no saber lo que quieres provoca que la gente que tengas a tu cargo vaya sin rumbo fijo. La responsabilidad de ese caos es tuya, querido manager. Y por cierto, tan importante es saber lo que quieres como comunicarlo bien para que se entienda. Abrirse a los empleados, contar las dificultades y pedir ayuda hará que obtengas mejores resultados.

Desarrollador prepotente

Existe otra forma de sentirse superior a los demás, y es gracias a la acumulación de conocimiento. He conocido expertos desarrolladores/arquitectos de software/diseñadores con 20 años de experiencia que hablan con el don de tener la verdad absoluta. (También he conocido a desarrolladores de 3 años de experiencia con la prepotencia de saber más que los demás, ¿eh? jeje). Para todos ellos, tener que adaptar el mensaje a roles de managers es inútil. «Nosotros solo nos entendemos entre técnicos. Hablar con managers exige demasiado esfuerzo y es una pérdida de tiempo«.

Este enfoque solo provoca rechazo absoluto en los managers, porque éstos no encuentran ayuda jamás en ellos. Son esos casos en los que management se siente «secuestrado» por los desarrolladores, y la relación se rompe. Los jefes necesitan que desarrollo empatice con ellos. Que entiendan que si toman decisiones duras es porque ya han meditado muchas otras y no les queda otra salida (para ello, querido manager, debes explicar esas otras opciones, sino será imposible empatizar contigo).

¿Y cómo debe adaptar su mensaje el desarrollador? Cambiando de registro. Los que somos desarrolladores tenemos el superpoder de ser capaces de hablar a varios niveles. Hablamos a bajo nivel cuando estamos entre más técnicos, dando detalles de implementación, hablando de código, etc. Y hablamos a alto nivel con el resto del mundo, a nivel usuario, con nuestras familias, con los amigos, con Hacienda… Lo podemos hacer perfectamente. Usamos un lenguaje u otro dependiendo de donde estemos. Pues con nuestros amados managers nos toca hablar el lenguaje de negocio. Necesitamos posicionar nuestro foco en la rentabilidad de cada decisión. Nos tenemos que poner su sombrero.

Time is money
El tiempo que pedimos que nos den para mejorar el código es dinero que quizás no haya

El emisor es el responsable de que se entienda el mensaje

Como siempre he concebido la comunicación para que sea efectiva: asumir que el emisor es el responsable de que se entienda el mensaje te llevará a buen puerto. De esta manera, pondrás el foco en ti mismo como emisor y te esforzarás en llegar hasta el receptor con tu mensaje. Aquí lo explican muy bien, por cierto. Si eres manager, considero que tu responsabilidad toma mayor importancia al tener muchos receptores. Y si eres desarrollador con necesidad de hacer llegar ideas a management, considero que es tu responsabilidad adecuar tu lenguaje a la capa receptora.

Además, un recurso muy importante que ayuda enormemente a comunicarnos de forma eficaz es la comunicación no violenta (conocida por las siglas CNV). Recomiendo siempre el libro de Comunicación no Violenta, de Marshall Rosenberg, porque se explica de forma muy clara.

Y cómo no, ser humildes, tengamos el rol que tengamos. Porque ninguna persona es superior a otra, ni ninguna persona vale más que otra. Jamás. Debemos entender los roles como especializaciones dentro de una misma colaboración. El resultado será fruto de esa colaboración, con lo cual el éxito será de todos; cada uno habrá aportado una parte. Debemos sentir empatía por los compañeros, tengan un rol de toma de decisiones o tengan un rol de llevar a cabo tareas específicas, sintiéndonos igualmente profesionales.

 

 

Dejar un comentario