Estilos de Aprendizaje

El desarrollo de software presenta tanta variedad y matices en la manera de hacer cada tarea, en las herramientas que se utilizan y en los principios que se priorizan, que da lugar a un sin numero de inclinaciones y preferencias personales. Esto hace que cada desarrollador tenga sus valores y maneras de evaluar cada situación y que esta evaluación sea marcadamente distinta a la de otro.

Esta realidad se plantea claramente en lo personal. Noto que existe una falta de coincidencia llamativa entre mis pensamientos y los de otras personas que respeto en gran número de asuntos. En más de un momento me he preguntado donde nacen las diferencias más fundamentales con otras personas, o si es posible rastrear un único origen para muchas de ellas. Tal vez si.

El punto de partida de mi razonamiento son las palabras de Phillip Armour en su libro “The Law of Software Process”. Armour dice que el software no es un producto, es un medio para transportar conocimiento. Y continúa:

Si el software no es un producto, entonces el desarrollo de software no es una actividad de generar productos, no puede serlo. Si el verdadero producto no es el software sino el conocimiento contenido en el software, entonces el desarrollo de software solo puede ser una actividad de adquisición de conocimiento. Es cierto, podemos considerar que algunas de las funciones de desarrollo de software son una trascripción del conocimiento a una forma ejecutable. Esto es codificar. De todas maneras, codificar es sólo una pequeña parte de la actividad de desarrollar software, y se está volviendo más pequeña. También podemos afirmar razonablemente que si ya tenemos el conocimiento, entonces transcribirlo no requiere mucho esfuerzo. El trabajo real ocurre cuando tratamos de transcribir nuestro conocimiento y nos encontramos con que es incompleto. La actividad se convierte rápidamente en buscar el conocimiento correcto.
El desafío no es crear un sistema sino crear un sistema correcto. Si nosotros sabemos exactamente que es lo que tenemos que hacer, podemos crear sistemas tan rápido como nuestros dedos pueden tipear.
El desafío real es descubrir que es lo que el sistema debe hacer, y como podemos construir un sistema que lo haga.

The Law of Software Process: A New Model for the Production and Management of Software, Phillip Armour

Es algo difícil y extraño tomar esta perspectiva del desarrollo de software porque los desarrolladores tenemos una tendencia a pensar que sabemos todo lo necesario y una seguridad bastante manifiesta en nuestro conocimiento. Esta postura surge posiblemente porque los mejores desarrolladores tienen gran facilidad para aprender y cuando adquieren un conocimiento desarrollan una seguridad (excesiva) en ese conocimiento como si hubieran nacido con él. De pronto, un desarrollador que lo más parecido a control de versiones que había hecho en su vida era llamar a un archivo:

version_final.exe
version_final_final.exe
version_final_definitiva.exe

Trabaja en un proyecto donde se aplica un proceso de desarrollo CMM y a las dos semanas comienza a disertar sobre Gestión de Configuración, líneas base y a reírse de la inmadurez de otros que no tienen trazabilidad entre los requerimientos y los test cases.

Pero retomemos la idea de Phillip Armour. Pensemos por un momento que en realidad no sabemos todo y que lo que hacemos en un proyecto es, esencialmente, aprender.

Es crucial preguntarnos entonces como aprendemos, o más específicamente, cual es la manera más eficiente de aprender.

Aquí es cuando la individualidad de las personas, como siempre, comienza a ponerse en el medio. No todas las personas aprenden de la misma manera y estas diferencias en los estilos de aprendizaje se reflejan en más situaciones que las que uno supondría.

Marcus Buckingham, consultor y orador sobre prácticas de liderazgo y management dice que una revisión minuciosa de la teoría de aprendizaje de adultos revela que existen estilos predominantes que a veces se solapan. Entre ellos, el análisis y el hacer:

