¿Cómo puedo fomentar una cultura de la puntualidad en una empresa de software?

**El mejor factor de motivación es la confianza. La unidad del equipo es de suma importancia para lograr tus objetivos. La cultura de las reglas se nutre de la desconfianza, y los palos y las palancas para hacer cumplir las reglas sólo erosionarán aún más la confianza de tu equipo.

• En lugar de preocuparse por los tiempos exactos y las culturas informales, intenta averiguar cuáles son los valores intrínsecos.

• ¿Las 9:30 (o cualquier hora arbitraria) realmente importan? O es que tu equipo necesita asegurarse de que no están obstaculizando el trabajo de otros equipos por su ausencia?

• ¿5 minutos hacen una diferencia? Or ¿es lo más importante que todos los miembros se unan a la postura diaria?

• ¿Es la informalidad un problema? **

• ¿Es la flexibilidad un beneficio?

• Yo cavaría en el núcleo del problema, que es que su equipo no se ha creído la idea. Ver dónde está la desconexión, pero evitar la creación de una cultura de reglas. Enviarlos a casa por llegar tarde (una táctica disciplinaria que encontrarías en una escuela primaria) hará que tu equipo crea que los ves como niños en los que no se puede confiar.

Crear una cultura de la puntualidad puede llevar tiempo y puede ser algo que hay que comprometer de alguna manera. Ya que estás tratando con trabajadores del conocimiento inteligentes, tendrás más éxito si consigues que se adhieran al plan. En lugar de concentrarse en el tiempo, concéntrese en el problema creado por los problemas de programación.

Presente el problema como un desafío para el equipo y vea lo que se le ocurre. La respuesta puede ser horarios establecidos o puede ser algo diferente que resuelva el problema. Puede ser que los lunes, miércoles y viernes sean los días de las 9 de la mañana, mientras que los martes y jueves son los días flexibles. Aunque el plan no sea perfecto ni sea exactamente lo que usted imaginó, encontrar un punto medio en algún lugar que haga feliz tanto al equipo de desarrollo como a la solución del problema real evitará que su personal se amargue y le vea como el enemigo.

Tenga en cuenta que no se trata de un proceso de fabricación en el que todo el mundo debe presentarse exactamente a las 9:30 am, cuando suena el silbato, para que puedan comenzar la adormecedora tarea de ensamblar los mismos pequeños artilugios de plástico repetidamente, hasta que el silbato suene de nuevo, y el personal adormilado se dirija al bar local para la hora feliz.

Mi equipo no se presenta a tiempo. He tratado de obligarlos y no funciona.

Forzar a la gente inteligente nunca funciona. Debes recordar que estás tratando con gente altamente educada, inteligente y creativa que es buena para resolver problemas complejos, abstractos y únicos. Estas personas, al menos las realmente buenas, nunca seguirán ciegamente las órdenes. Esto se remonta a poner el problema en sus manos, al menos al principio. Si no hacen nada, entonces querrán intervenir con su propia solución.

Mencionaste que eres un nuevo jefe de equipo. Entrar en una nueva posición como esta es desafiante y estresante ya que no estás seguro de cómo ganar el respeto del equipo y también ser un buen líder. Esto viene con la experiencia, y es común que los nuevos líderes de equipo sin experiencia intenten “obligar” o forzar a la gente a hacer las cosas a su manera. Esto no es liderazgo.

Los desarrolladores, y otros trabajadores del conocimiento, no necesitan un gerente; en cambio, necesitan un líder. Los grandes líderes inspiran a otros a hacer grandes cosas, y esta es su oportunidad de llevar a su equipo a la grandeza en lugar de dictarlo a la desesperación.

Las investigaciones muestran que las personas son más propensas a comprometerse cuando han participado en la determinación de cuál será la solución en lugar de que se les diga esa solución, y esto es especialmente cierto con los trabajadores del conocimiento.

Para la inspiración, por favor vea la entrevista de Seth Godin sobre la Diferencia entre el liderazgo y la gestión . Recomiendo encarecidamente que todos y cada uno de los que tienen capacidad de liderazgo vean esta breve entrevista.

En mi experiencia, a los trabajadores del conocimiento no les gusta que les dicten políticas para las que no ven ningún propósito. Usted declara un propósito, pero los empleados que dirige parecen pensar que no es uno bueno. Además, es probable que haya alternativas que usted no haya considerado, y dado lo que suena como un asunto “dictado desde arriba”, es posible que sus empleados no hayan pensado en ellas, que no se sientan cómodos proponiéndolas, o que sientan que simplemente serían rechazados.

