Un hombre más sabio que yo dijo: “Puedes hacer que la gente se quede en la oficina 80 horas a la semana, pero no puedes hacer que trabajen más de 40 horas a la semana”.

Ese es el problema con el que te estás metiendo, y no hay nada que puedas hacer.

La gente viene a la oficina porque les pagas. Trabajan porque quieren. Y sabes por qué esta gente no tiene motivación para trabajar.

La forma en que su empleador trata a las personas no beneficia a nadie. Es posible que obtengan horas extras no pagadas de su personal, pero es probable que eso resulte en una baja moral, un trabajo de baja calidad y una alta rotación del personal (junto con el costo/tiempo requerido para capacitar a los reemplazos).

A largo plazo, creo que debe presionar para cambiar la mentalidad de su empleador. Es poco probable que experimenten una iluminación repentina, por lo que deberá eliminarla. Siga llamando a la puerta, señalando los riesgos y problemas con su enfoque y, finalmente, puede llegar a alguna parte. Sin embargo, ten cuidado: tendrás que abordar esto con sutileza porque no quieres que te vean como un irritante. (Además, no sé el tamaño o la estructura de la empresa, es posible que deba consultar a su gerente de línea y pedirle que lo lleve por usted).

( Si la empresa se encuentra en una posición financiera difícil, entonces debe ajustar sus solicitudes en consecuencia. Hay más cosas que dinero, tal vez vacaciones anuales adicionales, tiempo en lugar, la capacidad de terminar temprano un viernes, fruta gratis/ los refrescos pueden marcar la diferencia )

A corto plazo hay mucho que puedes intentar para mejorar el rendimiento del equipo.

• Es posible que la empresa no aprecie sus esfuerzos, pero no hay nada que le impida hacerlo. Decir "gracias" por un trabajo bien hecho, elogiar el buen trabajo y realmente mostrar aprecio cuando alguien va más allá demostrará que reconoce su arduo trabajo. (¡También traer una caja de donas de vez en cuando hará maravillas!)
• Se Flexible. De nuevo, no sé el tipo de trabajo que haces, pero si es posible trata de hacerle la vida más fácil a la gente. Déjelos salir temprano si tienen una cita o necesitan recoger a sus hijos. Creo que si das un poco de holgura en situaciones como esa, la recuperarás el doble cuando los plazos sean ajustados o la espalda esté contra la pared. Se trata de dar y recibir.
• Ayuda de carrera. Chatea con los miembros de tu equipo. Averigüe dónde quieren estar en 5 años. Intente (puede que no siempre sea posible) exponerlos a ese tipo de trabajo. Tal vez esté aprendiendo una nueva habilidad o tecnología, tal vez esté asumiendo un tipo diferente de trabajo (ventas, soporte, gestión de proyectos). Si las personas están aprendiendo y se sienten desafiadas por su trabajo, es probable que se esfuercen más.
• Sea un defensor. Todos los puntos anteriores entran un poco en esta categoría. Necesitas que sepan (o al menos sientan) que, si bien la empresa quiere que los administres, también estás luchando en su rincón. Dígales que aprecia la posición en la que se encuentran, pero también dígales que está tratando de cambiarla. Dígales lo que ha intentado y el progreso que está logrando.
• Comunicar. Continuando con lo anterior, comunica el progreso que estás haciendo. Si escucha algo de la gerencia, decida qué puede compartir con el equipo. Si se sienten involucrados, se sentirán involucrados y, por lo tanto, más comprometidos.
• Supervisar más de cerca. Lo anterior no funcionará para todos. En esos casos, es necesario monitorearlos más de cerca. Sepa en qué están trabajando. Pídeles que se comprometan con un tiempo de entrega (necesitas saber si esto es razonable o si se está completando) y luego verifica regularmente para asegurarte de que cumplan con ese plazo. Si no lo hacen, averigüe por qué. No está apuntando al conflicto, debería ser una discusión del tipo "bueno, ¿cómo puedo ayudarlo a cumplir con la fecha límite la próxima vez?": tal vez el proceso deba mejorarse, tal vez fueron interrumpidos o reasignados, tal vez algo salió mal . Si los plazos se incumplen continuamente, es probable que deba tomar la ruta disciplinaria.