Primero, está el análisis. Los analistas entienden una tarea aislándola, examinando sus elementos, y reconstruyéndola pieza por pieza. Como cada componente individual de la tarea es importante a sus ojos, ellos necesitan fervientemente información. Necesitan absorber todo lo que existe de conocimiento sobre un asunto antes de poder sentirse cómodos con eso. Si no sienten que tienen suficiente información, escarbarán y presionaran hasta obtenerla. Ellos leerán el material asignado. Asistirán a las clases requeridas. Tomarán buenas notas. Estudiarán. Y aún así querrán más.
La mejor manera de enseñarle a un analista es darle tiempo abundante en la sala de capacitación. Representar situaciones. Hacer ejercicios de postmortem. Descomponer su performance en sus partes de manera que pueda reconstruirla minuciosamente. Siempre darle tiempo para que se prepare. El analista odia los errores. Un punto de vista común es que los errores alimentan el conocimiento, pero para el analista esto simplemente no es verdad. De hecho, la razón por la cual se prepara tan diligentemente es para minimizar la posibilidad de errores. Por lo tanto, no espere enseñarle mucho lanzándolo a una situación nueva y diciéndole que la maneje.
Lo opuesto es verdad para el segundo estilo dominante de aprendizaje, el hacer. Mientras que los momentos más poderosos de aprendizaje para el analista ocurren antes de la acción, para el hacedor ocurren durante la acción. Prueba y error son parte integral de su proceso de aprendizaje. Ellos aprenden más mientras están resolviendo cosas ellos mismos. Para ellos, la preparación es una actividad árida y poco interesante. En lugar de representar una situación con ellos, tome una tarea específica dentro de su rol que sea simple pero real, déle un breve resumen de los resultados que quiere, y aléjese de su camino. Luego incremente gradualmente el grado de complejidad de cada tarea hasta que haya dominado cada aspecto de su rol. Él puede cometer algunos errores en el camino, pero para el hacedor, los errores son la fuente del aprendizaje.

What Great Managers Do, Marcus Buckingham, Harvard Business Review - Marzo 2005

El analista y el hacedor son dos criaturas con grandes diferencias. Sus estilos de aprendizaje se manifiestan a cada instante y en todos los niveles en un proyecto de desarrollo de software.

¿Cómo llevaremos adelante un proyecto?

El analista quiere definir un proceso detallado, amplio, que considere los casos normales y los excepcionales, que abarque la mayor cantidad de tareas y de la manera más profunda posible. Métricas, estándares, herramientas, toda la definición que se toma hoy es tiempo ahorrado mañana. “Hay que hacerlo bien la primera vez”, “hay que evitar el costo del retrabajo”.

El hacedor quiere definir lo menos posible. Sólo las principales tareas y con mínimo detalle. La experiencia le indicará el camino. No quiere ponerse a pensar en todas las variantes ahora. Lo que quiere hacer ahora es ponerse a trabajar, y discutir sobre proceso, a sus ojos, no ofrece grandes aportes o avances en cuanto a resultados. “Hay que definir un proceso que cubra un poco menos de lo indispensable.”

Llega el momento de planificar y el analista comienza la tarea de llenar su gantt con tareas, responsables, dependencias e hitos. Descompone las tareas en subtareas, reestima cada una de ellas. Evalúa la asignación de trabajo de cada responsable, prueba que sucede si cambia algunas asignaciones, si el recurso X trabaja durante este periodo con una carga del 70 % y luego sube a 100 %. Cambia de orden las tareas. Prueba alternativas planificando ejecuciones paralelas. Podrá pasar horas y horas armando y puliendo esta planificación.

El hacedor hace una planificación con grandes hitos y resultados esperados. Luego descompone todo el proyecto en periodos de tiempo más cortos y solo determina el detalle de los resultados esperados para lo más inmediato. Define los objetivos para cada miembro en un periodo de tiempo y confia sabran hacer lo que haga falta para cumplirlos.

Las dependencias y el detalle de las tareas necesarias para llegar a los objetivos se resolverán sobre la marcha, tal como a él le gusta. Posiblemente ni siquiera arme un Gantt (¡sacrilegio!).

El analista comienza a pensar en requerimientos. La especificación debe ser amplia, detallada, completa y dentro de lo posible, inmutable.

El hacedor detalla sólo lo que necesita y no tiene problemas de que las cosas cambien. Tampoco lo incomoda que no estén especificados todos los requerimientos, igual cambiaran en el futuro.

El analista quiere definiciones de diseño, una arquitectura pensada que anticipe las posibles variaciones que depare el futuro, no importa que hoy no debamos implementar el software en varios idiomas, o para distintas bases de datos, o con distintos navegadores, o lo que sea. Siempre generalicemos, eso evitara retrabajo.

El hacedor piensa en diseño evolutivo, YAGNI, solo implementa la funcionalidad requerida y confía que podrá implementar las extensiones y cambios que sean necesarios, pero pensar hoy en algo que hoy no se necesita es perder el tiempo.