Si la única razón por la que usted está implementando la política es por la tensión con la gente de otros departamentos, es su trabajo manejar esa tensión para que su gente pueda trabajar de la manera más efectiva. Sin embargo, no creo que esa sea la única razón. Por ejemplo, ¿qué pasa si se necesita un desarrollador para arreglar un problema urgente de producción que ocurre a las 8:00 o 9:00 o a cualquier otra hora? Sin embargo, es poco probable que necesites a todos tus desarrolladores presentes para arreglar ese problema. ¿Y si tuvieras un horario rotativo (a menos que alguien se ofrezca como voluntario) “temprano”, de modo que cada desarrollador se turnara para estar presente a las 8:00 (o 9:00, etc.)? Esa solución parece más probable que satisfaga tanto las necesidades de la empresa como los deseos de sus empleados. Todo el mundo “comparte el dolor” (o lo inflige a alguien a quien no le importa). La gente puede venir a trabajar la mayor parte del tiempo cuando sienten que serían más productivos. Esta es sólo una posibilidad, pero puede generar una discusión con sus empleados sobre cómo resolver los problemas reales y satisfacer los intereses de todos aquí.

Si elige ir por la ruta más disciplinaria, y el tema de la “hora de inicio” es realmente importante para sus desarrolladores, perderá sus buenos trabajos por otros. Es probable que sus empleados se sientan inseguros en sus trabajos (¿qué pasa si algún día ocurre una emergencia real que haga que alguien llegue tarde?). Además, esto puede verse como un cambio en la dirección de la gestión en la dirección equivocada (desde la perspectiva de sus empleados), ya que anteriormente tenían experiencia trabajando bajo otra persona.

Depende de usted, por supuesto, pero le insto a que dé un paso atrás y se esfuerce por ver la situación desde la perspectiva de sus empleados. Tienes un trabajo que hacer, por supuesto, pero creo que hay soluciones que satisfacen mejor los intereses de todos que la que tú propones.

La respuesta precisa a tu pregunta es despedir y reemplazar a alguien que no entiende el mensaje y luego despedir a cualquier otro que no lo entienda.

No espero que esto ayude a tu carrera o a los objetivos de desarrollo de tu compañía pero has decidido que este es el tema y parece que no hay nada que te convenza de lo contrario. Así que así es como se hace.

Más constructivamente, te sugiero que consideres lo siguiente:

• Tus desarrollos tuvieron un tiempo flexible. Ahora quieres quitárselo

No importa si es un beneficio oficial en alguna póliza escrita o no. Es una política de facto y parte de la cultura establecida. La vida y los horarios de la gente se han establecido alrededor de estas horas. Y para los devs como yo, que prefieren esquivar la hora punta y que tienen un horrible y desagradable caso de SAD en el invierno, pero no pueden pensar en ningún lugar amigable para los devs más cerca del ecuador en el que preferiría vivir, es tan importante como obtener beneficios para la salud.

• ¿Cuál es la naturaleza de esta “angustia” que mencionas? ¿Es a) principalmente celos o b) problemas legítimos de comunicación interdepartamental como la dificultad para programar reuniones/comunicación general.

a) Los devs no necesitan interactuar con los clientes u otros negocios. En mi experiencia, cuanto más rígida es la estructura de la compañía, más mediocres son los devs. Mientras que gran parte del desarrollo es un juego de tuercas, también es un proceso creativo de resolución de problemas que requiere que la gente esté en su mejor momento. También es un proceso impredecible impulsado por los plazos que resulta en horas muy, muy tardías a veces. Un efecto secundario de esto es que los desarrolladores a menudo reciben el tratamiento “creativo”. En una compañía de 30 personas no debería ser difícil insistir en que la gente sea adulta acerca de los empleados que necesitan estar en su mejor momento cuando están presentes y es probable que finalmente dediquen muchas más horas en el transcurso de un año que un 9-5 que normalmente está empacando sus cosas a las 4:55 p.m. todos los días.

