Si las reuniones son abundantes y lo suficientemente largas como para causar problemas de productividad con los ingenieros de software que no están liderando equipos grandes, usted tiene demasiados, haciendo que la lista de asistentes requerida sea innecesariamente amplia, no preparándose lo suficiente de antemano por lo que son demasiado largos, tienen una mala arquitectura de software , son microadministradores, etc. La necesidad de un miércoles sin reunión en tal situación indica un problema.
Las reuniones son necesarias cuando se requiere una conversación en tiempo real entre los interesados. Cuando hay varios problemas y las partes interesadas para todos los problemas no coinciden exactamente, debe tener varias reuniones y dejar que el resto de su grupo trabaje. Cuando surge un problema tangencial durante una reunión que no está en la agenda, es para discutir en otra reunión donde la lista de invitados puede ser más corta y la reunión puede seguir inmediatamente. Cuando tenga información para compartir, el correo electrónico unidireccional (quizás unidireccional de muchas personas) funciona mejor. Algunas cosas bidireccionales consumen menos tiempo de las personas por correo electrónico una vez que se interrumpe la sobrecarga y se consideran los efectos secundarios, como una especificación funcional bien especificada que cumple con una API propuesta que se correlacionará con una buena implementación.
Son convenientes para los jefes que desean interactuar individualmente con sus subordinados en un intervalo de tiempo, pero eso no es lo mismo que sea necesario. Como líder, debe poner a los accionistas en primer lugar y minimizar el impacto total en su personal y sus efectos en la programación / productividad.
Mi única reunión periódica es buena y ocurre una vez por semana y dura menos de una hora.
Esa reunión de productos incluye al CTO, vicepresidente de ingeniería, gerente de producto, director de ingeniería de software, líder de prueba, líder web, gerente de soporte, ingeniero de ventas, operador de operaciones y yo como líder de ruta de datos. Cubrimos cualquier cosa que no sea crítica en nuestro radar, despliegues de características que ocurrieron o sucederán y que nos afectan a todos, herramientas que construimos que serían generalmente útiles, etc.
Según sea necesario, me reúno con el subconjunto requerido de personas en pruebas, marketing, ingeniería de software, etc.
El resto del tiempo hago el trabajo.
En una startup pasé aproximadamente 1/3 de mi tiempo reuniéndome con personas; pero eso estaba bien porque tenía doce de nosotros trabajando en proyectos algo compartimentados. Si tuviera un problema con la interacción vertical a través del coordinador de E / S, el almacenamiento persistente y la administración de clústeres, hablaría con esos tres tipos. Para las interacciones del iniciador SCSI con el coordinador IO, la lista de invitados sería esas dos personas y yo. Para todas las reuniones puse una agenda en la pizarra y puse todo lo que no estaba en la lista para más adelante. Utilizamos el correo electrónico para las comunicaciones unidireccionales, como las actualizaciones de estado semanales de las personas que luego podíamos leer cuando ya estábamos interrumpidos.
En otra, pasé 1,5 horas al día con SCRUM mal hecho. Esa productividad realmente limitada.