Hay situaciones y entornos que facilitan la postura del analista o del hacedor. Hay proyectos donde el nivel de incertidumbre es muy alto e intentar planificar en gran detalle tareas lejanas en el tiempo es una pérdida de tiempo. Hay otros donde la complejidad de la comunicación entre los diferentes equipos participantes requiere una planificación detallada y una definición clara de entregables, con fechas y criterios de completitud.

Pero el problema está en que nos cuesta realizar una evaluación racional de las necesidades de una situación particular y dejar de lado nuestros gustos.

En realidad en muchos momentos no tomamos decisiones racionales, sólo intentamos darle fundamentos racionales a decisiones basadas en preferencias o gustos.

Esto es un comportamiento bastante habitual en nuestro rol de consumidores, por ejemplo. Cuando vamos a comprar ropa y vemos una campera de marca reconocida pero muy similar a una mas barata, si nos gusta lo suficiente, encontraremos las razones necesarias que enmascaren nuestra compra como una decisión racional. “Mmm, si, me conviene comprar esta campera. Porque al final si compro la más barata no la termino usando. Y, en definitiva, estoy gastando dinero en algo que no voy a usar. En cambio, con esta, que sale un poquito más cara, estoy seguro que le voy a sacar provecho. Además como es de muy buena calidad, voy a tener campera para muchos años. Si, ¡me llevo esta!”

Clink, caja. Acabas de comprar una campera que sale el doble que otra porque tiene una etiqueta roja en la manga. No parece una decisión muy racional.

Cuando un analista o un hacedor tienen que tomar una decisión en un proyecto es muy difícil que dejen sus preferencias de lado.
El analista siempre verá riesgos de retrabajo, de hacer las cosas mal.
El hacedor siempre verá como perdida de tiempo tanta preparación, simplemente hagamos lo que tenemos que hacer y si hace falta algo más nos vamos a dar cuenta.
El analista siempre verá que los problemas de hoy son producto de la falta de preparación y planificación.
El hacedor siempre piensa que los problemas de hoy son inevitables y que lo mejor que se puede hacer es afrontarlos y aprender.

Lo constructivo de todo esto es entender que cuando otra persona realiza un planteo sobre necesidades de realizar más definiciones o de realizar menos definiciones puede estar relacionado con su manera de aprender. También darse cuenta cuando uno esta defendiendo una posición simplemente por una cuestión de gustos, no por necesidades reales de un proyecto.

En resumen, conocerse mejor y conocer mejor a los demás, para facilitar las coincidencias. Esto es positivo para cualquier proyecto.

¿Es buena idea medir y premiar el desempeño individual?

Hay temas que se presentan tantas veces en mis conversaciones con personas distintas que se ganan un espacio en este sitio indefectiblemente. En este caso, tiene que ver con algo que he mencionado antes, las métricas.

Razonando sobre el motivo de la existencia de las métricas, podemos realizar un primer acercamiento estableciendo que las métricas se toman porque ofrecen visibilidad sobre algún aspecto de un objeto en estudio, y otorgan de esta manera, información adicional para tomar decisiones. Se supone que estas decisiones tenderán a mejorar la situación. Si mido cuantos defectos introduzco en cada etapa de mis proyectos, es para saber donde debo apuntar mis acciones para mejorar, y en el próximo proyecto introducir menos defectos. Este debe ser el objetivo de tomar las métricas y de tomar decisiones basadas en ellas. Mejorar. Si todo va a estar igual o peor que antes ahorremos tiempo, dinero y esfuerzo.

Teniendo en cuenta esta ambición de mejora y considerando que las personas juegan un rol fundamental en los proyectos de desarrollo de software, no es difícil ni rebuscado llegar a la conclusión que existen grandes oportunidades de mejora midiendo el desempeño de las personas y tomando decisiones para optimizarlo. El objetivo de estas líneas es analizar esta idea:

Medir el desempeño individual de las personas para poder tomar decisiones que nos permitan alcanzar una mejora.

Este es un tema interesante. Mi percepción es que la postura más aceptada es que medir la performance individual es posible y es una buena idea. De hecho, muchas empresas lo están haciendo. Aunque las decisiones nunca son buenas sólo porque son frecuentes.

Comenzando con la primera parte de esta idea, podemos preguntarnos cómo hacemos para medir la performance de las personas. Indefectiblemente hay que establecer un sistema de medidas contra el cual todos serán mensurados. Déjenme contarles una experiencia relacionada al tema para ilustrar el punto que sigue.