Su trabajo como líder/gerente de equipo es proteger a los miembros de su equipo de la basura que viene de arriba para que sean productivos.

Necesita averiguar POR QUÉ tienen que trabajar horas extras. ¿Son generalmente improductivos o los plazos son poco realistas? Si no son realistas, debe tomar medidas para hacerlos realistas... Involucre al equipo en la elaboración de estimaciones para las escalas de tiempo; y si la gerencia presiona por escalas de tiempo poco realistas, entonces debe presionar para obtener más recursos.

A la gerencia no le gustará que lo diga... a nadie le gusta que la gente retroceda; pero al final pueden preferirlo cuando aumenta la productividad, la gente está más feliz y se cumplen los plazos.

Problema cultural

Creo que la respuesta de Karl Bielefeldt es la mejor, pero me gustaría decirlo con más fuerza: tienes un problema cultural y no tiene nada que ver con China. ¿Su jefe quiere que se corrijan los errores en su software? ¡¡¡Impresionante!!! Hay innumerables ocasiones en mi carrera en las que quise priorizar la corrección de errores, pero la gerencia quería más entrega de funciones.

El verdadero problema que tiene es la actitud de su equipo hacia la calidad del código . En última instancia, este es un problema de madurez. La mayoría de los equipos terminan con un código roto y defectuoso por algunas razones comunes y recurrentes:

• No hay suficiente tiempo/recursos dedicados a las pruebas
• No se dedica suficiente tiempo a documentar y revisar el código
• Demasiado enfoque en la entrega
• Disposición a acumular deuda técnica ilimitada

No es trabajo de su jefe solucionar estos problemas. Estos no son problemas organizacionales o corporativos. Estos son problemas de los desarrolladores , y los desarrolladores deben adquirir la actitud y la estrategia adecuadas para enfrentarlos.

Lectura en frío

Sin saber nada más sobre su empresa, equipo o prácticas comerciales, voy a hacer algunas predicciones:

• Su base de código tiene pocas o ninguna prueba unitaria (cobertura de código <20%)
• Su equipo participa en pruebas manuales (pocas o ninguna prueba automatizada de integración/funcional/aceptación)
• Su equipo pone poco esfuerzo en la revisión del código (o lo trata como un sello de goma, una oportunidad para quisquillosos gratuitos o se salta por completo)
• Su equipo rara vez documenta el código o agrega comentarios triviales (// la siguiente línea imprime un mensaje en el archivo de registro)
• Su equipo no participa en la refactorización regular, o solo tiene 1 o 2 ingenieros que creen que la refactorización es incluso algo útil.
• A su equipo le encanta escribir código nuevo e intenta evitar mantener el código existente como la peste.
• Su sistema carece de métricas automatizadas de éxito (cantidad de transacciones/solicitudes exitosas frente a intentos, cantidad de errores por transacción, cantidad de tiempos de espera, errores del usuario, etc.)

Saliendo del Agujero

Incluso si solo tengo razón en la mitad de las predicciones, eso es suficiente para explicar tu situación. La solución no es más horas extra, ni tratar de convencer a su jefe para que retroceda. Parte del problema es que carece de un fuerte liderazgo técnico en su equipo. Su equipo realmente necesita uno o cinco ingenieros senior que puedan promover prácticas maduras de desarrollo de software que reduzcan los defectos tan pronto como sea posible.

Como puede imaginar, las correcciones prescritas abordarán directamente los defectos que predije anteriormente, junto con una breve descripción de por qué debería invertir en la actividad:

• Pruebas unitarias: creo que el 80% es el mínimo absoluto para una base de código mantenible a largo plazo. Me esfuerzo por alcanzar el 98 % o más, y eso casi siempre se puede lograr. No se trata de marcar alguna casilla en una lista de verificación SDLC masoquista. Primero, no todo el código es fácil de probar. Escribir pruebas contra dicho código obliga al desarrollador a repensar el diseño y la organización del código. Hacer que la unidad de código sea comprobable lo hace mejor. Digo esto como una verdad absoluta, porque creo que lo es, y nunca he visto un contraejemplo. Además, las pruebas unitarias descubren una gran cantidad de errores que finalmente se manifiestan en la producción y, a menudo, de una manera insidiosa y difícil de reproducir. Finalmente, las pruebas unitarias sirven como una especie de documentación de las intenciones del desarrollador cuando el codificador original se ha trasladado a otro proyecto y el mantenedor está tratando de inferir lo que estaba tratando de lograr. Afirmo que las pruebas unitarias siempre ahorran más tiempo de lo que cuestan, razón por la cual los desarrolladores maduros invertirán el tiempo para escribirlas. Desafortunadamente, apostaría a que menos del 20% de los desarrolladores en todo el mundo cuentan como "maduros" según esta métrica. :/ No puede saber qué tan bien lo está haciendo en las pruebas unitarias hasta que implemente un analizador de cobertura de código en su proceso de compilación y coloque los resultados en un "
• Pruebas de aceptación: su equipo tiene muchos errores que corregir porque ha subcontratado las pruebas adecuadas para sus usuarios, y esto hace que su jefe se enoje bastante. Sus desarrolladores son perezosos, creen que otra persona debería hacer las pruebas (como evaluadores dedicados) y claramente no mantienen un conjunto de pruebas automatizadas. Necesita pruebas que se ejecuten en cada fusión, en cada compilación de producción, en cada implementación en cada entorno de prueba y en cada implementación de producción. Desea una amplia cobertura a través de la generación de pruebas aleatorias y una extensa validación de datos dentro de su código. Este es un tema completo en sí mismo, pero también es fundamental para su problema. No necesita escribir miles de casos de prueba para tener un conjunto de pruebas de aceptación útil. Pero sí necesita encontrar un buen marco de prueba, sentirse muy cómodo con él y convertirlo en su nuevo mejor amigo.
• Revisión de código: muchos desarrolladores no obtienen el valor de la revisión de código que está fácilmente disponible. En primer lugar, la revisión del código debería ayudar a mantener un estilo y un enfoque coherentes en todo el equipo. No creo que los desarrolladores necesiten escribir código como si fueran todos clones, al estilo XP. Pero sí ayuda a hacer cumplir algunos estándares comunes, sin convertirse en guerras de formato. Esto se extiende a patrones de diseño y lenguajes de codificación que ocurren con frecuencia en el espacio de su problema. En segundo lugar, la revisión del código es una oportunidad de aprendizaje, tanto para el autor como para los revisores. Es una manera especialmente buena para que los desarrolladores junior aprendan buenas prácticas de los más veteranos (suponiendo que los seniors sean realmente buenos programadores). Los revisores deben hacer muchas preguntas siempre que el código no esté claro y el proceso debe ser colaborativo en lugar de confrontación. Tercero, los buenos revisores a menudo pueden detectar errores simplemente leyendo el código. Esto no sucederá todo el tiempo y no reemplaza las pruebas. pero es unbuen bono , y uno que obtienes "gratis" solo porque te molestaste en pedirle a otras 2 personas que leyeran tu código. Cada fusión debe tener una revisión de código .
• Escribir una buena documentación es pasado por alto por aproximadamente el 95% de todos los desarrolladores, dado mi juicio altamente poco científico. No necesita documentación a nivel de la NASA para mejorar su base de código, ni todos los códigos requieren el mismo nivel de documentación. En general, cuanto más código se reutiliza, más documentación debe tener. Por lo tanto, cualquier tipo de biblioteca/clase/módulo compartido debe obtener documentación adicional, especialmente para cosas como seguridad de subprocesos, seguridad de excepciones, uso previsto, API de funciones detalladas, manejo nulo, etc. El código de la aplicación a medida debe tender más a ser claro y autónomo. documentando Una vez más, no puede saber qué tan buena es su documentación hasta que la genera como parte del proceso de compilación y la publica en un servidor web local. Muchos errores ocurren porque hay suposiciones y expectativas que no coinciden entre los ingenieros (sobre valores válidos para los campos, dónde ocurre la validación, etc.). La documentación ayuda a mitigar este modo de falla.
• Refactorización: esta es una de las cosas más valiosas que puede hacer por las bases de código crujientes que han adquirido una gran deuda técnica. Es quizás el segundolo que debe hacer (¡después de escribir pruebas unitarias, por supuesto!). Para una pequeña empresa o una startup, hay momentos en los que moverse rápido y romper cosas es el curso de acción correcto. Pero eso no puede sostenerse indefinidamente. Si no presiona con fuerza para refactorizar las pausas, su equipo eventualmente caerá por un precipicio de deuda técnica (suena como si se estuviera aferrando a una pequeña rama mientras hablamos). Los buenos ingenieros deberían impulsar la refactorización de todos modos. El hecho de que no haya mencionado ningún remedio defendido por los desarrolladores me dice que carece de tales ingenieros. El código no tiene que ser perfecto la primera vez que lo escribes (y casi nunca lo será). Pero deberías poder mejorarlo cada vez que lo toques. La refactorización debe ser una segunda naturaleza para todo su equipo, y todos deben sentirse capacitados para hacerlo. cuando los cambios son claramente beneficiosos para todo el equipo. Obviamente, desea evitar la refactorización gratuita. Pero dudo que esto sea incluso un riesgo para su equipo.
• Operaciones/métricas: no solo necesita pruebas a nivel de código y externas a su producto, también necesita métricas operativas para ver el rendimiento de su producto. Y estas métricas deben incluir parámetros de calidad (recuento de transacciones, velocidad, recuentos/tasas de errores, etc.). Tu jefe no debería ser el que te exija que arregles los errores. Debe tener sus propios objetivos de calidad definidos por el equipo que lo obliguen a entrar en modo de limpieza cuando se desvíe de ellos.

Próximos pasos

Curiosamente, lo único que no ha mencionado es que su jefe exige que entregue 20 funciones nuevas para la próxima semana, además de corregir todos los errores. Asumo que existe cierta presión de este tipo, pero su fracaso para resaltarlo me da esperanza. Sugiere que tiene espacio para solicitar una pausa en la entrega de funciones mientras su equipo paga la enorme deuda técnica que ha acumulado. Si elabora un plan detallado para su jefe sobre cómo va a mejorar sistemáticamente la calidad de su producto y mantener un alto nivel de calidad en el futuro , entonces quizás encuentre apoyo para dicho plan.

Por supuesto, debe trabajar con su equipo en el plan y aceptar qué pasos serán los más apropiados y efectivos. Y seguramente habrá compromisos que deberán hacerse en todos los lados. Es posible que deba amortizar la refactorización en algunos ciclos de productos, mientras que su jefe puede reconocer la urgencia de crear un conjunto de pruebas decente de inmediato, incluso a costa de la congelación de funciones.

En resumen, creo que su situación es totalmente salvable. Sin embargo, creo que requiere un gran cambio en el pensamiento y la actitud de todo tu equipo. En lugar de ver a su jefe como el enemigo, debe comenzar a pensar en el jefe como un aliado en una nueva era de calidad del software. Y asegúrese de usar el enfoque en la calidad como su munición cuando venda su plan de remediación: "Bueno, nos dijo que desea corregir todos los errores. Tenemos un plan para hacerlo, pero requerirá que se encuentre con nosotros a mitad de camino". . Esto es lo que proponemos..."

¡Buena suerte!

Hay otras formas de aumentar la productividad en la corrección de errores además de trabajar más tiempo. Solicitaría ideas de su equipo sobre eso y les daría tiempo para implementar sus ideas. El empoderamiento contribuye en gran medida a la moral. Para algunas ideas:

• Mejore las pruebas y haga que las pruebas se ejecuten antes de cada fusión.
• Refactorización de código problemático.
• Priorice sus errores para que los importantes se solucionen primero.
• Averigüe qué código causa la mayoría de los errores y asigne tiempo para mejorar su calidad general.
• Utilice herramientas de análisis estático o de pelusa.
• Solucione las advertencias y active -Wall -Werror o el equivalente en su idioma.

Centrarse en los empleados. Asegúrese de tener (mejores prácticas) sesiones individuales semanales para hablar sobre metas más grandes, grandes ideas, desarrollo profesional. Aquí hay un gran recurso, con una combinación de ofertas pagas y gratuitas: hay un valor real en las cosas gratis: https://www.manager-tools.com/

Específicamente, busque información sobre las reuniones "uno a uno".

Tuve una situación hace años en la que mi jefe le informó a uno de mis muchachos que su contrato no se renovaría, dentro de un año. ¿Puedes imaginar? Esto es lo que hice. Me concentré en trabajar con el chico para pulir su currículum. ¿Qué quieres que diga tu currículum? Hagamos algo de eso realidad. ¿Adónde quieres ir desde aquí? ¿Cómo puedo ayudarte a llegar allí? Esto funcionó muy bien, hasta que el chico encontró otra oportunidad, momento en el que prácticamente todo estaba sobre rieles. Pero ayudó inmensamente.

Las reuniones individuales son la clave para relacionarse con su gente, como personas. Por cierto, estas no son reuniones de proyecto o actualización. Este es usted como gerente haciendo un aspecto del liderazgo, una persona a la vez.

Hay un viejo dicho que dice que, por lo general, las personas no renuncian a sus trabajos: renuncian a los gerentes.

Dado que su gente es "simplemente" maltratada, en lugar de ya despedida, tiene más opciones que yo. Asegúrese de que su gente sepa que está haciendo lo que puede para su beneficio, ya sea en este trabajo o en el siguiente.

¿Está utilizando un proceso formal? Supongo por las pistas contextuales y su otra pregunta que usted está a) creando software yb) en China. 'a' es relevante, 'b' puede no serlo, pero tenga en cuenta que vengo de una perspectiva de Estados Unidos/Canadá y puede haber comportamientos culturales/aprendidos que afecten la viabilidad de mis sugerencias o requieran adaptarlas. Estas sugerencias se basan en más de 20 años desarrollando software profesionalmente y habiendo trabajado en compañías que van desde pequeñas empresas emergentes hasta empresas globales masivas y que tienen de todo, desde una administración extremadamente solidaria hasta déspotas que gobiernan por miedo.