b) En una compañía de 30, no deberías tener tantas reuniones que esto se convierta en un problema. Sin contar cosas como las reuniones de sprint u otras sesiones de planificación bimensual, atar a tus devotos durante más de 30 minutos cada día en las reuniones es un absurdo y un desperdicio de dinero totalmente incompetente. Lo mismo ocurre con la comunicación en general. 30 personas significa que te acercas al otro tipo y le hablas. En escenarios de tiempo flexible es razonable establecer un lapso de tiempo en el que todos están en la oficina al mismo tiempo. No se me ocurre una buena razón para que ese lapso sea de más de 3-4 horas de la jornada laboral y por qué no debería ser lo más cercano posible al medio del día.

• ¿Por qué un stand up matutino?

¿Por qué es que la primera idea de gestión de los desechos de scrum, ágil, etc… es siempre el consejo de que no tienes el stand up en primer lugar? En la programación se tarda un tiempo en volver a la plena conciencia de todos los detalles y cuestiones que estás tratando en un problema determinado. Cuando haces “stand up” lo primero, tus devs no van a tener la cabeza completamente atornillada. Los standups son críticos para la comunicación y la mejora de la eficiencia, no es algo que se haga primero para “quitarse de en medio”.

• ¿Están tus devs fallando en su trabajo?

• Si no, ¿por qué se meten con algo bueno? No es su trabajo comunicarse con las otras preocupaciones de la compañía. Es el suyo. En una estructura de gestión sana, su responsabilidad es con su gerente inmediato y la gente que dirige, no con las uvas agrias de otros departamentos que tienen que estar allí a una hora más típica por razones prácticas.

Lo primero que tienes que hacer es ir a leer “Peopleware”

Es un error tratar de cambiar esto ahora. Yo era un gerente en una empresa donde teníamos un horario de trabajo bastante flexible. Uno de nuestros desarrolladores más productivos llegó a las 11 de la mañana. Se reportó conmigo por un tiempo. Me dijeron que le hiciera cambiar su horario. Luché contra esta petición. Con fuerza. Fui rechazado.

El resultado:

Un desarrollador menos productivo, menos interesado que era un gran colaborador del equipo. Se volvió mucho menos productivo y útil para el equipo.

Todo por una tonta noción de “a tiempo”.

Concentrarse más en la productividad.

Su trabajo como gerente es eliminar las barreras a la productividad - no hacer que todos se vean, se sientan y actúen igual.

Los horarios flexibles son una ventaja - y un empleador que permite horarios flexibles puede atraer más gente de calidad.

Como “nuevo líder técnico” no hay manera de que pueda cambiar la cultura pronto. Especialmente en la dirección que pareces querer. ¿Has hecho algo para mejorar los roles/trabajos de tu equipo?

Trabaja en la construcción de la confianza con ellos primero. Muchos gerentes/líderes primerizos cometen errores como este.

**Averigua lo que los otros grupos REALMENTE necesitan. No “tienen que estar aquí a las 9:30”. Averigua realmente cuál es el problema. En lugar de decirle a su equipo lo que tiene que hacer, explíqueles el problema y pídales que le den sugerencias y comentarios. ¿Cuál es el verdadero problema subyacente?

He tratado de obligarlos y no está funcionando.

Hay una razón para eso. Y parece que no estás escuchando. Alcanzar medidas más drásticas y martillos más grandes no va a mejorar la situación. Intenta el enfoque de la “zanahoria” en lugar del enfoque del “palo”.

De nuevo, lee “Peopleware”.

No vas a llegar lejos con ideas como reuniones diarias o enviar gente a casa o con la noción de que son tus secuaces que necesitan hacer lo que dices, “o si no”.

¿Quién te dice que tienen que estar en el trabajo a las 9:30? ¿Otros grupos? ¿Tus jefes? ¿Ustedes? Averigua el problema REAL y encárgate de eso. Cuando ellos aparezcan NO debe ser el problema.

Independientemente de por qué lo haces, para los miembros de tu equipo es como si les quitaras una ventaja. Para algunos de ellos puede ser incluso una de las principales razones por las que están trabajando para tu compañía en lugar de otra.

Esencialmente, les estás pidiendo que acepten una reducción en su paquete de compensación total.

Es posible convencerlos de que lo acepten, pero necesitarás buenos argumentos y casi seguro que habrá un resentimiento persistente por ello. Puede que pierdas o no a buenas personas por esto.

Por tu descripción la razón principal parece ser los celos de otros departamentos. ¿Ha considerado dar a los otros departamentos el mismo beneficio?

En resumen: No lo haga a menos que piense que vale la pena perder a algunos de ellos por esto.

