agile, Organizaciones Diferentes, Sin categoría

Di NO a la meritocracia. ¿Cómo componemos nuestro Development Team?

La meritocracia es un sistema muy famoso en muchas organizaciones que básicamente consiste en que ascienden los mejores en una organización por méritos. Digamos que las personas con más talento son las que llegan lejos dejando atrás a los menos talentosos.

Así dicho suena maravilloso, los mejores son los que llegan lejos. Solo nos queda encontrar un método que nos diga quienes son los mejores. Necesitamos poder introducir en un excel los nombres de todos nuestros compañeros de trabajo con una columna que diga “talento” y hacer una ordenación de esa columna. Si puedes tener eso, puedes tener la meritocracia.

Un ejemplo donde esto se ve reflejado es a la hora de elegir los ministros del gobierno. Sin meterme en política, siempre hay revuelo cuando un partido trata de fomentar el 50% de paridad. Los detractores siempre dicen “lo importante no es que haya mujeres, es que estén los mejores”. ¿No existe en un partido político de más de cien mil personas 10 mujeres que sean buenas? Hay que pensarlo con detenimiento porque la elección es complicada “Esta persona tiene dos carreras, una de derecho y otra de filología inglesa y este tiene una carrera como arquitecto y sabe tres idiomas” ¿Quién es mejor?

water-2045469_1280.jpg

Es muy difícil acertar con esto, os pongo un ejemplo real que viví. En una empresa en la que trabajé tenían un sistema trimestral de bonus por productividad (realmente era más bien un sistema de reparto de beneficios). En ese momento estaban dos programadores y un responsable tenía que decidir quién de los dos lo había hecho mejor. Os expongo la situación:

  • Un programador venía de trabajar con PL-SQL y tenía que aprender Java en ese trimestre, aún así, lo hizo muy bien y desarrolló mucho trabajo. Además, tenía una categoría superior al compañero.
  • El otro compañero era Javero, sacaba mucho más trabajo además siendo de una categoría inferior.

 

¿Quién es mejor? Para su responsable ambos eran buenos, habían trabajado bien, se habían esforzado, sin embargo, tenía que elegir.

Este tipo de situaciones son tremendamente injustas, mirar al individuo es muy difícil, porque cada persona es diferente y usar expresiones de mejor o peor no son realistas. Y es muy importante otra característica totalmente humana: todos nos vemos mejor de lo que somos.

El motivo de que esto sea así lo explica muy bien el experimento de Milgram donde al “sujeto” de estudio se le hacían tomar malas decisiones presionado por una autoridad moral. Nosotros sabemos por qué tomamos las decisiones, por eso, cuando nos equivocamos, sabemos el motivo de porqué nos equivocamos. Con los demás, no sabemos bajo qué circunstancias toman sus decisiones y por eso a veces las percibimos como si fueran “estúpidas”.

Ahora imagina que tenemos que componer un Development Team para desarrollar un producto crítico de nuestra organización. ¿Elegimos a los mejores? ¿Cómo sabemos quiénes son los mejores?

En Scrum se suele mirar más al equipo. El foco se pone ahí porque los equipos son los que mueven el mundo. No hay ya un cirujano experto, es un equipo de quirófano, o cuando un piloto de Fórmula 1 corre lo hace en equipo. El equipo es lo importante y el resultado del mismo es lo que importa.

Si lo pensamos Scrum dispone de diferentes reglas fomentando el trabajo de equipo por encima del individual. En el Development Team no hay etiquetas y el trabajo se considera responsabilidad de todos. El equipo debe tener de todas las habilidades o skills necesarias pero no habla de “personas concretas”. Por ejemplo, no dice Scrum que haya un “QA”, dice que haya las habilidades necesarias, si por ejemplo hace falta hacer trabajo de QA, al menos una persona deberá aportar esos conocimientos. Por tanto, no tenemos etiquetas, tenemos personas con habilidades que nos ayudan a sacar producto.

Otra peculiaridad es la velocidad del equipo. Medimos puntos, horas o PBIs que el equipo hace en un Sprint, pero nunca a nivel individual. No nos interesa crear una competitividad interna entre compañeros.

¿Cómo podemos aplicar meritocracia en un circunstancia así? Si fomentamos el trabajo en equipo es difícil saber quién se lo merece más teniendo en cuenta que tod@s luchamos en equipo por desarrollar producto. Por tanto, las organizaciones que quieran hacer Scrum apostar por una meritocracia como manera de crecer quizás acabe chocando y perdiendo talento.

Scrum, por suerte o desgracia, no entra a decirte cómo organizar tu empresa. Sólo pide que los managers den soporte a Scrum, ayuden a resolver impedimentos y entiendan el desarrollo empírico de producto. Sin embargo, doy algunos consejos que creo que pueden ayudar por encima de una meritocracia:

  • El salario acorde a la experiencia y no acorde al puesto: Que una persona con conocimientos de arquitecturas fuertes pueda ganar más que un SM.
  • No fomentar que ser Scrum Master es un “ascenso” en la organización. Ser Scrum Master es jugar un rol diferente dentro de Scrum, pero si aparejas un salario mejor entonces puedes fomentar competitividad. Además, en algunas organizaciones dan mejor salario al Scrum Master porque realmente es un Jefe de Proyectos encubierto, y por tanto, tiene una responsabilidad añadida que hay que compensar.
  • Lo mismo aplica para Agile Coach como un ascenso del Scrum Master.
  • Evitar parrillas salariales que fijen lo que ganan las personas, buscar más el talento y la atracción.
  • A la hora de dibujar la organización de un equipo poner un gran círculo con los nombres de los desarrolladores y añadir las habilidades que tiene el equipo (no las personas).
  • Si quieres crear bonus, que sean a nivel equipo y no individual.

Por último, hay más cosas que se podrían hacer pero es verdad que son muy difíciles. Por ejemplo hacer transparentes los sueldos en la organización o dejar que los equipos decidan cuanto ganar. Estas técnicas están apareciendo en lo que se conoce como empresas “teal” y en España está calando muy poco. Digamos que asumen que las personas son responsables para hacer su trabajo y que cada uno decide qué tareas asumir por lo que el paradigma sobre cómo organizar la empresa cambia totalmente. Estas decisiones son difíciles en empresas que han crecido y madurado de una manera por lo que, de momento, es complicado aplicarlo.

people-3120717_1280.jpg

Sin embargo, hay algo más fácil que sí se puede hacer como paso intermedio. Tratar de crear un ambiente donde el crecimiento no sea tanto hacia “arriba” como un crecimiento en conocimiento, en habilidades y en valores. Para que esto ocurra es tan sencillo cómo cambiar las atribuciones de los managers intermedios de jefes a facilitadores. Enseñarles a trabajar para soportar la autoorganización y responsabilidad de los equipos. Por ejemplo, eliminando herramientas de control de la organización y el feedback de estos manages a las personas a la hora de revisar el sueldo. Cuando un empleado pregunte ¿Qué se espera de mí? La respuesta habitual sea “haz bien tu trabajo, mejora, aprende y se mejor profesional cada día”. De esta manera no tenemos que guiar a las personas y dejamos que descubran lo que se les da bien hacer y crezcan.

Y en tu organización ¿Cómo se disponen las subidas y el desarrollo de las personas?.

 

2 comentarios en “Di NO a la meritocracia. ¿Cómo componemos nuestro Development Team?”

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s