1. Si aún no lo está haciendo, comience a realizar un desarrollo basado en pruebas o una solución similar de retroalimentación rápida para informarle de inmediato si las nuevas confirmaciones rompen algo (suponiendo que el paso 0 esté terminado y esté utilizando el control de código fuente, si no lo está). t, implementarlo inmediatamente ). Las pruebas deben ser automáticas y realizarse en cada confirmación.
2. Adopte un proceso para recibir, realizar y entregar nuevos trabajos. Scrum es muy popular. La clave aquí es ser extremadamente transparente sobre cómo estima y entrega, y proporciona comentarios continuos sobre el progreso. Mantenga la línea en lo que puede ofrecer de manera realista: rápido, económico, bueno: elija 2. Como parte de esto, cree una acumulación de errores conocidos y trabaje para reducirlos.
3. Priorizar no introducir nuevos errores. Si el n.° 1 muestra algo roto, arréglelo antes de acumular aún más cambios. Si sigue agregando nuevos errores, nunca se pondrá al día y la productividad nunca mejorará. Y un ciclo constante de errores interminables es una forma segura de drenar la productividad y la motivación.
4. Realice un seguimiento de su progreso: tiempo de entrega, tasa de creación de errores, recuento de errores atrasados, etc. Demuestre a través de datos que cuando el equipo se ve presionado para entregar más de lo que dicen que pueden entregar cómodamente, la calidad del producto disminuye. Celebre las mejoras incrementales y trate los contratiempos como oportunidades de aprendizaje, no como una excusa para repartir castigos.
5. Ayude a los miembros del equipo a reconocer que el trato de la gerencia hacia un empleado no es un reflejo del valor de esa persona. Esto es algo que cada persona de su equipo debe comprender. Están trabajando en un ambiente tóxico y eso tiene un gran impacto en su salud mental. Es posible que ni siquiera se den cuenta de cómo les está afectando hasta que alguien se lo indique.