Para cambiar tu cultura tienes que darte cuenta de por qué estás experimentando resistencia y luego manejar la causa de la resistencia.

En mi experiencia, la “coordinación con otros departamentos” tiende a ser la provincia de aquellos con títulos de posición más altos y encabezados por una pista de gestión de proyectos/personas. Los desarrolladores de trabajo diario interesados sólo en el código tienden a estar protegidos de esto. En tiendas más estructuradas, pueden no hacerlo en absoluto y en tiendas más pequeñas, pueden hacerlo de manera más informal.

Te guste o no, has heredado una cultura de horario flexible, lo cual es una gran ventaja para la mayoría de los desarrolladores. Quitarles eso en uno de tus primeros actos como líder no sólo les parecerá tiránico (cuando les explicas que las 9:30 no es que temprano, les estás imponiendo tu propio horario, de forma arbitraria en su opinión), sino que es, de forma realista, la substracción de una ventaja sustancial. Puede que te guste trabajar con un horario determinado y no consideres que sea una ventaja significativa, pero probablemente lo consideren inestimable. Considéralo a la par que les dices que les quitas una semana de vacaciones o les reduces el sueldo en un porcentaje.

Para cambiar eso, puedes usar la zanahoria o el palo. Hablas de usar un palo y, tal vez, un palo más grande. Si sigues ese camino, planeo contratar a algunos nuevos desarrolladores, ya que supongo que algunos de tu equipo van a empezar a hacer entrevistas en otras compañías. Yo personalmente iría por la ruta de la zanahoria con el fin de conseguir compra para eliminar este beneficio dejando claro que las futuras promociones y avances serán decididos por aquellos que “coordinen con otros departamentos”. Es decir, los líderes/gente importante llegan temprano, trabajando con otros equipos, asumiendo responsabilidades, etc. Los “novatos” obtienen el beneficio de la flexibilidad, pero la gente que se toma en serio el avance llega a tiempo.

Si creas esa cultura, sospecho que algunos de tus devs empezarán a llegar a tiempo por su propia cuenta. Tanto por el interés en el avance como por la percepción de que “la gente importante llega temprano”.

No te envidio esto, como compañero de dirección, sería difícil para mí. Y honestamente, creo que vas a perder gente por ello. Creo que tienes un solo síntoma que proviene del cambio de cultura de Start Up, y no todos los desarrolladores van a hacer este cambio con éxito. Creo que necesitas estar preparado con las descripciones de los puestos y el conocimiento de cómo abrir las solicitudes de trabajo y creo que necesitas poner énfasis en la capacidad de contratar a nuevas personas y mejorar la documentación…

Lo siento, eso es tan sombrío. Pero no creo que tengas una situación de problemas de confianza, o un caso en el que puedas explicar fácilmente a la gente que está de acuerdo. Y realmente no hay compensación que equilibre perfectamente la enorme flexibilidad en el trabajo.

Estoy de acuerdo en que estás quitando un beneficio. La flexibilidad en la hora de inicio es un gran problema para algunas personas, y habla de una cultura informal que puede ser una fuerte preferencia para algunas personas. Presumiblemente a medida que la compañía ha crecido, la carga de trabajo se ha vuelto más confiable, la seguridad laboral ha mejorado, el respeto por el producto ha aumentado, y puede que hayas podido ofrecer algunos planes de acciones ingeniosos, aumentos de sueldo u otras mejoras. Si nada de eso es cierto, entonces te tienes que preguntar si tienes una empresa en crecimiento y próspera o una empresa que se hunde en la desesperación.

El truco es que la gente a menudo no puede conectar los puntos entre estos nuevos valores añadidos y la eliminación de la ventaja favorita. Puedes intentar explicarlo, pero para algunas personas esto no es un buen intercambio, y este no es un caso en el que puedas ofrecer la opción. Es un “mi camino o la autopista”, ya que tiene un impacto organizacional que no necesariamente se puede sentir dentro del equipo, pero que es experimentado y apoyado en los niveles más altos de la compañía.

Suena como si hubieras hecho las cosas correctas:

• lo has expuesto claramente

• has hablado sobre la razón y la necesidad de cambio

• te has comprometido uno a uno (y sigues haciéndolo, supongo) para arreglar los casos individuales a medida que van surgiendo

• has dado retroalimentación

