¿Recompensas o sanciones? O solo recompensas?

Cuando trato con profesionales, encuentro que la gestión del estilo de la Teoría Y es la mejor. La teoría Y asume que los empleados quieren hacer un buen trabajo. Asume que el dinero no es un motivador, por lo que las recompensas intangibles son las mejores.

La gerencia al estilo de la Teoría X asume que los empleados son perezosos, necesitan dirección constante y están motivados por el miedo al castigo y al dinero en efectivo.

Al tratar con personas que necesita ser proactivas y tomar sus propias decisiones, una atmósfera positiva, gratificante y alentadora fomentará más líderes en su equipo, y eso es lo que necesita como PM.

Si se utilizan penalizaciones, no deben ser algo drástico, desmotivador o que dificulte enormemente el trabajo de los miembros del equipo. En los equipos de software, la persona que rompe la compilación generalmente es responsable de tener que arreglarla. Aunque es un tipo de penalización, el desarrollador aprenderá del error y también podrá asumir el papel de liderazgo en la coordinación para solucionarlo.

Otro tipo de penalización podría ser poner un centavo en un frasco cada vez que otro desarrollador encuentre un error en su código. Dado que es más como un juego en el que la persona con más centavos pierde, en realidad es bastante motivador.

Tal vez el perdedor del grupo tiene que ser el que vaya a buscar café para los demás esa semana.

Para usar un ejemplo fuera de la programación, cuando estaba en el ejército, si olvidaba algo en mi uniforme, la sanción era de 20 flexiones. Me ayudó a mantenerme en forma, me sirvió como recordatorio para la próxima vez y fue una especie de juego del que todos nos reímos, incluso con nuestro sargento.

¡Evitaría sanciones financieras a toda costa, ya que este es el sustento de alguien! Cada vez que Roger Goodell multa a un jugador de la NFL por cometer un error, me estremezco.

ACTUALIZAR:

Para las recompensas, la recompensa también debe ser intangible. No estás lidiando con ratas en una jaula a las que puedes electrocutar y alimentar arbitrariamente en función de su elección de caminos. En cambio, la recompensa podría estar relacionada con el trabajo, como darle al mejor ingeniero la oportunidad de liderar la presentación del equipo de una característica de un nuevo producto al director ejecutivo o a un cliente. Una recompensa como esta está relacionada con el trabajo, por lo que en realidad fomenta los comportamientos que pueden haber ayudado al empleado a llegar a donde está en primer lugar.

Otro ejemplo de una gran recompensa sería una mayor libertad para tomar decisiones sobre el proyecto de forma independiente. Si un ingeniero se ha probado a sí mismo, déjelo tener un papel más independiente en un proyecto. Deje esto claro para que todos sepan que se ganó este privilegio/derecho de paso. (Esto es más para ingenieros junior. Los ingenieros senior ya deberían haberse ganado este derecho).

Alguien más (Craig Villacorta) dijo reconocimiento , que es a lo que me estoy refiriendo con estos ejemplos, así que no le daré una paliza.

En resumen, tenga en cuenta que si bien está tratando con profesionales que , naturalmente, harán todo lo posible porque así son , eso no significa que estos profesionales sean secos y no les guste divertirse.

Siempre que el sistema de recompensas/penalizaciones sea algo divertido, puede ser una herramienta para ayudar a mejorar la moral.

¡ Piense en la reputación en los sitios de Stack Exchange! Claro, la mayoría de nosotros estamos aquí para ayudar a las personas, mejorar nuestras habilidades de escritura y aprender de los demás, pero ¿no es un poco divertido ver cómo su reputación aumenta?

Me olvidaría del enfoque típico de recompensa/penalización. La gran mayoría de las personas que conozco que son las mejores en sus equipos de proyecto no trabajan para obtener una recompensa o evitar una sanción. Lo hacen porque se sienten responsables de los resultados de su trabajo, no quieren defraudar al cliente/su organización/líder/ellos mismos, simplemente quieren hacer un buen trabajo, etc. Básicamente se dedican al 100% (o más) de su trabajo porque creen que es lo correcto.

Si lo hace todo sobre la recompensa y/o la penalización, crea el sistema que será engañado o al menos la gente intentará engañarlo. No obtendrá un rendimiento significativamente mejor si le dice a la gente que al final del proyecto hay una gran recompensa. Si funcionara de esa manera en los deportes, siempre se premiaría a los mejores equipos en la parte superior, lo que obviamente no funciona de esa manera.

Habiendo dicho eso, no estoy en contra de las recompensas, pero no lo conviertas en la clave para motivar a la gente. Y en cuanto a las penalizaciones, para mí, los comentarios críticos bien entregados siempre funcionaron mejor que cualquier penalización específica.

Así que, en resumen, mi respuesta a la pregunta recompensas versus penalizaciones es "ninguna".