El último elemento es probablemente el más importante, pero los primeros 4 son los que ayudarán a tu equipo a llegar allí. No puedes obligar a las personas a "concentrarse", al menos no de manera efectiva.

Una observación que he hecho a lo largo de los años es que las empresas dirigidas por propietarios que constantemente interfieren con los profesionales que realizan el trabajo y tratan de exprimir la productividad a través de amenazas de castigo también han tendido a ser las menos exitosas.

Respondiendo a este bit específicamente:

a veces observo que los miembros de mi equipo no trabajan tan concentrados como deberían porque todos sabemos que necesitamos trabajar horas extras nuevamente

Lo que probablemente esté sucediendo aquí es que se han dado cuenta de que no solo están en la oficina hasta que se corrigen algunos errores, sino que están atrapados allí durante la cantidad de horas que la alta gerencia ha elegido, y la cantidad de trabajo que hacen es irrelevante.

Arréglalo estableciendo la meta para el día en que el equipo pueda trabajar: "3 errores más y todos podemos irnos a casa. X, si has terminado tu error, ¿puedes emparejarte con Y para que todos podamos irnos a casa más rápido?" ?"

Pero en realidad, como todos han dicho, tu trabajo es luchar por tu equipo, no explotarlos. El arrastre de características debe retroceder a la siguiente iteración.