Creo que has llegado al “¿lo dice en serio? "donde se demuestra a la gente que eres serio, y que esto realmente necesita cambiar. Mi opinión personal es que llegar 5 minutos tarde a una oficina en mi región no es gran cosa y que las reuniones de corta duración (como las reuniones de pie en un sprint ágil) no deberían ser tan bruscas al comienzo de la jornada laboral como para que una conexión de autobús perdida o un mal tráfico sea un problema habitual. Pero esto es algo regional - diferentes locales tienen grandes variaciones en la situación del tráfico. Así que eso es tanto conocer tu región y saber por las quejas individuales lo que es razonable.

El resto es sólo llegar a un mecanismo que es lo suficientemente debilitante como para probar que eres serio. Un día de pago de la multa es una opción y está dentro de sus derechos legales - aunque cualquier mecanismo que se me ocurra, lo haría a través de los abogados. También lo es un sistema de advertencia formal que lleva a una acción disciplinaria. Asumiría que tu departamento de recursos humanos podría tener sugerencias…

Mucho depende de lo que el trabajo pueda tolerar - cuando envías a alguien a casa, también pierdes ese día de trabajo, lo que impacta en tu costo y horario. Cuando tienes un sistema de advertencia que lleva a una acción disciplinaria - incluyendo el despido - te ahorras el resto del día de trabajo, pero te arriesgas a tener que despedir al empleado.

Creo que la cosa es que, cuando se trata de castigos, tienes que estar preparado con un castigo lo suficientemente perjudicial como para ser tomado en serio y para conducir a casa el punto de que "no estás haciendo tu trabajo si no estás haciendo esto”.

La respuesta corta es que NO debes hacer esto. Los miembros de su equipo técnico son (o al menos, deberían ser) lo suficientemente inteligentes como para saber que no hay ningún beneficio tangible en tener a todos presentes en la oficina en un momento arbitrario; la _única métrica importante es si su trabajo se hace o no.

Si su equipo no está haciendo su trabajo, entonces es un tema aparte. Pero si ellos están haciendo las cosas, entonces ¿por qué los acosas sólo porque otros departamentos te han estado acosando?

Parte de tu papel como líder es aislar a tu equipo de las distracciones triviales y las críticas provocadas por fuentes externas. Si su reacción a las quejas de los demás sobre los miembros de su equipo es pasar las quejas a los miembros de su equipo y/o dictar cambios basados únicamente en esas quejas, entonces está fallando en su trabajo. Yo sugeriría que, suponiendo que su equipo está haciendo su(s) trabajo(s) (lo cual parece ser el caso, ya que usted no se queja de su productividad), una mejor manera de responder a esas críticas es decirle al quejoso “sí, bueno, mis chicos trabajan duro y dan resultados sólidos de forma consistente, y eso es lo único que importa; así que ¿por qué no deja de preocuparse por cómo mi equipo maneja sus tareas y vuelve a las suyas? ”.

Y por supuesto, si usted sigue con una política obligatoria de “debe estar en la oficina a la hora X”, es justo complementarla con una política de “debe salir de la oficina a la hora Y”, y una política de “no debe trabajar desde su casa fuera de las horas normales de trabajo”. Eso es justo como una forma de proteger el equilibrio entre el trabajo y la vida de su empleado, ya que apuesto a que muchos de los miembros del equipo que tiene y que no se presentan hasta las 11:00 probablemente se quedan hasta tarde o hacen tiempo extra en casa.

Parece que hay una desconexión aquí entre la forma en que sus desarrolladores ven el tema, y la forma en que los otros departamentos (o sus superiores, o quienquiera que sea el que realmente está exigiendo este cambio) ven el tema. Sugeriría que se intente salvar esa brecha, en múltiples etapas si es necesario.

En primer lugar, ¿están de acuerdo los desarrolladores en que hay buenas razones para este cambio? Si no están de acuerdo, ¿tienen algún buen argumento en contra, o sugerencias alternativas? Si es así, debería llevarlos a la dirección y ver si suavizan el requisito de tiempo o si pueden explicar por qué las alternativas no funcionan y los argumentos en contra no resuelven el problema, para que pueda volver a sus desarrolladores y darles una explicación más completa. Continúe el vaivén tanto tiempo como sea necesario/productivo.