Como ya he mencionado en otros artículos, por las características de mi trabajo he tenido la posibilidad de conocer varias empresas, más allá de haber trabajado sólo en dos. Conocer el día a día de una empresa nueva implica tomar contacto con cuestiones culturales muy llamativas. En una empresa en la que trabaje, observé que el reconocimiento del esfuerzo que cada uno ponía en su trabajo era directamente relacionado con el horario de salida. Existía esa idea en la gerencia y en muchas personas de la organización. Irse tarde estaba bien, irse a las 6 de la tarde era casi un insulto a las personas que se quedaban. Por supuesto, nadie decía: “Todos deben irse después de las 7 de la tarde”. La presión social tomaba caminos más sutiles pero no menos efectivos. Ciertamente, la gran mayoría de los empleados se retiraban después de las 18. Pero aquí venía lo curioso de la anécdota: muchos llegaban más tarde de lo que se considera normal. 9.30, 10, 10.30. ¿Por qué no trabajar de 9 a 18 como la gran mayoría de las empresas, en lugar de 10.30 a 19.30, por ejemplo? Porque muchas personas parecían prestarle atención al horario de salida pero no tanto al horario de entrada. Entonces todos hacían lo necesario para verse bien frente a este sistema implícito y algo curioso de medir el esfuerzo y el compromiso.

Es una tendencia casi natural de las personas. Observamos como nos miden y nos enfocamos en mejorar bajo esos parámetros.

Por lo general los trabajos se estiman en horas hombre, por lo que se podría comenzar midiendo las horas de trabajo para medir la productividad. Esta puede parecer una métrica inicial aceptable. Pero el problema es que las personas son ingeniosas y trabajan para conformar al sistema. Si saben que se las está midiendo por la cantidad de horas que pasan en la oficina encontraran la manera de estar más tiempo en la oficina sin producir más (tal vez porque realmente no puedan producir más).

“Al fin y al cabo a nadie le interesa que tan buenas son mis especificaciones, que tan efectivos mis diseños, cuanto tiempo ahorramos por mis buenas decisiones, o mi gran aporte para tomar las tareas tediosas o para capacitar a los nuevos empleados. No, a la empresa le interesa cuantas horas estoy aquí, como si fuera un guardia de seguridad o un espantapájaros. Bien, puedo hacer muchas cosas para distraerme en la oficina y hacer que pase el tiempo. Puedo traer unos buenos libros que generalmente leo en casa, puedo escribir largos mails en Visual Studio para que parezca que trabajo, puedo preparar el café instantáneo batido más batido que se haya conocido dedicándole 32 minutos por día. Por supuesto, si miran la métrica verán 20 horas más que el mes pasado.”

Esto mismo puede suceder midiendo líneas de código, bugs corregidos, o lo que sea. Podríamos definir como métrica la cantidad de cumplimientos o incumplimientos de fechas de entrega, pero el software es una entidad lo suficientemente abstracta como para inutilizar esta métrica. No es extraño ver un grupo de desarrolladores “cumplir” con su fecha de entrega a testing para recibir como retorno un reporte de defectos enorme, o (seamos sinceros) no es extraño cumplir con fechas de entrega con clientes liberando versiones de un producto de dudosa calidad. Si el sistema de medidas premia el cumplimiento de fechas de entrega, estas se van a cumplir. De una manera u otra se van a cumplir.

Por el tipo de trabajo realizado en el desarrollo de software, es muy difícil, por no decir imposible, establecer un sistema de estas características que no termine corrompiendo el comportamiento de las personas y que refleje de manera fidedigna la performance.

El problema de relacionar algún tipo de premios a estas métricas es que no aporta nada al objetivo inicial planteado. Recordémoslo:

Medir la performance de las personas para poder tomar decisiones que nos permitan alcanzar una mejora.

Aquí nada mejora. Nadie produce más, nadie está más motivado. Simplemente todos hacen lo de siempre, tal vez aumentan su nivel de cinismo frente a las iniciativas de la empresa, y hacen lo necesario para verse bien frente al sistema de medidas.