Las malas condiciones de trabajo afectarán a sus empleados, no importa quién tenga la culpa.

Lo mejor que puede hacer es convencer a la gerencia de que las horas extra no pagadas son contraproducentes y que la tasa de la que están extrayendo el 'tiempo extra ocasional' según lo que es probable en los contratos de sus empleados podría ser ilegal (depende de la jurisdicción).

EDITAR: Según el comentario de virolino, esto debe hacerse con cuidado . No podemos decirle qué enfoque funcionará mejor con su gerencia porque no los conocemos. Si no puede responder esto usted mismo, puede ser mejor evitar esta opción.

Respondiendo a tu primera actualización:

Por otro lado, si es domingo pero estamos en la oficina trabajando horas extras, ¿cuánto tiempo es aceptable para usar las redes sociales?

¿En un domingo? Yo diría que al menos ocho horas es aceptable. ¡Aunque espero que se aburran antes que eso!

Para empezar, ¿por qué no haces que el trabajo de fin de semana sea más divertido?

Todos tienen que venir a la oficina los fines de semana mientras aún hay errores por corregir, esa es la desafortunada realidad de su situación.

Pero ya sabes que nadie va a poder arreglar ningún bug el sábado y el domingo habiendo trabajado ya de lunes a viernes.

Así que acepte que nadie va a hacer nada de todos modos, seguramente puede pensar en algo mejor que hacer que navegar por las redes sociales.