Si llega al punto en que los desarrolladores están de acuerdo en que hay buenas razones pero simplemente no están dispuestos a adaptarse, o no creen que las razones sean buenas y se resienten con la idea, comunique eso a la dirección. Explique que usted podría forzar a los desarrolladores a hacer lo que se quiere, pero eso causará resentimiento, menor motivación, muy posiblemente menor productividad o incluso que los empleados se vayan. Asegúrate de que la dirección lo entiende y sigue estando de acuerdo en que es importante hacer cumplir la hora de inicio (y de nuevo, comunícaselo a tus desarrolladores), de lo contrario puedes acabar siendo responsable de un cambio que ha hecho perder a la empresa más de lo que ha ganado.

(Nota personal: He estado en la posición de que me digan que entre a una hora determinada porque, en lo que respecta a los empleados, no hay una buena razón, y es realmente extremadamente poco motivador. Es muy importante asegurarse de que la gente entienda las razones y no se sienta como si cambiara la política por capricho o porque no confíe en ellos.)

Solía trabajar en una organización sin fines de lucro que tenía este problema. Las reuniones siempre empezaban tarde, 10 minutos tarde se convirtió en un “estándar”.

Entonces conseguimos un nuevo director de proyecto para un gran proyecto clave (y uno en una línea de tiempo fija). Ella convocó la primera reunión. La gente entraba como siempre, minutos tarde y charlando casualmente. Se sentó en su silla y no dijo nada - nada en absoluto - durante varios minutos. Eventualmente la charla “se calmó” hasta que hubo silencio. Todos estábamos esperando que nos escucharan para hablar. Ella permitió que el silencio continuara por un poco más de tiempo. Miró a su alrededor y dijo: “Tengo que dejarlo claro. Las reuniones empiezan a tiempo. Si vas a llegar 5 minutos tarde, no te molestes en venir, sólo veme después. OK, ahora para el proyecto que estamos haciendo esta semana [lo que sea]…”. Esto causó una GRAN impresión y la gente hizo un gran esfuerzo para llegar a tiempo a sus reuniones.

Nota: Añadida respuesta adicional abajo.

Contabilizar el trabajo hecho a distancia.

A menudo los más altos productores hacen una gran parte de su trabajo a distancia de todos modos, por lo que a veces dedican tanto tiempo a distancia como en la oficina. Este es un punto importante para considerar y comunicarse con los otros departamentos. Esa comunicación debe ser sutil. No llames a una reunión, sólo empieza a buscar formas de mostrar “sí, Joe estuvo despierto hasta tarde anoche trabajando en la X” y “sí, Mary arregló que el domingo estuvo despierto ‘hasta como la medianoche’.

Habla abiertamente sobre el viaje. Si alguien viene a las 10.30, su viaje puede durar 15 minutos. Si necesita llegar a las 9 o 9.30, su viaje puede ser de una hora. Además, sería lo mismo ir a casa si trabajara 8 o 9 horas. Mucha gente siente que esto es un gran desperdicio de su vida. Prefieren trabajar a distancia por un tiempo y luego venir después de eso. Busque integrar este hecho con sus necesidades cuando establezca los horarios y asegúrese de que otros departamentos también lo sepan, nuevamente mencionándolo frecuentemente.

Asegúrese de usar tecnología para ayudar. Por ejemplo, yo trabajo virtualmente, el 100% del tiempo. Por lo tanto, tener Skype activado, mostrar mi estado de conexión, una cámara de video, etc. también puede ayudar.

Habiendo estado en situaciones similares, aunque reconozco que en menos tiempo que la OP, sólo tengo esto que decir sobre el estado de su situación:

La solución más práctica y simple…

…sería intentar empezar las reuniones a las 11 en su lugar. No te preocupes, no te estás “rindiendo”. En su lugar estás redirigiendo el flujo de manera muy parecida a los principios detrás de Aikido . La idea es centrarse en permitir que tu equipo haga cosas importantes ya que es el punto más importante porque realmente hay un problema serio que necesita ser abordado:

El equipo realmente NO tiene ni idea de lo que pasa con los otros departamentos y lo que REALMENTE necesitan hacer.

Tener a tu equipo para que se presente a las 9:30 lo cual puedo admitir que no es temprano no es sin embargo una solución a este problema. Lo has intentado y has fallado, así que deja de insistir en hacerlo. Deja de golpearte la cabeza contra una pared de ladrillos. Mi único consejo aquí es siempre valorar la comunicación por encima de las reuniones arbitrarias.