Otra alternativa usada es definir un valor de productividad, objetivos cumplidos, o algo por el estilo para calificar el trabajo de una persona en un periodo de tiempo determinado. Este valor es definido por la persona en el nivel superior de la jerarquía del empleado calificado. Esto no es una métrica, es una opinión. ¿Cómo te parece que trabajo este mes Juancito? “Mmm, yo le pondría un 8” “Me parece que cumplió con los objetivos”. No estoy diciendo que esta opinión no sea válida o que no sea útil. Estoy diciendo que no es una métrica, lo que en cierta manera nos aleja de la idea inicial de medir la performance de las personas. Pero si pienso que esto nos da una pista de algo que podemos hacer para mejorar la performance, que exploraremos más adelante.

De alguna manera, la necesidad de una métrica objetiva de desempeño individual tiene relación a la búsqueda de alcanzar la equidad, la disposición del ánimo que mueve a dar a cada uno lo que merece. Si en un periodo dado el rendimiento de un empleado es bueno y el de otro es excelente, el segundo debe recibir un retribución mayor. Pero no hay que confundirse. La equidad no está alineada con la premisa definida anteriormente porque la búsqueda de equidad puede perjudicar nuestro objetivo de mejorar el desempeño. Nadie piensa que hace un mal trabajo. Nadie dice: “Sinceramente este mes he trabajado de manera irresponsable, sin compromiso, y es mi culpa completamente. No me merezco el premio por productividad” ¡No! Todos pensamos que hacemos muy bien nuestro trabajo, o a lo sumo tan bien como se puede hacer con las herramientas que la empresa nos da. “Puede que haya hecho algo mal pero la empresa no me capacito o no me dio el tiempo necesario, o…” Siempre pensamos que estamos trabajando bien. Por eso, recibir un premio por nuestro desempeño no es más que recibir lo que merecemos; y no recibirlo es darse cuenta que nadie reconoce nuestro esfuerzo y, por lo tanto, no tiene sentido. El resultado de esta búsqueda de equidad nunca termina produciendo una mejora de desempeño sino más bien lo contrario.

Es esta búsqueda de equidad, también, la que nos hace pensar en medir individualmente el desempeño de las personas para poder comparar unos con otros. No considero que esto sea buena idea. David Anderson, manager en Microsoft, cuenta porque:

Desarrollar software es un deporte de equipo; requiere interacción y soporte mutuo a través de todo el equipo. Es trabajo de conocimiento y es hecho mejor en un entorno de conocimiento compartido. Cuando uno premia a las personas por su esfuerzo individual relativo a sus pares, estas alentándolos a acaparar conocimiento, no a compartirlo. El manager debe ser medido por la productividad del equipo, no los individuos miembros del equipo por sus esfuerzos individuales. Es un sistema – optimiza para el sistema, no para sus partes.

Managing at Microsoft, Software Development Magazine, Marzo 2005

Podemos pensar, entonces, que el problema no es encontrar la métrica apropiada para medir individualmente el desempeño de una persona y poder premiarla, porque esto nunca nos llevará a una mejora de desempeño que es nuestro objetivo original. Esto parece ser lo que realmente ocurre con los programas de premios por performance.

“Cerca del 83 por ciento de empresas con algún tipo de programa de premios por performance dicen que su enfoque es poco exitoso, o que directamente no funciona,” de acuerdo a The Wall Street Journal (“Firms Report Lackluster Results from Pay-for-Performance Plans”, 15 de Junio de 2004)

No tenemos métricas pero tal vez tampoco las necesitemos. Hay cosas que se pueden conocer más allá de la falta de métricas y se puede actuar para mejorar.

¿Cómo es la relación con tu pareja?

“Mmm, el último mes tuvimos 3 discusiones leves, y una grave. Dos veces ella no quiso cocinar y 5 veces yo protesté para sacar la basura. Dos veces no coincidimos sobre el destino de nuestros ahorros. Eso significa que si multiplico la cantidad de incidentes por su nivel de gravedad y lo divido sobre la cantidad de días me da el coeficiente de relación saludable.” [1] Suena estúpido, ¿no? Uno puede decir si la relación con su pareja es buena, mala o regular sin métricas. Porque convive, comparte momentos y la suma de cada una de esas pequeñas experiencias es la que nos da la sensación del estado de la relación. Además es saludable que uno aprenda a prestar atención a los detalles que manifiestan como esta esa relación.

Siendo un manager puedo saber si es bueno el desempeño de cada uno de los miembros de mi equipo sin métricas. Como manager uno debería prestar atención a los detalles, formar esa sensación sobre el desempeño de los integrantes del equipo y escuchar y escuchar. Muchas veces los problemas se manifiestan de formas inesperadas y sutiles. Parte del trabajo de un manager es aprender a detectar estas formas.