+1 a @pawelbrodzinski por "ninguno". Sin embargo, agregaré que a veces el reconocimiento puede ser una gran recompensa. No tiene que ser monetario o material. Muchas personas con las que he trabajado y entrevistado realmente responden positivamente a un genuino "gracias por hacer un gran trabajo". Les hace sentir que la gente realmente nota y valora su trabajo. En mi organización, comenzamos nuestras reuniones de equipo con una lista de mesa redonda de "victorias". A la gente le encanta reconocer a los demás y ser reconocida en público. También nos "gestionamos", donde le paso una pista a mi VP de que un miembro del equipo hizo un buen trabajo en algo, y nuestro VP en realidad enviará una nota de agradecimiento escrita a mano a la persona diciendo algo como, "Yo Escuché que estabas trabajando en X y estás haciendo un buen trabajo.

No tengo una respuesta directa, pero sí una historia que quizás te diga algo a tener en cuenta.

Una vez, hubo un entrenamiento para líderes de una escuela de vuelo militar. Se les explicó que para aprender nuevas habilidades, es mejor premiar el buen desempeño, pero no reprender el mal desempeño.

Uno de los instructores de vuelo argumentó de inmediato que eso estaba mal.

Cuando uno de sus alumnos se desempeñaba mal en un día, lo reprendía. Al día siguiente, su desempeño mejoró. Cuando uno de sus alumnos se desempeñaba muy bien, lo recompensaba. Al día siguiente, su rendimiento bajó. Su conclusión fue que la reprimenda es efectiva, donde la recompensa logra todo lo contrario de lo que él quiere.

La realidad de la historia es que sus reprimendas o recompensas tienen poco que ver con este tipo de cambios en el desempeño. Volar, como la ingeniería de software, es una habilidad que requiere tiempo y esfuerzo para aprender y mejorar gradualmente. A veces tendrás días buenos, a veces tendrás días malos. Pero, por lo general, regresa a la media, que es un crecimiento gradual.

La moraleja de la historia para su pregunta es: si decide reprender o recompensar, asegúrese de que sea algo a largo plazo. Todo el mundo tiene días buenos y malos, a veces incluso semanas. Si actúa como instructor de vuelo en esta historia, en realidad terminará con la mentalidad de que recompensar es ineficaz y que reprender funciona bien.

Ser parte de un buen equipo que logra y entrega buenos productos, ser tratado con respeto y tener la oportunidad de crecer en su oficio son los factores más deseables para un entorno de desarrollo de software.

Si debe trabajar en un entorno donde los trabajadores del conocimiento son tratados más como trabajadores de fábricas del siglo XIX (como parece suceder en algunos talleres de desarrollo), entonces el poder y el dinero son las principales variables con las que juega la administración. El poder puede variar desde tener una mayor prioridad en la elección de días de vacaciones o asignaciones de proyectos hasta tener la capacidad de contar chismes sobre otros trabajadores.

Este NO es, DE NINGUNA MANERA, el tipo de entorno que recomendaría ni querría operar, pero así es como he observado a los gerentes navegar por ese tipo de tiendas. Por cierto, las tiendas que funcionan de esa manera solo pueden existir cuando hay una ventaja de bajo costo para el medio ambiente. Sin embargo, una vez que la innovación y la creatividad se convierten en factores para ganar negocios, este tipo de entornos generalmente implosionan.

Aquí hay una publicación (y una discusión con Pawel) que puede resultarle interesante sobre el tema de Enseñar a los ingenieros a ser notables .

Lo recomendaría a este video que brinda varias citas que demuestran que para trabajos calificados, el rendimiento en realidad disminuye con el pago. (Sospecho que la parte de "sobrepago" de esa estadística es una pista falsa, pero el punto general sigue siendo bueno). Por supuesto, el pago es solo un tipo de recompensa, pero infiero que el único tipo de recompensa que muchas personas calificadas realmente Lo que quiero es un acceso continuo a problemas interesantes y un reconocimiento ocasional, no exagerado.

La gestión por miedo a las consecuencias negativas se está volviendo obsoleta. Incluso está viendo un uso decreciente en el ejército, que es donde uno pensaría que prevalecería. En última instancia, agrega demasiado estrés, lo que es muy perjudicial para el progreso.

Idealmente, su grupo debería estar lo suficientemente motivado como para que no tenga que proporcionarles recompensas tangibles. Si debe proporcionar recompensas, los complementos son probablemente lo mejor, seguidos de las recompensas relacionadas con el proyecto, como el privilegio de ayudar en la gestión del proyecto. Pero el castigo prácticamente nunca debe usarse con los empleados que le gustaría conservar.

Ni. Para la mayoría de los desarrolladores, lo que se recompensa o castiga se percibe como algo que está fuera de su control, por lo que las recompensas/castigos terminan siendo percibidos como arbitrarios o basados ​​en la popularidad.