Como los otros departamentos empiezan a las 8 puedes usar esta reunión tardía del equipo para tu propio beneficio. Entre las 8 y las 11 tienes 3 horas para ayudar a tu equipo con las actividades de gestión de proyectos como (sin ningún orden o prioridad particular):

• Ir a las reuniones y reunir los objetivos y requisitos de los otros departamentos
• Averiguar lo que se terminó desde ayer
• Gestionar las expectativas y compromisos con los otros departamentos sobre lo que se necesita y se puede hacer durante el día de trabajo
• Entregar buenas y malas noticias a los otros departamentos
• Actualizar cualquier plan relevante para el equipo si hay alguno
• Averiguar qué problemas de código y arquitectura de software necesitan tener atención hoy
• Decir “NO” a las peticiones que no proporcionan ningún valor comercial
• Aceptar las críticas de los otros departamentos y disculparse con la seguridad de que los problemas se arreglarán
• etc. (siempre hay algo que debe ser abordado)

Y por último antes de la reunión resumir un breve para el equipo sobre lo que está pasando, con el fin de darles un poco de conocimiento de la situación. Cuando la reunión comienza a las 11 y todos están frescos para empezar a trabajar tienes información y un protocolo de reunión preparado para ellos. Puedes tener el resumen y las minutas de la reunión escritas como un boletín y enviarlo por correo electrónico en algún momento después de la reunión como un gentil recordatorio.

Durante la reunión con el equipo necesitas dos cosas de ellos:

• Pedir estimaciones para las tareas que se necesitan hacer, especialmente las que son de alta prioridad. No tiene que ser preciso, como en minutos. Con esto puedes decidir compromisos y plazos mucho más claramente con los otros departamentos. Si no pueden dar ninguna estimación para una tarea, pídeles que la resuelvan durante el día o al día siguiente.
• Pide impedimentos o si necesitan ayuda con cualquier cosa, escríbelo y procura que esos asuntos se puedan arreglar y que se arreglen.

Después de un tiempo probablemente puedas pasar gradualmente a tener las reuniones más temprano. Pero al principio ir a contracorriente no es el camino a seguir y sólo conduce a un cultivo aún más infeccioso (en el que la única forma de reparar es reemplazar todo el equipo). Si son, como usted dice, “primadonnas” entonces su verdadero trabajo es convertirlas en impresionantes primadonnas que entreguen con alta calidad. Está claro que su equipo tenía y quiere autonomía, así que empiece a explotar esa cultura en beneficio de los objetivos de su empresa.

Cuando hayas logrado hacer un equipo confiable, a través de la comunicación en lugar de la coerción, puedes salir tres horas antes que todos los demás en el equipo sabiendo que están haciendo su trabajo (pero aún así estar de guardia si la mierda golpea el ventilador). Ahora esa es la confianza con la que puedes contar.

Los demás plantean muchos puntos buenos sobre cómo manejar la situación; sin embargo, al final del día, si el horario de su grupo está perturbando a otros en la empresa, entonces debe corregir el problema y asegurarse de que las cosas funcionen sin problemas. Teniendo esto en cuenta, debes averiguar cuándo otros grupos necesitan un acceso fiable a los desarrolladores y si hay algún margen de flexibilidad en ese horario. Si otros grupos necesitan acceso a los desarrolladores cuando están en la oficina de manera impredecible, entonces un segmento central de desarrolladores debe asegurarse de que esa necesidad sea atendida. Si esto significa que algunos desarrolladores tienen que estar en la oficina en períodos de tiempo fijos, entonces es lo que es.

Con respecto a mover a los desarrolladores a algún tipo de horario de disponibilidad fijo, su mejor apuesta es asegurar que cualquier “horario duro” sea suavizado tanto como sea posible. Por ejemplo, si las “horas centrales” son de 11:00 a 15:00 entonces también puede asegurarse de que las horas centrales del viernes no están presentes y el viernes es un verdadero día de horario flexible. Como el martes, miércoles y jueves son tradicionalmente considerados los días más productivos de la semana, usted podría hacer que las horas principales se apliquen a esos días y permitir que el lunes y el viernes sean también días completos de horario flexible.