Puede comenzar jugando juegos de programación como TIS-100 y Shenzhen I/O , competir entre sí por puntajes altos.

Una vez que todos se hayan relajado un poco y se estén divirtiendo, ¿tal vez podrían pensar en un proyecto de programación en el que los diez podrían trabajar juntos? ¿Quizás algunos de ustedes ya tienen algunas ideas?

¡Es el fin de semana! No te están pagando. Así que haz lo que quieras.

Luego, tal vez , si te apetece , durante la última hora de cada sábado y domingo, puedes decir "¡Está bien, muchachos! ¡Tomemos cada uno de nosotros un error y dediquemos la última hora de hoy a solucionarlo!".

Un equipo energizado y motivado arreglará más en una hora que un equipo desmotivado en un fin de semana.

El título de mi otra pregunta puede ser un poco engañoso. El aumento de funciones es una de las razones principales por las que tenemos muchos errores que corregir. ¡Desarrollamos nuevas funciones en nombre de la corrección de errores!

¿Cómo estás trabajando? Parece que tiene una nueva lista de funciones a la que se sigue agregando, que es en lo que trabaja durante la semana; y una lista de errores que también sigue creciendo, que es en lo que trabajas durante los fines de semana.

Si puede corregir la lista de errores, entonces ya no necesitará venir los fines de semana (por mucho que desee después de implementar el último bit ;-))

Divide tu trabajo en sprints. Planifica cada uno con tu equipo. Priorice la corrección de errores sobre el desarrollo de nuevas funciones. Haz retrospectivas. Todas las cosas buenas en la respuesta de Lawnmower Man , básicamente.

Pero solucione primero el problema de la moral para que el equipo vuelva a estar al día.

Creo que nadie ha abordado lo siguiente hasta ahora: las personas se enfocan en "no hacer" (que apoyo completamente) o se enfocan en algunas prácticas de codificación.

Si no puede abolir por completo las horas extraordinarias no pagadas (como vienen de arriba), ¿qué puede hacer?

• ¿Puede proporcionar horarios de trabajo flexibles? "Chicos y chicas, lo sé, necesitamos trabajar 80 horas a la semana, pero en mi equipo puedes ir y venir cuando quieras, solo necesitas marcar esas horas, porque no puedo cambiar esto todavía".
• ¿Tiene fondos para compensar? Algún vudú financiero podría estar en tus manos. "Lo sé, la empresa no paga las horas extra, pero cada empleado de mi equipo recibe una bonificación de 1000 dólares si eliminamos 100 errores para fin de año".
• Obtenga una compensación no monetaria, a la Google lo hizo para mantener a la gente en la oficina por más tiempo. "La gente que hace horas extra recibe tres comidas gratis, obtiene un pase para el gimnasio interno y puede visitar a un terapeuta gratis en las pocas horas no laborales". Exagero, por supuesto.
• Cosas que no se me ocurrieron, pero apoya a tu equipo de todas las formas posibles. Consígales computadoras más elegantes. Muévalos a una oficina mejor. Cortar la garganta del gerente superior y abolir las horas extras no pagadas. Tales cosas.
• Si todo falla: renuncia con todo el equipo y encuentra un nuevo trabajo / lanza una startup.

¿Cómo puedo administrar a mis miembros para mantener una productividad razonable cuando mi empleador no trata bien a los empleados?

La última mitad de la pregunta es irrelevante. Si los empleados no están siendo productivos, disciplínelos ya que otros enfoques no han funcionado. Si no está preparado para disciplinar, entonces está fallando en su rol.

Adivina quién es el peor y disciplínalo primero para animar a los demás.

Es posible que tengas que repetir esto varias veces. Mientras tanto, vea qué puede hacer con el jefe en términos de hacer algunas concesiones a la moral del personal, siga repitiendo eso también. No socave a su jefe ante los trabajadores, pero haga lo mejor que pueda por ellos y por sus responsabilidades.