Esto nos lleva al esquema que planteaba unos párrafos mas arriba, sobre reflejar una opinión sobre el desempeño de una persona de alguna manera.

Pensemos en la siguiente situación: Carlos, líder de un equipo de desarrollo, observa que Luis no se desempeña de la mejor manera. Él está convencido que Luis puede realizar su trabajo mejor, nota que no lo hace con todo el compromiso que él esperaría. Es una situación muy concreta y real para Carlos. Luis puede trabajar mejor y no lo hace. Por supuesto, Carlos quiere que Luis mejore su desempeño. ¿Qué es lo que puede hacer para lograr esto? Podría quitarle el premio por productividad a Luis.

¡Ouch! Esa es una forma bastante primitiva de comunicación, demasiado simplista y centrada en el dinero. El rol que está cumpliendo el premio por productividad es dar retroalimentación sobre el trabajo ejecutado a un empleado.

Esther Derby dice que la retroalimentación “es información que le damos a otra persona cuando queremos que comience, termine, continué, o cambie algún comportamiento.”

How to Talk About Work Performance: A Feedback Primer, Esther Derby

En el caso del castigo por falta de productividad simplemente es decir: “No estoy conforme con lo que hiciste este mes”. Es una manera de dar información muy pobre y tosca para lograr algún resultado.

Se puede hacer de una manera mucho más efectiva, clara y menos ofensiva conversando sobre el tema con el principal interesado. Esther Derby brinda algunas recomendaciones en su artículo sobre retroalimentación:

• Hablar del tema tan rápido como sea posible: si como manager detecto un problema la primera semana del mes, ¿por qué esperar hasta fin de mes, cuando se definen los premios, para dar retroalimentación?


• Proveer ejemplos específicos: “No trabajaste comprometido como esperamos” es algo tan ambiguo que no da pautas al empleado sobre que es lo que debe cambiar. “Note que esta semana faltaste por tercera vez a una reunión de equipo en lo que va del mes” es algo más específico. Lo mismo se aplica para retroalimentación sobre hechos positivos. “Manejaste con gran rapidez y eficiencia los requerimientos del cliente X durante las vacaciones de Hugo. Hiciste que su ausencia no nos afectara.” En este caso el premio por productividad sólo dice BIEN/MAL.


• No depender de la telepatía:
  “Pero, ¿qué hice mal?”
  “No me lo preguntes. Sabes muy bien que hiciste mal.”
  El premio por productividad por si sólo es telepatía pura. No dice nada, todo es supuesto.


• Verificar que existe acuerdo en los datos: En caso de dar ejemplos específicos, verificar que el empleado está de acuerdo con lo que se dice. “Si, realmente falté a tres reuniones este mes.”


• Solicitar un cambio: Elemental, Watson. Si uno como manager espera que un empleado cambie su comportamiento hay que decirlo. Si uno espera que deje de hacer algo hay que decirlo. “Entiendo que las reuniones muchas veces se extienden demasiado. Ya trabajaremos sobre ese tema. Pero quiero que, a partir de hoy, asistas a todas las reuniones de equipo.”
  

Este enfoque admite que el desempeño de una persona no es proporcional al dinero que se les paga. Entiende que se deben contemplar las motivaciones, los problemas, la fallas en la definición de objetivos o en la comunicación. Y apunta a resolver los problemas que pueden causar el desempeño insatisfactorio. Claro, esta tarea es más compleja que simplemente tomar decisiones binarias sobre si pago o no un premio de productividad. Pero quienes piensan seriamente en mejorar el desempeño deben estar dispuestos a tomarse el trabajo que requiere.

Muchos managers no tienen la tendencia natural de manejar los aspectos sociales de su rol. Es más fácil para ellos sentarse a llenar una planilla con números o una aplicación de RRHH, que sentarse a conversar con los miembros de su equipo para detectar las maneras de mejorar el desempeño o escuchar los problemas que tienen. Lo que plantea un aspecto interesante de todo esto. ¿Qué tan idóneos son los managers para hacer su trabajo? ¿Qué tan bien lo hacen? ¿Qué tan preparados están para hacerlo? La búsqueda constante de una forma de medir con un número el desempeño de las personas y de premiar o castigar con dinero puede ser simplemente un reflejo de la incapacidad actual de los managers para cumplir su rol.