En términos de asegurar que las horas se cumplan, si la dirección viene desde arriba y es aprobada por la alta dirección entonces, en última instancia, los desarrolladores deben adherirse a ella como parte de su empleo. Usted debe hacer lo que pueda para asegurar que se introduzca gradualmente y si algunos promotores tienen un horario flexible escrito en su acuerdo de empleo, debe ser abordado (por ejemplo, cambiando su compensación y beneficios, otorgando derechos adquiridos, etc.); sin embargo, en algún momento tendrá que asegurarse de que la política debe ser cumplida, lo que también puede requerir una disciplina oficial de los empleados. Asimismo, si algunos deciden irse, puede valer la pena tratar de ver si están dispuestos a quedarse con los cambios en la compensación y los beneficios; sin embargo, es posible que también tenga que aceptar la pérdida de algunos de los promotores.

En última instancia, si su trabajo requiere que se imponga un cambio cultural al grupo para satisfacer las necesidades de la empresa, entonces sus opciones van a estar limitadas hasta cierto punto. Puedes y debes hacer todo lo posible para suavizar el cambio y obtener cualquier compromiso con otros grupos como puedas, pero eventualmente necesitarás hacer cumplir el cambio y aceptar cualquier cambio de personal que pueda venir con él.

Estoy leyendo comentarios y respuestas y debo confesar que estoy un poco aturdido. ¿Desde cuándo el hecho de que la gente llegue a tiempo es una “pérdida de beneficios”? ¿Desde cuándo flex-time es no tener que preocuparse por el impacto de sus acciones en el resto del equipo y la compañía?

Por lo que leí en la pregunta y los comentarios, el comportamiento de sus miembros del equipo es probadamente perjudicial y costoso para la compañía. Y después de intentar razonar y comprometerse, la situación no ha mejorado (y entretanto, las 9.30 no es no temprano o de ninguna manera irrazonable).

Explique a su equipo que no tiene ningún problema con el flex-time, pero que implica una cierta responsabilidad personal para asegurarse de que su flex-time no está impactando en el trabajo de otros (en su equipo o en otros equipos). Como su equipo está claramente fallando en la parte de responsabilidad, yo diría que con efecto inmediato y hasta nuevo aviso, todo flex-time tiene que ser aprobado por usted de antemano. El no presentarse a tiempo por la mañana sin aprobación o una excusa razonable (no, el reloj despertador no sonó no es aceptable) **resultará en una acción disciplinaria como el pago del muelle o el tiempo de vacaciones.

Tengan muy claro por qué está sucediendo esto y qué los ha forzado a tomar estas medidas. Señale que esto no es algo que usted quiere hacer, sino algo que se le ha forzado a hacer. También ten claro que estas políticas restrictivas pueden ser levantadas una vez que la situación mejore.

Todavía hay múltiples vías disponibles para manejar este asunto, una de las cuales sería cambiar el papel que desempeña el departamento, como por ejemplo: Si estás trabajando con desarrolladores de software podrías cambiar el rol de cierta o algunas personas durante la semana para que hagan el soporte a los otros departamentos, lo que requiere que 1 o más personas entren a las 9 o antes y si eso no funciona siempre podrías invocar una cláusula de insubordinación que normalmente está presente en cualquier manual de empleo en los EE.UU.. Personalmente siempre he estado en contra de usar esta cláusula, que da a un gerente una vía para reprender e incluso despedir a alguien ** por causa** pero en su caso esto puede ser apropiado. Así que revisa el manual de empleados y discútelo con tu superior si tienes algo de lo que vas a hacer.

La idea básica es la siguiente:

1. Estableces la regla de que al menos 1-2 o toda la gente debe estar en el trabajo en la hora X.
2. Si los miembros de tu equipo no tienen una excusa válida para no presentarse o persistir en esta práctica, tú como manager deberías reprenderlos y posiblemente despedirlos.

Como manager haciendo lo que describí sería el último recurso pero basado en lo que estás describiendo puedes haber llegado a ese punto. Hay muchos artículos sobre la insubordinación de los empleados que puede encontrar en línea y estos son sólo algunos ejemplos:

• BlogSpot
• Duhaime

Por supuesto, la consecuencia desafortunada puede ser una alta tasa de rotación en su grupo que se reflejaría pobremente en usted como gerente, pero hará cumplir la disciplina y probablemente matará la moral en el proceso.

Habiendo dicho todo eso, tengo una pregunta: ¿Realmente necesita que su equipo llegue más temprano que cuando ellos llegan?

Básicamente, tienes que decidir qué es más importante, ¿hacer el trabajo correctamente o sentarse en tu escritorio durante 8 horas a horas prescritas?