[#ALM] Sobre evaluaciones anuales, los nuevos managers y animarse a romper esquemas

A01

Hola!

Cuando llega fin de año llega ese fabuloso momento donde llegan las evaluaciones anuales. Ya lo sé, no voy a entrar a hablar sobre ese tema por 2 motivos: primero me da urticaria ese penoso modelo y además que daría para escribir un post completo. Mejor leer lo que escribe Ilya Pozin que la verdad que lo describe muy bien en 2 páginas (link). Uno de los puntos que remarca, y de lo que va el post, es que la frecuencia del feedback no tiene que ser anual tiene que ser en modo “real time”. Aquí también toca algunos puntos como por ejemplo minimizar las críticas negativas sobre el trabajo, habla sobre estadísticas y diferencias entre evaluaciones hacia mujeres y hombres; y un par de cosas más.

Lo que creo que le falta es un poco de visión sobre los managers / amados líderes / jefes o como se llamen en vuestro equipo de trabajo. Para que el modelo de evaluaciones comience a ser más efectivo, también tiene que cambiar la forma en la que se lidera un equipo. Si partimos de la base que una evaluación es un acto que pretende corregir un error o reforzar una buena práctica, pues gran parte de la responsabilidad de este acto recae en la persona que lo lleva a cabo.

Por ejemplo, he visto muchos casos donde los managers, toman un modelo 100% orientado a la delegación de tareas y su rol consiste simplemente en dirigir a un grupo de personas. Personalmente esto suele ser como escupir contra el viento. En equipos modernos, la salud del equipo depende de la relación que exista entre los integrantes del mismo. Si lo único que hace el jefe es dar órdenes, cuando llegue el momento de comunicar una evaluación lo más probable es que el primer pensamiento del evaluado sea “y este que me dice si no entiende nada de lo que hacemos”. Si en cambio, la actitud del amado líder es liderar con el ejemplo, el momento de la evaluación es mucho más cercano y seguramente mucho más efectivo.  Un detalle sobre esto. No quiero decir que un manager tenga que trabajar codo a codo con cada uno de los integrantes del equipo (que si hay la oportunidad debería hacerlo). Liderar con el ejemplo significa ser coherente con las acciones que realizamos porque esas son las que se verán reflejadas en los integrantes del equipo. En estos casos, y por una cuestión de sentido común, los amados lideres suelen ser escogidos por el equipo.

Esto me lleva al segundo punto que está referido a la frecuencia con la que se realizan estas evaluaciones. Mi recomendación no es invertir 15 minutos al día con cada persona del equipo, pero si analizar las variables que definen el entorno del equipo y tal vez aprovechar las retrospectivas o similares para realizar estas evaluaciones. Y aquí llegamos a un punto importante, si en tu empresa las evaluaciones son anuales, ESO NO QUIERE DECIR QUE NO PUEDAS CAMBIAR ESTA FORMA DE TRABAJO. No me refiero a convencer a los encargados de recursos humanos para que cambien la forma de trabajo de 10000 personas, sino más bien realizar acciones disruptivas desde adentro. Alguno pensará que como buen compatriota del “Che”, pretendo fomentar una revolución y la verdad es que SI. Si realmente crees en un modelo que puede funcionar mejor, porque no aplicarlo en tu equipo. Comentarlo con otros compañeros y a la larga si el modelo es bueno, seguro que se termina adaptando a la filosofía de la empresa.

Nota: Siempre que propones una buena idea, no creo que haya una capa superior tan obtusa como para no darse cuenta de las ventajas de un cambio para bien.

A03

Sobre esta misma base, es increíble como los “nuevos managers” son mucho más abiertos a compartir información, en contrapartida con los managers tradicionales donde impera la creencia de que “la información debe ser controlada”. No voy a entrar en cuestiones sociales, aunque esto también viene dado gracias a una generación donde el concepto de IP es cada vez más extraño y contrario a lo que se llevó en los últimos 50 años. (Este es el 2do punto donde debería escribir un post simplemente para esto)

Para finalizar y retomando el tema de ser disruptivo, yo simplemente animaría a cualquier persona que sostenga este papel de amado líder a romper un poco las barreras de lo establecido e intentar

  • Ser coherente con lo que dices y con lo que haces. Esto se verá reflejado cuando transmitas un mensaje con el equipo de trabajo
  • Adoptar un modelo de feedback en tiempo real. Las evaluaciones anuales están muy bien, realmente bien, increíblemente bien 😉
  • Entender las diferentes generaciones de trabajo. Esto es importante, hay que ser muy sutil al trabajar con personas de 25 años y de 50 años …
  • Convence a “tus jefes” de lo que crees. Lo sé, es como escupir acostado lo más probable es que salga mal, aunque … ¿y si te sale bien?

a02

Aquí debería cortar el post, porque el siguiente párrafo seguramente será sobre modelos disruptivos y creo que mejor me voy a jugar al futbol con el Valentino un rato 😀

Saludos @ Madrid

/El Bruno

References

Why Everyone Hates Performance Reviews And How To Fix Them

http://www.forbes.com/sites/ilyapozin/2014/12/10/why-everyone-hates-performance-reviews-and-how-to-fix-them/

Advertisements

[#ALM] #PairProgramming in transmitter / receiver

Hello!

Pair Programming is very cool, and at some point you start to get addicted to this practice, kind of a 12-step program. In an early stage, it is usually difficult to have a with a good pace of work. However, in the next phase, the team start to realize that something like “this is amazing”; and from now on, the team only wants to work in a Pair Programming mode. Finally you end up realizing that there have to be a balance, in example: is good to maybe have 2 sessions of Pair Programming in a day, one in the morning and another in the afternoon. This gives time so then everyone in the team can have its own time for research, personal development time and play some online game.

A classic bad example of Pair Programming is when an Alpha developer and a Beta developer, are starting to work together. That’s it without have some clear rules. The Alpha programmer, as we all know is often very dominant. The Alpha Devs, impose his point of view, etc. (kind of a Punisher in dev mode). In a model of Pair Programming, this programmer has just taking over the control in the keyboard, writing all code, and refuting any suggestions or criticism received from the Beta dev. In the toher side, the Beta developer is more comfortable in a position where not falls on him (or her) much responsibility, so this living in this 2nd level is fine.

A solution for this type of scenario, is to work in Pair Programming, with a model “transmitter” and “receiver” (or “leader” and “key presser”). In this model, you can work in small time lapses, ie: 25 minutes (the Pomodoro TechniqueDuring this period of time, one of the developers will be responsible for coding and the other will be the one which tell what to do.

The “key presser” can not directly code based on what he thinks, but it must be the hands and fingers of the ‘leader’. This model is incredibly unproductive at first, however when it passes a time has a number of advantages

  • The fact of forcing that one code and the other leads, move to the team members improve their communication skills
  • The leader has to learn a quick and consistent way to communicate his ideas so that key presser can carry them out
  • The key presser, have to learn to listen (this seems obvious, however usually is very complicated)
  • When the leader explains his idea out and loud, it tends to be a great time to detect problems, bugs, etc.
  • On the other hand, the part listening also has voice and vote, can challenge an idea, collaborate with it, etc.

Depending on the size of the team, it is also important to do rotations in pairs that work. And not try to gather the most obvious profiles.

I encourage you to try this model and then tell me!

Best regards

/El Bruno

References

> Pair Programming, http://en.wikipedia.org/wiki/Pair_programming

> Punisher, http://en.wikipedia.org/wiki/Punisher

> Pomodoro Technique, http://en.wikipedia.org/wiki/Pomodoro_Technique

> Picture, http://avengersalliance.wikia.com/wiki/Punisher/Dialogues

[#ALM] #PairProgramming en modelo Emisor / Receptor

Hola!

Lo de programar a pares (“Pair Programming”) tiene cierto punto de adicción y odio que hace que cuando lo comienzas a probar, es algo muy parecido a un programa de 12 pasos. En los primeros momentos, por lo general es complicado dar con un ritmo bueno de trabajo. La siguiente fase, es algo así como “esto es la rehostia !!!” y el equipo solo quiere trabajar en un modelo de Pair Programming. Finalmente te terminas dando cuenta que ni tanto ni tan poco, que es bueno tal vez tener 2 sesiones de Pair Programming al día en el equipo, una por la mañana y otra por la tarde. Esto da tiempo para que luego cada persona(je) del equipo pueda tener su propio tiempo de investigación, desarrollo personal y jugar al Apalabrados.

Un ejemplo clásico de Pair Programming mal aplicado es cuando se juntan un developer Alpha y un developer Beta, sin dejar claras las reglas de juego. El programador Alpha, como todos sabemos es por lo general muy dominante. Los Alpha Devshablar mucho, imponer su punto de vista, etc. (una especia de Punisher en modo developer).  En un modelo de Pair Programming, este programador acaba adueñándose del teclado, escribiendo el código que a él (o ella) le parece y refutando todas las sugerencias o críticas que recibe del programador Beta. Por otra parte, el programador Beta se encuentra más cómodo en una posición donde no recaiga en él (o ella) mucha responsabilidad, así que esto de estar en 2do plano está muy bien.

Una solución para este tipo de escenarios, es trabajar en Pair Programming, con un modelo “emisor” y “receptor” (o “líder” y “pica teclas”). En este modelo por ejemplo, se definen períodos de tiempo de trabajo, por ejemplo de 25 minutos (al estilo Pomodoro Technique). Durante este período de tiempo, uno de los developers será el encargado de codificar y el otro será el que le indique lo que debe hacer. El “pica teclas” no podrá codificar directamente en base a lo que piensa, sino que deberá ser las manos y dedos del “líder”. Este modelo, es increíblemente improductivo al principio, sin embargo cuando pasa un tiempo tiene una serie de ventajas inherentes

  • El hecho de forzar a que uno codifica y el otro lidera, ayuda a que los integrantes del equipo mejoren sus capacidades de comunicación
  • El líder, tiene que aprender una forma rápida y coherente de comunicar sus ideas para que el pica teclas las pueda llevar a cabo
  • El pica teclas, tiene que aprender a escuchar (esto parece obvio, sin embargo suele ser muy complicado)
  • Cuando el líder explica su idea en voz alta, suele ser un excelente momento para detectar problemas, fallos, etc.
  • Por otra parte, la parte que escucha también tiene voz y voto, puede desafiar una idea, colaborar con la misma, etc.

Dependiendo del tamaño del equipo, también es importante ir realizando rotaciones en los pares que trabajan. Y no intentar de juntar a los perfiles más obvios.

Los animo a que prueben este modelo y luego me cuentan !!!

Saludos

/El Bruno

Referencias

> Pair Programming, http://en.wikipedia.org/wiki/Pair_programming

> Punisher,  http://en.wikipedia.org/wiki/Punisher

> Pomodoro Technique, http://en.wikipedia.org/wiki/Pomodoro_Technique

> Picture, http://avengersalliance.wikia.com/wiki/Punisher/Dialogues