Pregunta:
¿Cómo puedo fomentar una cultura de puntualidad en una empresa de software?
Jacob G
2012-04-12 22:34:49 UTC
view on stackexchange narkive permalink

Como nuevo líder técnico en una nueva empresa, ¿cuáles son algunas de las estrategias adicionales que se pueden emplear para cambiar la cultura del equipo de desarrollo para que la gente se presente en el momento que solicité?

TLDR : mi equipo no llega a tiempo. Intenté obligarlos y no está funcionando.

Datos de antecedentes:

  1. Pequeña empresa, 30 empleados, 5 miembros de mi equipo.
  2. El cliente potencial anterior todavía está en el personal como desarrollador habitual.
  3. La cultura antes de mi llegada era de informalidad sin límites establecidos ni horarios centrales. Esta cultura no fue desafiada por los líderes corporativos. La mayoría de las personas del equipo se presentaban entre las 10:30 y las 11:00 debido a esto.
  4. Otros departamentos, debido a la naturaleza de su trabajo, han establecido tiempos de inicio de 8 o 9.

Esta discrepancia e imprevisibilidad causa mucha angustia entre mis departamento y otros departamentos. Como tal, senté al equipo y especifiqué un tiempo 'a más tardar' de las 9:30. Expliqué mi razonamiento y expliqué los beneficios de tal esquema y los aspectos negativos del esquema actual. Fue una conversación larga y polémica y 3 de las 5 personas del equipo estaban bastante disgustadas.

No hace falta decir que la gente no llega a tiempo (y las 9:35 no es a tiempo).

He programado nuestra reunión diaria de pie a las 9:30 como un motivador adicional. Sabiendo que se necesita un poco de tiempo para cambiar las horas de inicio (con viajes diarios, etc.), inicialmente esperaría para comenzar la reunión hasta que todos aparecieran, pero ahora simplemente comienzo la reunión (y a menudo termino la reunión) con quien esté presente. Eso tampoco parece marcar la diferencia y hace que el equipo sea menos cohesivo.

Las conversaciones individuales y grupales producen los mismos resultados que la conversación original (es decir, no ven el valor, piense Le estoy quitando una ventaja del trabajo, etc.)

Cuento con todo el apoyo y el respaldo del equipo de alta dirección y estoy facultado para emplear cualquier dispositivo que considere apropiado para solucionar este problema.

Mi próximo paso actual es enviar a alguien a casa y hacer se toman el día libre. ¿Es eso demasiado drástico? ¿Hay estrategias alternativas que estoy pasando por alto que podrían ayudarme a resolver este problema?

Edite según las preguntas de la respuesta de Jarrod

¿Qué tan nuevo es un líder técnico? fuerte> 6 meses, en esta empresa, en el momento de esta pregunta.

¿Por qué imponen políticas de gestión puramente no técnicas? Está en el ámbito de mi puesto definido por la dirección ejecutiva.

¿Cuáles son sus credenciales de gestión? 10 años de experiencia como líder técnico. Sin educación formal o certificación en nada gerencial.

¿Qué experiencia previa en administración de personal tiene? He sido líder técnico durante 10 años. He sido responsable de contratar / despedir / entrevistar / revisar / dirigir / crear algunos equipos técnicos diferentes.

¿Se ha ganado el respeto del equipo de una manera técnica?

¿Se ha ganado el respeto del equipo de una manera gerencial? El equipo me entrevistó por su capacidad técnica y gerencial. Fui claro y directo sobre cómo me gusta dirigir equipos técnicos y cómo me gusta ejecutar proyectos (con la salvedad obvia de que eso es solo un punto de partida y la cultura y el personal influyen en última instancia en el lugar donde aterrizo). Hay muchas cosas, desde un punto de vista perspectiva gerencial, con la que el equipo está bastante satisfecho.

¿El líder técnico anterior se retiró? Sí.

¿Se degradó al líder técnico anterior? No. Fue su solicitud.

¿El líder técnico anterior fue efectivo? Durante un tiempo. Pero, el crecimiento de la empresa y el código base hicieron que su estilo fuera ineficaz.

¿La mayoría del equipo existente tiene una relación más personal con el líder técnico anterior? Sí.

¿El líder técnico anterior sigue efectivamente a cargo? No.

Entonces [la cultura previa de informalidad sin límites establecidos] debe tener ¿Ha estado trabajando? Funcionó durante un tiempo, cuando la empresa aún era una startup. Ha crecido y evolucionado mucho más allá de la fase de inicio y, debido a ese crecimiento, no es tan eficaz como antes. Especialmente porque otros departamentos han introducido un poco más de formalidad y previsibilidad.

¿El equipo logró entregar productos útiles cuando se lo prometió? Al principio. Pero a medida que la empresa y el producto crecieron, la calidad y los tiempos de entrega disminuyeron significativamente.

No parece que hayas considerado o explorado algún tipo de compromiso con tu equipo o los equipos externos en función de sus comentarios negativos. ¿Lo hiciste? Por supuesto que sí, no soy un novato. La cuestión es que respeto el hecho de que el resto de la empresa trabaje en una caja inflexible debido a la naturaleza de sus responsabilidades. El equipo no estaba dispuesto a ceder en su tiempo flexible y, en muchos casos, los otros departamentos no pueden ceder. También he abordado los comentarios negativos específicamente con los otros departamentos e implementé una serie de cosas para mejorar las cosas. Uno de los grandes beneficios de este cambio fue mejorar la previsibilidad y cambiar las percepciones.

Actualización final

De la tripulación original de 5, 2 han sido reemplazados. El primero fue el líder del equipo anterior. No podíamos estar de acuerdo en cómo ejecutar proyectos de desarrollo y él no podía aceptar cambios a lo que había establecido anteriormente, por lo que acordamos mutuamente separarnos. El segundo perdió interés en el trabajo, cometió un par de errores importantes y también acordamos de mutuo acuerdo separarnos.

El equipo, en su conjunto, ahora se presenta lo suficientemente temprano para garantizar una amplia cobertura para el resto de la empresa. Lo que finalmente funcionó fue el mandato y la presión de los compañeros. Además, otros cambios que se han instituido han dado lugar a que casi toda la angustia interdepartamental se resuelva. Todos todavía pueden trabajar en proyectos increíbles, en su mayoría de su elección, a su propio ritmo en una empresa emocionante y todos están bastante contentos a pesar de que el mercado laboral es ridículo en el área.

Me ascendieron a un puesto ejecutivo y el nuevo 'equipo de problemas' se ha movido debajo de mí (además de seguir manteniendo el control del equipo de desarrollo y aún en desarrollo). Ahora estoy trabajando para ayudarlos a desempeñarse mejor y ser mejores compañeros de equipo para sus colegas. No tengo el problema de la puntualidad con este nuevo equipo ... Sus problemas son la precisión y la comunicación.

Tal vez un tipo diferente de motivador, como una dona * solo * para aquellos que llegan a tiempo o temprano. Puede ser costoso hacerlo todos los días, así que tal vez solo lo haga una vez a la semana, pero no les diga * qué * día ...;) Nunca he probado esto, así que es por eso que estoy publicando como comentario. que una respuesta.
Una cosa importante falta en esta pregunta: *** POR QUÉ *** estás haciendo este cambio? ¿El trabajo no se realiza de manera oportuna? ¿Existe un problema real que deba resolverse (y es esta la forma correcta de resolverlo? Podría ser un tema para otra pregunta ...) Como Andrew señaló en su respuesta, dictar una hora de inicio arbitraria "no después" para el conocimiento Los empleados que ya tienen una cultura de horario flexible serán impopulares, y es difícil sugerir motivadores / metodología sin más contexto ...
@voretaq7: Creo que "esta discrepancia e imprevisibilidad causa mucha angustia entre mi departamento y otros departamentos" significa que otros departamentos deben estar en contacto con el departamento de OP. y cuando un grupo llega a las 9 am y depende de otros que no se presentarán hasta las 11 más o menos, causa problemas.
@FrustratedWithFormsDesigner Posiblemente, pero si el desarrollador pone el trabajo en el escritorio del diseñador a las 8 pm para ser probado entre las 9 y las 11 mañana por la mañana, no veo ningún problema. Prefiero la coordinación a las reglas arbitrarias. También estoy tratando de no hacer suposiciones, pero la "angustia" podría ser fácilmente "Sales está llorando porque también quieren llegar tarde y si no pueden, ¡nadie puede!"
¿Estás dispuesto a hacer cumplir la otra cara de la regla de la "campana de la escuela"? ¿Todos dejan de hacer lo que están haciendo y se van en un momento determinado, sin importar cuánto trabajo pueda quedar por hacer?
@JimInTexas es más una regla de "horas centrales". Debe estar en la oficina entre las 9:30 y las 4:00 ... puede columpiarse más temprano o más tarde según su elección.
@voretaq7, en el mundo empresarial, un gerente tiene que actuar cuando otros departamentos se quejan. Los empleados de esos departamentos no ven por qué tienen que estar allí a horas determinadas y los desarrolladores no. Estoy seguro de que le han indicado que solucione el problema.
@HLGEM Sin embargo, eso depende de la naturaleza de la queja: A veces, la acción correcta como gerente es decirle a los otros departamentos "Así es como trabaja mi equipo y funciona para la empresa. Tough Rocks". - En el caso de Jacob, aunque sus desarrolladores parecen ser prima donnas mimados con problemas de actitud [ver esta discusión en el chat] (http://chat.stackexchange.com/transcript/message/4208458#4208458) y algunos de los comentarios a continuación. ..
@JacobG: Entonces, la gente de otros departamentos * necesita * tener reuniones cara a cara con los desarrolladores de su equipo de forma regular, tanto que hacer que los desarrolladores entren a trabajar a las 11 a.m. interfiere seriamente con eso. ¿Por qué es necesaria tanta interacción cara a cara entre departamentos? *¿Es necesario? ¿Asistir a estas reuniones es realmente un buen uso del tiempo de sus desarrolladores, o puede llevarse a cabo la coordinación en un nivel superior (por ejemplo, entre * usted * y otros departamentos)? No dudo de su descripción de la situación, pero parece extraño.
@KeithThompson: La interacción entre departamentos es frecuente y, a menudo, se debe a la necesidad de colaboración. Somos una empresa pequeña y un pequeño equipo de desarrollo, y necesitamos desempeñar varios roles en el SDLC, respaldar nuestros entornos de producción y ayudar a los otros departamentos a cumplir también con sus entregables. Muchos de nosotros en la empresa tenemos cosas urgentes para entregar y, por lo general, no hay suficiente tiempo de espera para pasar días coordinando. Hago interferencias lo mejor que puedo, pero no puedo asumirlo todo y necesito que el resto del equipo esté disponible.
* No hace falta decir que la gente no llega a tiempo (y las 9:35 no es a tiempo). * Esto suena dictatorial, microgestivo y tiránico. Parece que necesitas minions; busque esos tipos de personalidad cuando la tripulación actual se retire.
En el momento en que diga: (y las 9:35 no es a tiempo) inmediatamente me da la impresión de que es un jefe severo y es menos probable que escuche lo que dice. Los programadores en casi todas partes siempre han tenido flexibilidad en las horas de trabajo, y la mayoría de las veces la gente cae en una rutina, es poco probable que sean impredecibles cuando van a venir. Las personas hacen esto principalmente por lo que les funciona mejor y, a su vez, eso los hace más productivos.
@JarrodRoberson y tsoverflow: ustedes son obviamente bienvenidos a sus opiniones, pero creo que están un poco fuera de los límites con su hipérbole. No soy ni 'tiránico' ni 'tonto', pero espero que la gente llegue a tiempo a las reuniones y esté lista para participar.
Aún así, parece que el problema es contigo, no con el resto del equipo. Tienes un tono dictatorial aquí, solo puedo imaginar cómo te enfrentas a la gente que se supone que debes * liderar *. La sensación que tengo es que esta es tu primera o segunda vez en este puesto y crees que deberían hacer lo que dices porque tú estás a cargo. Existe una cultura para bien o para mal; necesitas adaptarte y cambiarlo con el ejemplo desde adentro. Viniste aquí pidiendo ayuda, pero no quieres escuchar las opiniones de nadie. Esto realmente debería ser * ¿Cómo puedo doblegar a mis empleados a mi voluntad? *
desayuno con bagels, donas, café, etc.empaquételo todo a las 9:30 am
No sé qué piensan todos, pero discutir durante cinco minutos no es realmente una forma efectiva ni productiva de pasar su tiempo con el equipo.
@Spoike: puede que sean solo 5 minutos, pero todavía están retrasados. Si ni siquiera pueden aparecer en TIME 9/10 veces, ¿cómo puede el autor confiar en ellos?
@Ramhound: Siempre que tengo gente que llega tarde a las reuniones, honestamente ** no me importa **. Termino hablando con personas que llegan a tiempo (discutiendo el día, la vida, lo que sea ... ya sabes ... conociéndolos mejor) y luego sigo con el asunto real cuando todos han llegado. La confianza es algo que se gana a través de sus interacciones con otras personas. La penalización (aunque se ve bien en las películas más taquilleras de Hollywood) no es la forma en que se construye su confianza con ellos.
@Spoike Yo diría que llegar habitualmente tarde * a las reuniones * delata una falta de respeto por el tiempo de los demás que debería abordarse. La empresa no debería estar pagando a cinco personas para que se sientan jugando con los pulgares y haciendo una pequeña charla esperando que lleguen todos. Hay un valor para * algunas * charlas triviales, etc., pero una cultura en la que el negocio de una reunión no comienza hasta varios minutos después de la hora de inicio programada indica que el tiempo no se valora ni se respeta.
@tsOverflow: Si la reunión de pie es a las 9h30 en punto, entonces solo tiene que programar su llegada para las 9h25 y puede permitirse llegar 5 minutos tarde en caso de problema.
@MatthieuM .: OP decidió hacer que todos vinieran a las 9:30 am primero, luego programó la reunión a las 9:30 am para obligar a todos a venir temprano. Existe la diferencia entre programar la reunión con anticipación de esa manera y tener una reunión en ese momento sin la intención subyacente de hacer que las personas asistan en un momento determinado.
@JohnMcG: Llegar como nuevo gerente para interrumpir las cosas sin permitir que nadie tenga un mandato al respecto es gran cosa, una señal de que no escuchas y una falta de respeto. Cambios como este llevan tiempo, incluso años. Trate de empezar a respetar a los demás antes de * exigir * respeto. De la edición: Su equipo no está dispuesto a comprometer el tiempo flexible, lo cual supongo porque tienen un interés personal en él y probablemente se inscribieron para ese tipo de trabajo. Cualquiera sea la razón, es su trabajo como gerente lidiar con eso y manejar las expectativas ... o despedir al equipo ... pero esa es una mala solución.
@JacobG: De la discusión de chat vinculada por voretaq7, parece que su situación podría resumirse como "Tengo que liderar un departamento de prima donnas malcriadas que no hacen el trabajo correctamente, tienen malas relaciones con otros departamentos y llegan tarde". - en tal situación, "llegar tarde" es * el menor de tus problemas *. Sin embargo, es posible que pueda usar esto a su favor: si puede estar de acuerdo con la alta gerencia en que la puntualidad se puede relajar a cambio de mejoras en otras áreas, * y * presentar esto como un quid pro quo a su equipo, puede * * obtener mejoras por todas partes.
@Spoike - Parece que sería muy difícil trabajar con usted. A los ojos del supervisor, no parece pensar que "llegar tarde" sea un problema. Para ser honesto, no importa cuál fue la política con el supervisor anterior. Si no les gustan dichos cambios, pueden irse y el nuevo supervisor puede reemplazarlos con personas que ESTARÁN a tiempo.
@Ramhound: Ahora estás haciendo suposiciones que no existen y son muy innecesarias. Normalmente llego a tiempo a las reuniones, e incluso prefiero estar allí unos minutos antes y normalmente es fácil trabajar con ellos, al menos eso es lo que me dicen mis compañeros en mi perfil de LinkedIn. :-) Todo lo que digo es que incluso si alguien llega tarde a una reunión, no quiero gastar toda mi energía cognitiva en discutir sobre ello, hay asuntos mucho más urgentes que atender.
Todavía estoy desconcertado de por qué perder una o dos horas por la mañana es tan desastroso para la coordinación con otros departamentos. Si sus desarrolladores pasan más de una hora al día haciendo este tipo de cosas, eso es un indicador para mí de una gestión seria (no necesariamente de OP) o un problema cultural. Si los desarrolladores son prima donas, es posible que todos sean unos idiotas. También es posible que alguien los tenga en horas de reuniones al día para actualizaciones constantes del progreso de todo el trabajo al que ni siquiera pueden llegar hasta después de las 5 cuando todos los demás se van. He estado allí / he visto esa colosal pérdida de salarios de los desarrolladores.
* Cuento con todo el apoyo y el respaldo del equipo de alta dirección y estoy facultado para emplear cualquier dispositivo que considere apropiado para solucionar este problema. * - ¿Y cree que esto le ayudará a imponer una cultura de puntualidad? Buena suerte amigo.
@JimG. Esa fue simplemente información potencialmente relevante que alguien pudo haber usado para formular una solución productiva para "alentar", no "imponer" una cultura de puntualidad. Siéntete libre de participar en la comunidad y ofrecer tu propia solución productiva.
La pregunta es un oxímoron ...
La intensidad de la jornada laboral de un programador es incomparable a la de los trabajadores de otro departamento, por lo que no pueden ser tratados por igual. Por ejemplo, si su trabajo es revisar un par de CV o hacer una llamada telefónica, por supuesto que debe estar allí de 9 a. M. A 5 p. M. Quiero decir, hay trabajos en los que no tienes tareas desafiantes, pero tu presencia es necesaria todo el día, y hay otros en los que tienes una fecha límite y una cantidad de trabajo por hacer antes de eso, independientemente de cuándo llegues a la Mañana.
* "He programado nuestra reunión diaria de pie a las 9:30 como un motivador adicional ..." * - ¿llamas a esto una * "motivación" *? DIOS MIO..
¿Hay alguna razón por la que tengas que subrayar que eres tú quien decide las cosas en tu equipo?
OP suena a dictador. "¿Por qué están imponiendo políticas de gestión puramente no técnicas? Está en el ámbito de mi puesto definido por la dirección ejecutiva". ¿Poder-viaje mucho?
"Contratamos a mucha gente a bajo precio a cambio de horarios de trabajo súper flexibles. Ahora que mordieron el anzuelo, nos gustaría cambiar". Si quieres "puntualidad", incluye las horas de trabajo (centrales) en el contrato.
Soy nuevo en el sitio y me gustaría dejar esta nota aquí: como desarrollador, me gustaría saber en qué empresa trabajaba el OP en el momento en que hizo esta pregunta, por lo que nunca les envío mi currículum.
Al leer la pregunta, los comentarios y el chat, no me queda claro exactamente dónde se encuentra la motivación para esta 'eliminación de beneficios' entre "necesitamos coordinar entre departamentos" y "otros departamentos están celosos de nuestro beneficio". Probablemente sea obvio, pero si sus desarrolladores sienten que la primera razón es solo una fachada para la segunda, la reacción que está obteniendo es completamente predecible: mientras está en eso, ¿por qué no reducir sus salarios para alinearse con otros departamentos? Si realmente es el problema de la "coordinación", ¿es un problema todos los días? Si no es así, debe haber otra posible solución.
Me preguntaba por qué había "angustia" en los otros departamentos. ¿Podría dar más detalles sobre esto?
@ThorbjørnRavnAndersen Probablemente estaban jugando Bright Eyes en su departamento.
Si * ellos […] piensan que les estoy quitando una ventaja del trabajo * es porque usted lo está. También puede ser justificado, necesario, irrazonable, dictatorial, pero es lo que es independientemente.
Entonces, ¿la razón del inicio temprano es que otros departamentos están celosos? Quizás necesite ver por qué 9-5 se convirtió en un estándar en primer lugar, y las muchas razones por las que ya no se aplica a la mayoría de los desarrolladores de software en la era del teletrabajo ...
De diecisiete respuestas:
#1
+155
Nicole
2012-04-13 00:42:13 UTC
view on stackexchange narkive permalink

El mejor factor de motivación es la confianza. La unidad del equipo es de suma importancia para lograr sus objetivos. Las culturas de las reglas nacen de la desconfianza, y los palos y los empujones para hacer cumplir las reglas solo erosionarán aún más la confianza de su equipo.

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

  • ¿Realmente importan las 9:30 (o cualquier hora arbitraria)? ¿O es que su equipo necesita asegurarse de que su ausencia no obstaculice el trabajo de otros equipos?

  • ¿5 minutos marcan la diferencia? ? ¿O es lo más importante que todos los miembros se unan al enfrentamiento diario?

  • ¿Es la informalidad un problema? ¿O la flexibilidad es un beneficio?

Me gustaría profundizar en el meollo del problema, que es que su equipo no ha aceptado la idea . Vea dónde está la desconexión, pero evite crear una cultura de reglas . Enviarlos a casa por llegar tarde (una táctica disciplinaria que encontraría en una escuela primaria) hará que su equipo crea que los ve como niños en los que no se puede confiar.

+1 - Creo que esta es la forma más concisa de expresar el problema * y * las soluciones. Independientemente de las reglas que establezca, debe facilitar la realización de las cosas, y así es como se debe abordar esto con los empleados.
Me gusta esta respuesta y estoy de acuerdo con ella. Creo que intenté que entendieran los problemas subyacentes y cómo se les ayudaría con una política de horas centrales. Un desarrollador respondió con superioridad (es decir, que se jodan los otros departamentos porque soy especial) y los demás se centraron únicamente en la pérdida de un beneficio. No creo que se vean a sí mismos como parte del equipo más grande, sino como la superestrella del equipo más grande. No quiero "enviarlos a casa", por eso pedí algunas tácticas alternativas, ya que no sé qué más hacer.
@JacobG Ya sabes, el segundo desarrollador _tiene_ un punto: poder entrar entre las 10:30 y las 11:00 a. M. ** es ** una ventaja, incluso si no apruebas que usen (como, por ejemplo, , pausas para fumar). No debe eliminarlo sin ofrecer algún tipo de compensación.
+1 absolutamente de acuerdo. Yo agregaría que quizás el problema pueda mitigarse considerando tener "cobertura" durante las horas centrales en lugar de tener a todos en el sitio en las horas centrales. ¿Pueden algunos desarrolladores ofrecerse como voluntarios para llegar antes mientras que otros se quedan más tarde?
Estoy de acuerdo con el factor motivación, pero no estoy de acuerdo con que una cultura de reglas sea algo malo.
cuando la gente tiene malos hábitos, recompensarlos / compensarlos por dejarlos no es bueno. Prefiero recompensar y compensar los resultados.
Algunos buenos puntos, pero no estoy de acuerdo con tu premisa. La confianza, no la desconfianza, habilita las culturas de reglas. El problema del OP es que sus informes no confían en él lo suficiente como para hacer lo que les pide. Puede que tengan razón al no hacerlo. Entonces, más bien ** El mejor factor de motivación es el interés propio. **
Esto no es un problema de * confianza *, es un problema de * respeto * y el gerente directo de alguien apoya su opinión, la respeta y se asegura de que se escuche su voz. Lea los comentarios sobre mi respuesta, no hay ninguna creencia de que el equipo de desarrollo deba tener voz en el asunto, es un enfoque dictatorial, no un enfoque aislado de la gestión.
Como líder de equipo o gerente de línea que trabaja con personas inteligentes y creativas, la habilidad más importante es escuchar. Siempre que el equipo sea productivo y eficaz, no se interponga en su camino. En este caso, la presión proviene de fuera del equipo; veo mi papel como * proteger * al equipo de este tipo de "lluvia organizativa" y, por lo tanto, termino luchando por ellos con la dirección, no al revés. Si el equipo es eficiente y productivo, no se meta con él. Si el cronometraje rompe la cohesión del equipo, asegúrese de que se plantee en sus retrospectivas como un problema que el equipo debe resolver.
+1 por centrarse en el problema central y evitar crear una cultura de reglas. El punto sobre la flexibilidad como beneficio también es bueno.
#2
+124
jmort253
2012-04-13 11:26:15 UTC
view on stackexchange narkive permalink

Crear una cultura de puntualidad puede llevar tiempo y puede ser algo en lo que deba comprometerse un poco. Dado que está tratando con trabajadores del conocimiento inteligentes, tendrá más éxito si puede lograr que acepten el 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 qué se les ocurre. La respuesta puede ser horarios establecidos o puede ser algo diferente que resuelva el problema. Puede ser lunes, miércoles, viernes son los días de 9 a.m., mientras que los martes y jueves son los días flexibles. Si bien es posible que el plan no sea perfecto ni será exactamente lo que imaginó, encontrar un término medio en algún lugar que haga feliz tanto al equipo de desarrollo como que resuelva el problema real evitará que su personal se amargue y lo vea como el enemigo .

Tenga en cuenta que no se trata de un proceso de fabricación en el que todos deben presentarse exactamente a las 9:30 am, cuando suena el silbato, para que puedan comenzar la abrumadora tarea de ensamblar el mismo pequeños artilugios de plástico repetidamente, hasta que vuelve a sonar el silbato y el personal aturdido se dirige al bar local para la hora feliz.

Mi equipo no llega a tiempo. Traté de obligarlos y no funciona.

Forzar a las personas inteligentes nunca funciona. Debe recordar que se trata de personas creativas, inteligentes y con un alto nivel de educación que son buenas para resolver problemas complejos, abstractos y únicos. Estas personas, al menos las realmente buenas, nunca seguirán órdenes ciegamente. Esto se remonta a poner el problema en sus manos, al menos al principio. Si no hacen nada, entonces querrá intervenir con su propia solución.

Mencionaste que eres un nuevo líder de equipo. Asumir una nueva posición como esta es desafiante y estresante, ya que no está seguro de cómo ganarse el respeto del equipo y también ser un buen líder. Esto viene con la experiencia, y es común que los líderes de equipos nuevos sin experiencia intenten "obligar" u obligar a las personas 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 llevarlo a la desesperación.

Las investigaciones muestran que las personas tienen más probabilidades de comprometerse cuando han participado en determinar qué la solución será en lugar de que les se les diga esa solución, y esto es especialmente cierto con los trabajadores del conocimiento.

Para obtener inspiración, consulte Seth Godin Entrevista sobre la diferencia entre liderazgo y gestión. Recomiendo encarecidamente que todas las personas con capacidad de liderazgo vean esta breve entrevista.

"Que se les ocurra un plan" fue también mi primera reacción. Sin embargo, a juzgar por los comentarios y el chat, no parece probable que funcione en este caso en particular ...
@Benjol - El tono de la pregunta me hace pensar que hay más en esto de lo que parece. También se siente la gestión del estilo de la Teoría X, que no es eficaz cuando se gestionan desarrolladores. Solo escuchamos un lado de la historia y la verdad siempre está en algún punto intermedio.
Mira mi respuesta :)
El punto más importante es este: _ Forzar a las personas inteligentes nunca funciona_. No puede tratar a los miembros de su equipo altamente inteligentes como niños y esperar que no se quejen, se defiendan y se resientan por ello (por ejemplo, no me afecta directamente nada de esto, pero todavía me resulta difícil no hacerlo). se ofende personalmente por cómo el OP está tratando de administrar su equipo). Los empleados técnicos generalmente son tan inteligentes como sus gerentes (si no más), por lo que la única forma efectiva de acercarse a ellos es como compañeros, no como subordinados insensatos que deberían hacer lo que usted dice porque usted lo dijo.
Tengo poca educación y todavía me opongo a que la gente se quite mi tiempo flexible.
#3
+64
Andrew
2012-04-12 23:19:20 UTC
view on stackexchange narkive permalink

Según mi experiencia, a los trabajadores del conocimiento no les gusta que les dicten sobre políticas que ven no tienen ningún propósito. Usted establece un propósito, pero los empleados que administra parecen pensar que no es bueno. Además, es probable que haya alternativas que no ha considerado y, dado lo que parece un problema "dictado desde arriba", es posible que sus empleados no las hayan pensado, no se sientan cómodos proponiéndolas o sientan que simplemente serían

Si la única razón por la que está implementando la política es debido a la tensión con personas de otros departamentos, es su trabajo manejar esa tensión para que su gente pueda trabajar de la manera más eficaz. Sin embargo, no creo que esa sea la única razón. Por ejemplo, ¿qué sucede si se necesita un desarrollador para solucionar un problema de producción urgente que ocurre a las 8:00 o 9:00 o en cualquier otro momento? Sin embargo, es poco probable que necesite que todos sus desarrolladores estén presentes para solucionar ese problema. ¿Qué pasaría si tuvieras un horario "temprano" rotativo (a menos que alguien se ofrezca como voluntario), de modo que cada desarrollador tome un turno para estar allí a las 8:00 (o 9:00, etc.)? Parece más probable que esa solución satisfaga tanto las necesidades comerciales como los deseos de sus empleados. Todos "comparten el dolor" (o se lo infligen a alguien a quien no le importa). La gente puede entrar y trabajar la mayor parte del tiempo cuando sienta que sería más productiva. Esta es solo 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 seguir la ruta más disciplinaria, y el tema de la "hora de inicio" es realmente importante para sus desarrolladores, perderá los buenos por otros empleos. Es probable que sus empleados se sientan inseguros en sus trabajos (¿y si un día ocurre una emergencia real que hace que alguien llegue tarde?). Además, esto puede verse como un cambio en la administración en la dirección equivocada (desde la perspectiva de sus empleados), ya que anteriormente tenían experiencia trabajando con otra persona.

Depende de usted, por supuesto, pero Les insto a que den un paso atrás y se esfuercen más 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 estás proponiendo.

No voy a penalizar a nadie si tiene una razón legítima para llegar tarde. Quedarse dormido tres veces a la semana porque están jugando WoW toda la noche no es legítimo. Tenemos una persona que se adelanta y prefiere llegar a las 7:30. El gran problema es que si Dev X está trabajando en un proyecto con el Diseñador Y y el Diseñador Y está a las 8, está esperando hasta la 1 p.m. o más tarde para obtener algo que pueda necesitar. Cuando se llama a él, los desarrolladores no ven ningún problema con él. Somos una empresa pequeña y todos deberíamos estar en el mismo equipo. En serio, las 9:30 no es muy temprano. ¿Realmente estoy siendo irrazonable?
@JacobG No puedo decir si estás siendo irrazonable sin más información, sin embargo, la clave para flexibilizar el tiempo es que el trabajo *** debe *** estar terminado. Si lo que está diciendo es que el trabajo ** no ** se está haciendo, eliminar el tiempo flexible de los empleados improductivos (o acortar el tiempo de pago / vacaciones) puede ser el camino a seguir. En tu ejemplo. Dev X y Designer Y deberían estar coordinando para que ninguno de los dos esté sentado haciendo girar sus pulgares esperando al otro. Si eso no sucede, es tanto un problema de proceso como un problema de programación ...
"Perderás tus buenos por otro empleo" - ese es el meollo de todo el problema, @Jacob. Si el trabajo no se hace, entonces tiene problemas más profundos; sus desarrolladores y diseñadores deben coordinarse mejor. Si el trabajo * se está * haciendo, entonces no pierda el tiempo de los desarrolladores con tonterías como establecer una hora de inicio específica.
+1 por perder frente a otros empleadores. Si estuviera pasando de un entorno en el que se confiaba en mí para mantener mi propio horario y hacer mi trabajo a un entorno de marcado de relojes donde obtuviera deméritos por tardanza, estaría desempolvando mi currículum.
@ErikDietrich: Entonces, si no estaba haciendo su trabajo de manera satisfactoria y su jefe le dijo: "Sabes, tu trabajo no se está haciendo a tiempo y fulano de tal se queja de que no estás lo suficientemente disponible durante su horario establecido y prescrito, así que comencemos a llegar con un horario constante a las 9:30 a más tardar ". ¿Todavía desempolvarías tu currículum?
-1
De acuerdo con @AdamRackis sobre si `El gran problema es que si Dev X está trabajando en un proyecto con el Diseñador Y y el Diseñador Y está en el 8, está esperando [...]` Yo votaría que el Diseñador Y debería planificar con anticipación y decir en al final del día "Oye, voy a estar trabajando en esto mañana por la mañana, ¿podrías asegurarte de llegar temprano mañana y ayudarme, o terminarlo antes de que te vayas?" Hacer que trabajen juntos también requiere menos tiempo .
"Quedarse dormido tres veces por semana porque están jugando WoW toda la noche no es legítimo". ¿Qué significa "quedarse dormido"? ¿Estamos todavía en la escuela primaria aquí? Ocho horas son ocho horas, ya sea que comiencen a las 6 a.m. o a las 10 a.m. Si necesita que las personas estén presentes en las reuniones y demás, déjelas que elijan ciertas horas centrales en las que estarán disponibles, digamos de 10 a.m. a 3 p.m. o lo que sea. Pero si el trabajo se está haciendo es ortogonal a si llegan en un momento determinado o no. ** ¿Has intentado hablar con los desarrolladores sobre el problema y pedirles a * ellos * que encuentren una solución? **
@Kyralessa - Si su jefe dice que debe estar en el trabajo a las 9:30, entonces será mejor que esté en la oficina a las 9:30, de lo contrario LLEGARÁ TARDE. No puedo creer cuántas personas tienen problemas con la pregunta de este autor, y mucho menos diciéndole que no está siendo un líder razonable, me enseñaron a llegar a tiempo todos los días.
@Ramhound El problema es que la cultura anterior era una en la que las 9:35 NO era tarde, y el OP quiere cambiar a una cultura que es, presumiblemente para personas con talentos que no son fácilmente reemplazables y que tienen cierto nivel de libertad sobre donde puedan trabajar. Él puede gritar "LLEGAS TARDE", supongo, pero eso puede resultar en que algunas personas se vayan y bajen la moral, lo que parece que está tratando de evitar.
@Renan Ciertamente, no es ideal para todas las situaciones. El punto es asegurarse de que se cubran las necesidades comerciales. Si hay un problema de producción urgente en un momento crítico, alguien debe poder solucionarlo. En mi puesto actual, a menudo soy yo, pero lo que sucede es que recibo un correo electrónico en mi teléfono, lo reconozco y entro en mi máquina * en casa * y soluciono el problema. Si ocurre una emergencia tras otra, hay problemas mucho más allá de quién está en la oficina y cuándo.
@Ramhound Establecer una hora de inicio arbitraria cuando no había una antes y esperar que todos simplemente ajusten su programa de vida en torno a ella _es_ irrazonable. De hecho, establecer una hora de inicio difícil cuando no es realmente necesario tampoco es razonable. Obviamente, los desarrolladores no lo ven como necesario, por lo que les parece irrazonable. Además, considerando que han estado en la compañía mucho más tiempo que el gerente y todos parecen estar de acuerdo, es posible que tengan razón.
#4
+50
Erik Reppen
2012-05-06 00:55:38 UTC
view on stackexchange narkive permalink

La respuesta precisa a su pregunta es despedir y reemplazar a alguien que no recibe el mensaje y luego despedir a cualquiera que no reciba el mensaje.

No espero que esto ayude su carrera o los objetivos de desarrollo de su empresa, pero ha decidido que este es el problema y parece que no hay forma de convencerlo de lo contrario. Así es como se hace.

De manera más constructiva, le sugiero que considere lo siguiente:

  • Sus desarrolladores tuvieron tiempo flexible. Ahora quiere eliminarlo

No importa si es un beneficio oficial en alguna política escrita o no. Es una política de facto y parte de la cultura establecida. La vida y los horarios de las personas se han establecido en torno a estas horas. Y para los desarrolladores como yo, que prefieren evitar las horas pico y que sufren un caso terriblemente desagradable de TAE en el invierno, pero no pueden pensar en ningún lugar apto para desarrolladores más cerca del ecuador en el que prefiera vivir, es tan grande como un trato como obtener beneficios para la salud.

  • ¿Cuál es la naturaleza de esta "angustia" que mencionas? ¿Son a) principalmente celos ob) problemas legítimos de comunicación interdepartamental como dificultad para programar reuniones / comunicación general?

a) Los desarrolladores no necesitan interactuar con clientes u otras empresas. En mi experiencia, cuanto más rígida es la estructura de la empresa, más mediocres son los desarrolladores. Si bien gran parte del desarrollo es fundamental, también es un proceso creativo de resolución de problemas que requiere que las personas estén en su máxima expresión. También es un proceso impulsado por plazos impredecibles que a veces resulta en horas muy, muy tarde. Un efecto secundario de esto es que los desarrolladores a menudo reciben el tratamiento "creativo". En una empresa de 30 personas, no debería ser difícil insistir en que las personas sean adultas acerca de los empleados que necesitan ser más agudos cuando están presentes y es probable que, en última instancia, dediquen muchas más horas en el transcurso de un año que una empresa de 9-5 generalmente empacan sus cosas a las 4:55 pm todos los días.

b) En una empresa de 30, no debería tener tantas reuniones que esto se convierta en un problema. Sin contar cosas como reuniones de velocidad u otras sesiones de planificación bimensuales, atar a sus desarrolladores durante más de 30 minutos todos los días en reuniones es una pérdida de dinero absurda y extremadamente incompetente. Lo mismo ocurre con la comunicación general. 30 personas significa que te acercas al otro chico y le hablas. En escenarios de tiempo flexible, es razonable establecer un período de tiempo en el que todos estén en la oficina al mismo tiempo. No puedo pensar en 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 a la mitad del día.

  • ¿Por qué un standup matutino?

¿Por qué la primera gestión de ideas descartadas de scrum, ágil, etc ... es siempre el consejo de que no tienes el standup primero? En programación, se necesita un tiempo para volver a ser plenamente consciente de todos los detalles y problemas con los que se enfrenta en un problema determinado. Cuando haces stand-ups a primera hora, tus desarrolladores no van a tener la cabeza completamente atornillada. Los stand-ups son fundamentales para la comunicación y la mejora de la eficiencia, no es algo que simplemente haces para "salir del camino".

  • ¿Tus desarrolladores no logran hacer el trabajo?

Si no es así, ¿por qué meterse con algo bueno? No es su trabajo comunicarse con las otras preocupaciones de la empresa. Es tuyo. En una estructura de gestión sensata, su responsabilidad es para con su gerente inmediato y las personas que administra, no las uvas amargas de otros departamentos que tienen que estar allí a horas más típicas por razones prácticas.

Di una respuesta a la pregunta. Y luego un seguimiento / apéndice realmente largo.
#5
+46
user718
2012-07-12 12:30:04 UTC
view on stackexchange narkive permalink

Revisión de la pregunta: Falta mucho contexto e información

Como nuevo líder técnico en una nueva empresa, ¿cuáles son algunas estrategias adicionales que se pueden emplear para cambiar la cultura del desarrollo? equipo para que las personas se presenten en el momento que solicité?

  1. ¿Qué tan nuevo de un líder técnico?
  2. ¿Por qué está imponiendo políticas de gestión puramente no técnicas?
  3. ¿Cuáles son sus credenciales de gestión?
  4. ¿Qué experiencia previa en gestión de personal tiene?
  5. ¿Se ha ganado el respeto del equipo de manera técnica?
  6. ¿Se ha ganado el respeto del equipo de manera gerencial?

TLDR: Mi equipo no llega a tiempo. Traté de obligarlos y no está funcionando.

No podemos proporcionar una solución a menos que sepamos específicamente por qué necesita cambiar la cultura drásticamente. Tampoco sabemos con qué ha intentado obligarlos a poder decirle por qué no es eficaz. Podemos adivinar, pero eso es especulación.

¿Por qué tiene la tarea de resolver lo que podría decirse que es un mandato de gestión de personal no técnico? Entréguelo a un superior que sea gerente y déjelo ocuparse de él. Cop bueno vs poli malo.

Datos de antecedentes:

Pequeña empresa, 30 empleados, 5 miembros de mi equipo. El cliente potencial anterior todavía está en el personal como desarrollador habitual.

  1. ¿El líder técnico anterior se retiró?
  2. ¿Fue degradado el líder técnico anterior?
  3. ¿Fue efectivo el líder técnico anterior?
  4. ¿La mayoría del equipo existente tiene una relación más personal con el líder técnico anterior?
  5. ¿El líder técnico anterior sigue efectivamente a cargo ?

La cultura anterior a mi llegada era de informalidad sin límites establecidos ni horarios centrales. Esta cultura no fue desafiada por los líderes corporativos.

  1. ¿Entonces debe haber estado funcionando?
  2. ¿El equipo tuvo éxito en la entrega de productos útiles cuando se lo prometieron?

La mayoría de las personas del equipo se presentaban entre las 10:30 y las 11:00 debido a esta. Otros departamentos, debido a la naturaleza de su trabajo, han establecido horarios de inicio de 8 o 9. Esta discrepancia e imprevisibilidad causa mucha angustia entre mi departamento y otros departamentos.

Específicamente cómo es así, no hay suficientes detalles aquí para siquiera comenzar a formular una respuesta a esta pregunta. Cualquier tipo de respuesta sería una completa especulación.

Como tal, senté al equipo y especifiqué una hora "a más tardar" de las 9:30. Expliqué mi razonamiento y expliqué los beneficios de tal esquema y los aspectos negativos del esquema actual. Fue una conversación larga y polémica y 3 de las 5 personas del equipo estaban bastante disgustadas.

¿Qué tal si nos brindas tus beneficios y negativos sin ellos, no podemos juzgar cuán razonable ni cuán efectiva pudo haber sido su comunicación. No parece que hayas considerado o explorado algún tipo de compromiso con tu equipo o los equipos externos en función de su retroalimentación negativa. ¿Lo hiciste?

No hace falta decir que la gente no llega a tiempo (y las 9:35 no es a tiempo).

Esto no es así ' Suena como una actitud muy positiva o eficaz.

He programado nuestra reunión diaria de pie a las 9:30 como un motivador adicional. Sabiendo que se necesita un poco de tiempo para cambiar las horas de inicio (con viajes diarios, etc.), inicialmente esperaría para comenzar la reunión hasta que todos aparecieran, pero ahora Solo comienzo la reunión (y a menudo termino el reunión) con quien esté presente. Eso tampoco parece marcar la diferencia y hace que el equipo sea menos cohesivo.

Por lo tanto, las acciones unilaterales que está tomando hacen que el equipo sea menos cohesivo. Piense en it.

Las conversaciones individuales y grupales producen los mismos resultados que la conversación original (es decir, no ven el valor, creo que estoy quitando una ventaja del trabajo, etc ...)

Escuchamos y podemos extrapolar lo que no aceptan, ¿los escuchas ?

Cuento con todo el apoyo y el respaldo del equipo de alta dirección y estoy facultado para emplear cualquier dispositivo que considere apropiado para solucionar este problema.

The Catholic Church tenía el mismo poder durante la Inquisición, ¡mira cómo resultó!

Mi próximo paso actual es enviar a alguien a casa y hacer que se tome el día libre. ¿Es eso demasiado drástico? ¿Hay estrategias alternativas que estoy pasando por alto que podrían ayudarme a resolver este problema?

La intensificación tampoco parece una alternativa viable. Enviarlos a casa sin paga es un insulto y perjudicará a la empresa más que al empleado. Te hará parecer aún más dictatorial y tiránico. Tratarlos como niños hará que actúen como niños aún más.


Resultado previsto de su enfoque actual

  1. Perderá todo el respeto de todo el equipo, serán cada vez más ineficaces, usted será percibido cada vez más ineficaz a medida que la productividad se detenga.
  2. Su fracaso con el cambio de políticas y las habilidades de gestión de personal hará que sus superiores lo perciban como ineficaz.
  3. Perderá el respeto de las personas que no de su equipo debido a la comunicación entre oficinas. También saboteará cualquier oportunidad futura de liderazgo técnico con ellos.
  4. Seguramente dañará su reputación en la empresa, arriba y abajo de la cadena.
  5. Los mejores empleados renunciarán verbalmente primero.
  6. Los empleados aún mejores renunciarán silenciosamente después de ellos.
  7. Los marginalmente calificados pueden renunciar o no dependiendo del dolor que imponga.
  8. Los no calificados aguantarán como garrapatas y aguanta todo lo que impongas.
  9. La empresa termina perdiendo y obteniendo una mala reputación externa por parte de los empleados que se fueron.
  10. ¡La percepción lo es todo! ¡Nunca olvide eso!

Algunos enfoques sugeridos

  1. Como su gerente, debe luchar para aislarlos de las decisiones de la alta dirección. Debes luchar para que se escuche su voz. Debe ayudarlos a formar colectivamente una respuesta y rechazarlos y apoyarlos con su respuesta.
  2. Esta es una decisión no técnica y puramente de gestión corporativa. ¿Por qué está lidiando con él y su implementación? Tener un trato superior con esto, ese es su trabajo.
  3. No actúe como un dictador o un tirano. Puede que no sea igual a derecho.
  4. Tome algunas habilidades sociales, entrenamiento en habilidades blandas.
  5. Muévase más lentamente. Cosas como esta no cambian de la noche a la mañana.
  6. Necesita tener al líder técnico anterior de su lado si tienen una buena relación con el equipo.
  7. Tener un compromiso alternativo, cómo sobre las personas a las que no les importa venir temprano, ¿las otras personas no tienen que hacerlo?
  8. El movimiento del tiempo de pie es arbitrario, todo el mundo ve esto y no es visto como práctico o razonable pero como dictatorial.
  9. Haga que los equipos externos con los que tiene que lidiar sean parte de la discusión y lo ayuden a vender los cambios de política.
  10. Retroceda, esté de acuerdo con ellos, sé el buen policía. Haz que tu superior dicte la ley. Este es un problema de administración, no un problema técnico. Eres un líder técnico, no un gerente, ¿verdad?
  11. Haga que los miembros externos del equipo y los miembros de su equipo simplemente establezcan horarios para reunirse cuando necesiten reunirse. Días y horarios predeterminados de disponibilidad serían un buen compromiso. Los desarrolladores no quieren ser interrumpidos constantemente por el equipo externo y parecen estar allí únicamente para acudir a las reuniones cuando lo soliciten.

Reflexión final:

El estilo de gestión, tanto técnico como no técnico, se basa en Wu Wei Principal de The Tao te Ching.

El principio de Wu Wei puede entenderse golpeando una pieza de corcho flotando en el agua. Cuanto más fuerte lo golpees, más cede: cuanto más cede, más fuerte rebota. Sin gastar energía, el corcho puede desgastarlo fácilmente.

Cuanto más haga, más rápido es probable que falle. Cuanto menos hagas, más probable es que se haga lo que quieres que suceda.

Liderazgo transparente indirecto

Al principio, en el mejor de los casos, la gente apenas nota a un líder. Luego lo adoran y lo aclaman, luego llegan a temerlo, al final lo desprecian. Así, la fe perdida engendra la fe perdida.

Sea no directivo, haga que sus pocas palabras sean preciosas. Cuando el trabajo esté terminado, todos dirán: Lo hicimos solos, naturalmente.

Reúna a la gente del departamento externo que tiene las quejas junto con su gente en una habitación y deje ellos buscan una solución aceptable entre ellos internamente, sin usted en la sala . Esté dispuesto a aceptar cualquiera que sea el resultado. Entonces la solución es de ellos, ellos la poseen, y usted se ganará el respeto que tanto necesitan de ellos por dejar que lo resuelvan. Este es el enfoque no directivo .

+1, Todos estos son enfoques realmente geniales. Personalmente, me gusta el enfoque de empoderar al equipo para resolver el problema. Es sorprendente lo que los adultos son capaces de hacer cuando se les trata como ... bueno ... adultos. Martha necesita reunirse con John, por lo que planean y coordinan juntos, sin que el gran jefe malvado y desagradable venga y haga de dictador.
Edité mi pregunta para responder a algunas de sus preguntas específicas.
@JacobG Incluso después de su edición, una cosa que todavía no está clara es que es usted un * Líder técnico * o son estas personas * Líder no técnico / Gerente de línea *? Esta es una distinción importante, como líder técnico, conduce en la toma de decisiones técnicas. ¡Qué ** tecnología ** usar, ** no ** cuando los desarrolladores entren en el trabajo! 10 años de tomar decisiones técnicas no es ningún tipo de calificación para lidiar con problemas de personalidad / social gerencial no técnicos como este, especialmente sin capacitación formal.
@JacobG Comenzó con el enfoque del * palo *, ninguna cantidad de * zanahorias * se recuperará de eso. Una marca de un gran líder es saber cuando no están calificados y no van a ser efectivos y pedir ayuda, personalmente creo que este es uno de esos momentos para que usted salve las apariencias y le dé esta batalla a otra persona. . Ha perdido la guerra psicológicamente, incluso si * gana * la batalla que usted y el equipo habrán perdido mutuamente. La ** única ** forma de resolver esto es reunir a los líderes de los departamentos externos con su equipo y pedirles que busquen una solución * sin * usted en la sala.
@JarrodRoberson - No estoy seguro de entender su distinción. Soy responsable de controlar la dirección técnica y también soy responsable de sus revisiones. Apruebo PTO y entrego funciones. He estado haciendo ambas cosas durante 10 años. Además, técnicamente no ha habido un enfoque de "palos". Esta política se implementó a través de una discusión de más de 2 horas con todo el equipo. No se presentó dictatorialmente y no ha habido consecuencias. Desde entonces, los ejecutivos han reforzado el mensaje con el equipo y básicamente tuvieron la misma discusión de más de 2 horas.
@JacobG * "se puso en marcha mediante una discusión de más de 2 horas" * es un oxímoron. * "se puso en marcha" * implica una decisión ** unilateral ** dictada por alguien y aplicada. La mayoría de los lugares en los que he trabajado en los últimos 22 años se dieron cuenta de que debería haber una separación entre el liderazgo técnico y la gestión. Se trata de una estructura organizativa muy bien establecida en la mayoría de las empresas grandes (me refiero a miles de millones de $$$ al año) para las que he trabajado como liderazgo técnico. Combinar las dos responsabilidades es una receta para la lucha. Tener discusiones * 2 veces más de 2 horas * debería decirle que la política es mala y el enfoque es peor.
@JarrodRoberson Creo que estamos hablando entre nosotros. 1) Esta empresa es demasiado pequeña para garantizar un gerente de desarrollo no técnico. 2) Esta pregunta realmente se reduce a "cómo influir en un cambio de cultura" independientemente de los detalles del cambio. El hecho es que las personas a cargo reconocen la necesidad de un cambio cultural y han llegado a una conclusión sobre cuál es el cambio. Todos los involucrados están de acuerdo en que el cambio es correcto. La esperanza era que discutirlo con el equipo de desarrollo les llevaría a sacar las mismas conclusiones. Eso no sucedió y este fiasco es el resultado.
+1 esta es una buena respuesta ... aunque prefiero un entorno más estructurado, esta es una respuesta real con sugerencias prácticas.
@JacobG: "Todos los involucrados están de acuerdo en que el cambio es correcto". Sin embargo, dijiste que 3 de cada 5 de los desarrolladores se opusieron firmemente al cambio. ¿Significa esto que los desarrolladores no están "involucrados" en el cambio? ¿O quiere decir que después de las discusiones, todos los desarrolladores acordaron que este cambio era necesario?
@MarkBannister - Perdón por la confusión. Quise decir que todos los responsables que determinaron la necesidad de un cambio cultural estuvieron de acuerdo en que este era un movimiento apropiado.
@JacobG sigues diciendo * lo discutiste con ellos *, no les dijiste cómo iba a ser ahora y aparentemente hubo una discusión durante más de 2 horas. Esa no es una * discusión * sobre un cambio de política. ** Una discusión real ** habría sido * tenemos las siguientes quejas de otros departamentos, una idea de esos equipos es una hora de inicio más temprana, ¿qué otras ideas tienen ustedes que podamos enviar a los otros equipos para resolverlas? los problemas reales que tienen? *. Dado que no parece que tener a todos al 100% del equipo allí temprano sea en realidad el problema.
@JarrodRoberson: Siento que todavía no estoy siendo claro. El liderazgo reconoció el problema sistémico y cultural, ideó una solución a través de una discusión extensa. El componente de puntualidad es un elemento de esa solución. La discusión con el equipo de desarrollo fue llevarlos a través de la misma lógica que llevó al liderazgo a sus conclusiones con la expectativa de que el equipo sacaría las mismas conclusiones. Eso no sucedió porque el equipo no estuvo de acuerdo en que había un problema por resolver. Optaron por centrarse en este tema en particular por encima de todos los demás.
@JacobG una discusión implica comunicación bilateral, por su propia admisión incluso aquí, esta fue una comunicación unilateral de * cómo van a ser las cosas ahora *. * "He programado nuestra reunión diaria de pie a las 9:30 como un motivador adicional". * Es un ** palo ** arbitrario que intenta forzar un comportamiento obediente. Todos los que leen esto perciben que, ¡su "equipo" lo percibió con seguridad! Es una regla que se puso en práctica que ven como un castigo por acciones que aún no se han tomado y se están rebelando. Si no acepta esta percepción, nada de lo que haga será eficaz. Lo tienes claro, no los estás escuchando.
@JarrodRoberson Realmente no sé por qué no nos conectamos aquí. Si 5 departamentos se quejan de 1 (real / válido) y el 1 piensa que los 5 son simplemente celosos / inferiores / deberían superarlo, entonces intentar convencerlos de por qué este cambio sería mejor para todos parece justo. Como dije, el gerente senior me pidió que pusiera el cambio en su lugar, intenté guiar al equipo a través de la lógica que siguió el gerente senior y la respuesta fue que realmente no había ningún problema. ¿Se supone que debo volver a mgmt y decir "lo siento chicos, el equipo de desarrollo cree que el servicio al cliente es un montón de bebés y debería superarlo?"
@JacobG mi punto es ** su acercamiento ** al equipo de desarrollo fue pobre. Si insiste en este enfoque, que parece que sí, ** continuará fallando ** y sus supervisores lo verán fallando. Creo que debería retroceder en nombre de su equipo, * una gran parte del trabajo de los gerentes * es aislar a su equipo de cosas como esta. Al menos debería darle al equipo de desarrollo la oportunidad de encontrar una solución alternativa con la que retroceder. He dado muchos enfoques ** exitosos ** para llegar a un compromiso mutuo. No creo que el ** equipo completo ** deba estar a su entera disposición.
@JacobG deje de pasar tanto tiempo defendiendo su enfoque fallido y justificando las opiniones de otros departamentos y comience a tomar todas las buenas sugerencias sobre ** cómo puede apoyar a su equipo y dejar que su voz sea escuchada. ** Si no cree que deberían haberlo hecho. una voz, bueno, no me gustaría estar en ese equipo. Vea mis predicciones sobre lo que sucederá en mi respuesta.
Al leer esta discusión, se me ocurre que el verdadero problema aquí es que los superiores están tomando decisiones sobre detalles que no deberían preocuparles. Cada nivel debería preocuparse por los resultados inadecuados del nivel inferior. El cómo debería estar en tu cancha. El hecho de que los desarrolladores se estén burlando de todo el mundo en este punto me sugiere que ambos están hartos y no están preocupados en absoluto por encontrar nuevos trabajos si se trata de eso. Si quieren jugar así, es mejor que evalúen la dificultad de reemplazar a la mayoría de un equipo de desarrollo.
#6
+28
Tim
2012-04-27 00:55:45 UTC
view on stackexchange narkive permalink

Lo primero que debe hacer es leer "Peopleware"

Es un error intentar cambiar esto ahora. Yo era gerente en una empresa donde teníamos un horario de trabajo bastante flexible. Uno de nuestros desarrolladores más productivos llegó a las 11 a. M. Me informó por un tiempo. Me dijeron que le hiciera cambiar de horario. Luché contra esta solicitud. Difícil. Fui anulado.

El resultado:

Un desarrollador menos productivo y menos interesado que contribuyó enormemente al equipo. Se volvió mucho menos productivo y útil para el equipo.

Todo por una tonta noción de "puntualidad".

Concéntrese 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 de la misma manera.

Los horarios flexibles son una ventaja, y un empleador que permite horarios flexibles puede atraer a más personas de calidad.

Como "nuevo líder técnico", no hay forma de que pueda cambiar la cultura pronto. Especialmente en la dirección que parece querer. ¿Ha hecho algo para mejorar los roles / trabajos de su equipo?

Primero trabaje para generar confianza con ellos. Muchos gerentes / clientes potenciales primerizos cometen errores como este.

Descubra lo que REALMENTE necesitan los otros grupos. No "tienen que estar aquí a las 9:30". Averigüe realmente cuál es el problema. Luego, busque una solución para eso.

En lugar de decirle a su equipo lo que debe hacer, explique el problema y luego PÍDELES SUGERENCIAS / COMENTARIOS.

Hace una vaga referencia a "causa mucha angustia entre mi departamento y otros departamentos", pero no está claro cuál es esa angustia, ¿están molestos porque los desarrolladores reciben un trato preferencial? ¿Cuál es el problema subyacente real?

He intentado obligarlos y no funciona.

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

De nuevo, lee "Peopleware".

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

¿Quién te está diciendo que deben estar en el trabajo a las 9:30? Otros grupos? ¿Tus jefes? ¿Usted? Resuelva el problema REAL y aborde eso. Cuándo aparecen NO debería ser el problema.

* Nota del moderador: se ha eliminado la discusión extendida en los comentarios. Para continuar con la discusión, llévelo a [chat] (http://chat.stackexchange.com/rooms/3060/the-water-cooler). *
Una vez tuve un colega que apareció a las 12 en punto y se fue cuando le dio la gana.Con sandalias o sin zapatos.Como desarrollador de software, fue tremendo.Fue una de las pocas personas que conocí que claramente era mejor en este trabajo que yo.Tratar de obligar a este tipo a comenzar temprano (a) no tendría éxito y (b) sería la cosa más ridículamente estúpida que podrías hacer.
#7
+20
Kristof Provost
2012-04-13 15:03:29 UTC
view on stackexchange narkive permalink

Independientemente de por qué lo esté haciendo, los miembros de su equipo sienten que les está quitando una ventaja. Para algunos de ellos, puede ser incluso una de las principales razones por las que trabajan para su empresa en lugar de otra.

Básicamente, les está pidiendo que reduzcan su paquete de compensación total.

Es posible convencerlos de que lo tomen, pero necesitará buenos argumentos y es casi seguro que habrá un resentimiento persistente al respecto. Es posible que pierda gente buena por esto o no.

Según su descripción, la razón principal parece ser los celos de otros departamentos. ¿Ha considerado darles a los otros departamentos la misma ventaja?

En resumen: no lo haga a menos que crea que vale la pena perder algunos de ellos por ello.

No son exclusivamente celos y mi error si lo caracterizo como tal. Otros departamentos tienen horarios de atención al público, por lo que el horario flexible sin agregar recursos no es realmente una posibilidad para ellos.
@Chad - La respuesta está implícita en el segundo párrafo: Págales más
@CurtainDog - A menos que el aumento de sueldo dependa de llegar a tiempo, dudo que esta sea una solución duradera. Si es contingente, estamos de acuerdo.
¿Sería posible editar esta publicación y ampliar cómo darle al otro equipo la misma ventaja? Si bien esta publicación ofrece una alternativa, realmente no profundiza ni aborda el hecho de que algunos de los empleados pueden ser trabajadores por turnos que deben tener un horario.
#8
+18
Erik Dietrich
2012-04-23 20:37:03 UTC
view on stackexchange narkive permalink

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

En mi experiencia, "coordinar con otros departamentos" tiende a ser competencia de aquellos con títulos de posición más altos y se dirigió hacia una pista de gestión de proyectos / personas. Los desarrolladores de trabajo diario interesados ​​solo en el código tienden a estar protegidos de esto. En tiendas más estructuradas, es posible que no lo hagan en absoluto y en tiendas más pequeñas, pueden hacerlo de manera más informal.

Nos guste o no, ha heredado una cultura de horario flexible, que es una gran ventaja para la mayoría de los desarrolladores. Quitarles eso en uno de sus primeros actos como líder no solo les parecerá tiránico (cuando les explique que las 9:30 no es tan temprano, está imponiendo las suyas propias). programar en ellos, arbitrariamente en su opinión), pero es realista la resta de un beneficio sustancial. Es posible que le guste trabajar con un horario en particular y no considere que esto sea un beneficio significativo, pero probablemente lo consideren invaluable. Considere esto a la par con decirles que les está quitando una semana de sus vacaciones o recortando su salario en un pequeño porcentaje.

Para cambiar eso, puedes usar la zanahoria o el palo. Estás hablando de usar un palo y, tal vez, un palo más grande. Si sigue ese camino, planearía contratar algunos desarrolladores nuevos, ya que supongo que algunos miembros de su equipo comenzarán a realizar entrevistas en otras empresas. Yo personalmente iría por la ruta de la zanahoria con el fin de conseguir la aceptación de la eliminación de este beneficio dejando en claro que las futuras promociones y avances serán decididos por aquellos que "coordinen con otros departamentos". Es decir, los líderes / personas importantes están al principio, trabajando con otros equipos, asumiendo responsabilidades, etc. Los "novatos" obtienen el beneficio flexible, pero las personas que se toman en serio el avance llegan a tiempo.

Si crea esa cultura, sospecho que algunos de sus desarrolladores comenzarán a llegar a tiempo por su propia voluntad. Tanto por el interés en avanzar como por la percepción de que "las personas importantes llegan temprano".

#9
+13
aroth
2012-07-12 11:03:25 UTC
view on stackexchange narkive permalink

La respuesta corta es que NO debe 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 realiza o no.

Si su equipo no está haciendo su trabajo, entonces ese es un problema aparte. Pero si están haciendo las cosas, ¿por qué los acosa solo porque otros departamentos lo han estado acosando a usted?

Parte de su papel como líder es aislar a su equipo de las distracciones triviales y las críticas provocadas por fuentes externas. Si su reacción a otras personas que se quejan de los miembros de su equipo es transmitir las quejas a los miembros de su equipo y / o dictar cambios basados ​​únicamente en esas quejas, entonces está fallando en su trabajo. Sugeriría que, asumiendo que su equipo de hecho está haciendo su (s) trabajo (s) (que parece que sí, ya que no presenta quejas sobre su productividad), una mejor manera de responder a tales críticas es decirle al quejoso "sí, bueno, mis muchachos trabajan duro y ofrecen resultados sólidos consistentemente, y eso es lo único que importa; entonces, ¿por qué no dejas de preocuparte por cómo mi equipo maneja sus tareas y vuelves a las tuyas?".

Y, por supuesto, si cumple 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 casa fuera del horario laboral normal". 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 queden hasta tarde o dedican tiempo extra en casa.

Excepto que el autor afirma que el trabajo no se está haciendo.
@Ramhound - No, no lo hace, al menos no en la publicación original. En la larga lista de ediciones, menciona que el rendimiento ha disminuido recientemente. Pero como el equipo siempre ha tenido horarios de trabajo flexibles en el pasado, todavía no hay nada que demuestre que la disminución del rendimiento esté correlacionada con las horas de trabajo, o que establecer una hora de inicio firme provocará alguna mejora. A juzgar por la publicación original, parece que el autor está más preocupado por los comentarios negativos que recibe de otros departamentos.
Parece que "las palizas continuarán hasta que mejore la moral".
#10
+13
bethlakshmi
2012-07-12 21:36:53 UTC
view on stackexchange narkive permalink

No te envidio este: como compañero entrenador, sería difícil para mí. Y, honestamente, creo que perderás gente por eso. Creo que tiene un síntoma único que proviene de la puesta en marcha -> cambio de cultura de tamaño medio, y no todos los desarrolladores van a realizar este cambio con éxito. Creo que debe estar preparado con descripciones de trabajo y conocimiento de cómo abre las solicitudes de trabajo y creo que debe poner énfasis en la capacidad de contratar nuevas personas y mejorar la documentación ...

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

Estoy de acuerdo en que ESTÁS quitando una ventaja. La flexibilidad en la hora de inicio es muy importante para algunas personas, y habla de una cultura informal que puede ser una fuerte preferencia para algunas personas. Presumiblemente, a medida que la empresa 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 es posible que haya podido ofrecer algunos planes de inventario ingeniosos, aumentos de sueldo u otras mejoras. Si nada de eso es cierto, entonces debe preguntarse si tiene una empresa próspera de & en crecimiento o una empresa que se está hundiendo en la desesperación.

El truco es que la gente a menudo no puede conectar los puntos entre estos nuevos valores: agrega y la eliminación de la ventaja favorita. Puede intentar explicarlo, pero para algunas personas esto no es una buena compensación, y este no es un caso en el que pueda ofrecer la opción. Es "a mi manera o por la carretera", ya que tiene un impacto organizacional que no necesariamente se puede sentir dentro del equipo, pero que se experimenta y se apoya en los niveles más altos de la empresa.

Suena como ha hecho las cosas correctas:

  • lo ha expuesto claramente

  • ha hablado del motivo y necesidad de cambio

  • Se ha comprometido uno a uno (y supongo que continuará haciéndolo) para solucionar casos individuales a medida que surgen

  • Ha dado su opinión

Creo que estás pensando en "¿realmente lo dice en serio?" punto en el que, en su mayor parte, le está demostrando a la gente que habla en 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 un gran problema y que las reuniones que tienen un lapso corto (como stand ups en un sprint ágil) no deberían ser tan difíciles de comenzar. de la jornada laboral que una conexión de autobús perdida o mal tráfico va a ser un problema habitual. Pero esto es algo regional: los diferentes lugares tienen grandes variaciones en la situación del tráfico. Así que eso es tanto conocer su región y saber a partir de las quejas individuales lo que es razonable.

El resto es simplemente idear un mecanismo lo suficientemente debilitante como para demostrar que habla en serio. Un día de pago fijo es una opción y está dentro de sus derechos legales, aunque cualquier mecanismo que se me ocurra lo vería con los abogados. También lo es un sistema de alerta formal que conduce a una acción disciplinaria. Supongo que su departamento de recursos humanos podría tener sugerencias ...

Mucho depende de lo que el trabajo pueda tolerar: cuando envía a alguien a casa, también pierde en el trabajo de ese día, lo que afecta su costo Horario de &. Cuando tienes un sistema de advertencia que conduce a una acción disciplinaria, incluido el despido, te ahorras el resto del trabajo del día, pero te arriesgas a tener que despedir al empleado.

Creo que la cuestión es que, cuando te enfrentas a los castigos , tienes que estar preparado con un castigo que sea lo suficientemente dañino como para ser tomado en serio y recordar que "no estás haciendo tu trabajo si no estás haciendo esto".

#11
+10
weronika
2012-04-14 08:21:56 UTC
view on stackexchange narkive permalink

Parece que aquí hay una desconexión entre la forma en que sus desarrolladores ven el problema y cómo los otros departamentos (o sus superiores, o quienquiera que sea el que realmente exija este cambio) ven el problema. Sugeriría intentar cerrar esa brecha, en múltiples etapas si es necesario.

Primero, ¿los desarrolladores están de acuerdo en que existen buenas razones para este cambio? Si no están de acuerdo, ¿tienen buenos argumentos en contra o sugerencias alternativas? Si lo hacen, debe llevarlos a la gerencia y ver si relajan el requisito de tiempo, o si pueden explicar por qué las alternativas no funcionan y los contraargumentos no resuelven el problema, para que usted pueda Vuelve con tus desarrolladores y dales una explicación más completa. Continúe el intercambio tanto 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 lo hacen cree que las razones son buenas y resiente la idea, comuníqueselo a la gerencia Explique que podría obligar a los desarrolladores a hacer lo que se desea, pero provocará resentimiento, menor motivación, muy posiblemente menor productividad o incluso la salida de los empleados. Asegúrese de que la administración comprenda esto y aún esté de acuerdo en que es importante hacer cumplir la hora de inicio (y nuevamente, comuníqueselo a sus desarrolladores), de lo contrario, puede terminar siendo responsable de un cambio que hizo perder a la empresa más de lo que ganó.

(Una nota personal: he estado en la posición de que me digan que venga a una hora determinada, en lo que respecta a los empleados, no hay una buena razón, y realmente es extremadamente desmotivador . Es muy importante asegurarse de que las personas comprendan las razones y no sientan que solo está cambiando la política por capricho o porque no confía en ellas).

#12
+9
Michael Durrant
2012-05-06 19:27:24 UTC
view on stackexchange narkive permalink

Solía ​​trabajar en una organización sin fines de lucro que tenía este problema. Las reuniones siempre comenzaban tarde, 10 minutos tarde se convirtieron en un "estándar".

Luego obtuvimos un nuevo gerente de proyecto para un gran proyecto clave (y uno con un cronograma fijo). Ella llamó a la primera reunión. La gente entró como de costumbre, minutos tarde y charlando casualmente. Se sentó en su silla y no dijo nada, nada en absoluto, durante varios minutos. Finalmente, la charla "cesó" hasta que se hizo el silencio. Todos estábamos esperando escuchar para hablar. Dejó que el silencio continuara un poco más. Ella miró a su alrededor y dijo: "Necesito dejarlo en claro. Las reuniones comienzan a tiempo. Si vas a llegar 5 minutos tarde, no te molestes en venir, solo mírame después. Bien, ahora para el proyecto estamos haciendo esta semana [lo que sea] ... ". Esto causó una GRAN impresión y la gente hizo un esfuerzo real para llegar a tiempo a sus reuniones.

Nota: Se agregó una respuesta adicional a continuación.

Cuenta el trabajo realizado de forma remota.

A menudo, los productores más importantes hacen una gran parte de su trabajo de forma remota de todos modos, por lo que a veces dedicar tanto tiempo de forma remota como en la oficina. Este es un punto importante para considerar y comunicarse con los otros departamentos. Esa comunicación debe ser sutil: no convoques una reunión, simplemente comienza a buscar formas de mostrar "sí, joe estuvo despierto hasta tarde anoche trabajando en x" y "sí, Mary arregló eso el domingo, estaba despierta hasta la medianoche

Habla abiertamente sobre el viaje diario. Si alguien llega a las 10.30, su viaje diario puede ser de 15 minutos. Si necesita llegar a las 9 o 9.30, su viaje diario puede ser de una hora. Además, sería lo mismo se vuelve a casa si trabajaron 8 o 9 horas. Muchas personas sienten que esto es una gran pérdida de su vida. Prefieren trabajar de forma remota por un tiempo y luego volver. Intente integrar este hecho con sus necesidades al configurar veces y asegúrese de que otros departamentos también lo sepan, nuevamente mencionándolo con frecuencia.

Asegúrese de utilizar la tecnología para ayudar. Por ejemplo, trabajo virtualmente, el 100% del tiempo. Por lo tanto, tener Skype activado, mostrar mi estado como en línea, una cámara de video, etc. también puede ayudar.

La razón por la que estoy votando a favor de esto es porque la idea del gerente es genial: prácticamente le dio a todos una "tarjeta gratis para salir de las reuniones".
#13
+8
Spoike
2012-07-17 14:04:35 UTC
view on stackexchange narkive permalink

Habiendo estado en situaciones similares, aunque es cierto que en menos tiempo que el OP, solo tengo esto que decir sobre el estado de su situación:

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

... sería intentar comenzar las reuniones a las 11 en punto. No se preocupe, no está "cediendo". En cambio, está redirigiendo el flujo de manera muy similar a los principios detrás del Aikido. En cambio, la idea es centrarse en permitir que su equipo haga cosas importantes, ya que es el punto primordial porque realmente hay un problema serio que debe abordarse:

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

Sin embargo, tener su equipo para presentarse a las 9:30, lo cual puedo admitir que no es temprano, no es una solución para esto problema. Lo intentaste y fallaste, así que deja de insistir en hacerlo. Deja de golpearte la cabeza contra una pared de ladrillos. Mi único consejo aquí es que siempre valore la comunicación en lugar de las reuniones establecidas arbitrariamente.

Dado que los otros departamentos comienzan a las 8, puede utilizar esta última reunión del equipo para su propio beneficio . Entre las 8 y las 11 tiene 3 horas para ayudar a su equipo con actividades de gestión de proyectos tales como (sin ningún orden o prioridad en particular):

  • Ir a reuniones y recopilar objetivos y requisitos de los otros departamentos
  • Averigüe qué se terminó desde ayer
  • Maneje las expectativas y los compromisos con los otros departamentos sobre lo que se necesita y se puede hacer durante la jornada laboral
  • Entregue buenas y malas noticias a los otros departamentos
  • Actualice los planes relevantes para el equipo si los hay
  • Averigüe qué problemas de arquitectura de código y software deben tener atención hoy
  • Decir "NO" a solicitudes que no aportan ningún valor comercial
  • Acepte las críticas de los otros apartamentos y discúlpese con la seguridad de que los problemas se solucionarán
  • etc. (siempre hay algo que debe abordarse)

Y finalmente antes de la reunión resumir un breve para el equipo sobre lo que está sucediendo, con el fin de darles algo de conciencia de la situación. Cuando la reunión comienza a las 11 y todos están frescos para ponerse a trabajar, usted tiene la información y un protocolo de reunión preparado para ellos. Puede hacer que el resumen y las minutas de la reunión se escriban como un boletín y enviarlo como un correo electrónico en algún momento después de la reunión como un recordatorio amable.

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

  • Solicite estimaciones para las tareas que deben realizarse, especialmente aquellas que son de alta prioridad. No tiene que ser preciso, como en minutos. Con esto puedes decidir compromisos y plazos de forma mucho más clara con los demás departamentos. Si no pueden dar una estimación para una tarea, pídales que la resuelvan durante el día o el siguiente.
  • Pregunte por impedimentos o si necesitan ayuda con algo, anótelo y compruebe si esos problemas se pueden solucionar y si se solucionan.

Después de un tiempo, probablemente pueda pasar gradualmente a tener las reuniones antes. Pero inicialmente ir contra la corriente no es el camino a seguir y solo conduce a una cultura aún más infecciosa (en la que la única forma de reparar es reemplazar a todo el equipo). Si son, como dices, "primadonnas", entonces tu verdadero trabajo es convertirlas en primadonnas increíbles que se entreguen con alta calidad. Está claro que tu equipo tenía y quiere autonomía, así que comience a explotar esa cultura en beneficio de los objetivos de su empresa.

Cuando haya logrado formar un equipo confiable, mediante la comunicación en lugar de la coerción, puede salir tres horas antes que todos los demás en el equipo sabe que está haciendo su trabajo (pero aún así estará disponible si la mierda golpea al fan) Eso es confianza en la que puede contar.

Creo que este es un consejo más bueno y sólido y un buen enfoque alternativo que conduciría al éxito. El papel de un ** gerente / líder de equipo ** es aislar al equipo del ruido y la confusión y eliminar los obstáculos que reducen su eficiencia. ¡Esta respuesta propone un enfoque para hacer todas esas cosas!
#14
+6
pap
2012-04-26 17:26:40 UTC
view on stackexchange narkive permalink

Estoy leyendo comentarios y respuestas y debo confesar que estoy un poco atónito. ¿Desde cuándo el hecho de que la gente se presente a tiempo es una "pérdida de un beneficio"? ¿Desde cuándo el tiempo flexible no tiene que preocuparse por el impacto de sus acciones en el resto del equipo y la empresa?

Por lo que leí en la pregunta y los comentarios, el comportamiento de los miembros de su equipo es demostrablemente perjudicial y costoso para la empresa. Y después de intentar razonar y llegar a un acuerdo, la situación no ha mejorado (y por cierto, las 9.30 no es temprano o de ninguna manera irrazonable).

Explique a su equipo que no tiene problema con el tiempo flexible, pero que implica una cierta cantidad de responsabilidad personal para asegurarse de que su flexibilidad no esté afectando el trabajo de otros (en su equipo u otros equipos). Como su equipo claramente está fallando en la parte de responsabilidad, diría que con vigencia inmediata y hasta nuevo aviso, todos los tiempos flexibles deben ser aprobados por usted de antemano. No presentarse a tiempo por la mañana sin aprobación o una excusa razonable (no, el despertador no sonó no es aceptable) resultará en una acción disciplinaria como pago de atraque o tiempo de vacaciones.

Sea muy claro por qué sucede esto y qué le ha obligado a tomar estas medidas. Señale que esto no es algo que desee hacer, sino algo que se ha obligado a hacer. También tenga claro que estas políticas restrictivas pueden levantarse una vez que la situación mejore.

** Comentarios eliminados. ** Utilice los comentarios para mejorar la respuesta o solicitar aclaraciones, no para una discusión general. Para una discusión más amplia, utilice [chat].
#15
+6
anonymous
2012-04-24 00:35:26 UTC
view on stackexchange narkive permalink

Los demás plantean muchos puntos positivos 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 todo funcione sin problemas. Teniendo esto en cuenta, debe averiguar cuándo otros grupos necesitan acceso confiable a los desarrolladores y si hay espacio para la 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 se satisfaga esa necesidad. 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 opción es asegurar que las "horas difíciles" se suavizan tanto como sea posible. Por ejemplo, si las "horas centrales" son de 11:00 a 15:00, también puede asegurarse de que las horas centrales del viernes no estén presentes y que el viernes sea un verdadero día de horario flexible. Como el martes, miércoles y jueves se consideran tradicionalmente los días más productivos de la semana, es posible que pueda aplicar las horas principales a esos días y permitir que el lunes y el viernes también sean días flexibles completos.

En términos de garantizar que se cumplan las horas, si la dirección desciende desde arriba y es aprobada por la alta dirección, en última instancia, los desarrolladores deben adherirse a ella como parte de su empleo. Debe hacer todo lo posible para asegurarse de que se incorpore gradualmente y, si algunos desarrolladores tienen un tiempo flexible escrito en su contrato de trabajo, debe abordarse (por ejemplo, cambiando su compensación y beneficios, protegiéndolos, etc.); sin embargo, en algún momento tendrá que asegurarse de que la política debe cumplirse, lo que también puede requerir la disciplina oficial de los empleados. Del mismo modo, si algunos optan por irse, puede valer la pena intentar ver si están dispuestos a quedarse con los cambios de compensación y beneficios; sin embargo, es posible que también deba aceptar perder a algunos de los desarrolladores.

En última instancia, si su trabajo requiere que haga cumplir un cambio cultural en el grupo para satisfacer las necesidades de la empresa, entonces sus opciones estarán limitadas hasta cierto punto. Puede y debe hacer todo lo posible para suavizar el cambio y obtener cualquier compromiso con otros grupos como pueda, pero eventualmente tendrá que hacer cumplir el cambio y aceptar cualquier cambio de personal que pueda venir con él.

#16
+2
Karlson
2012-04-12 23:14:29 UTC
view on stackexchange narkive permalink

Todavía hay varias vías disponibles para manejar este problema, una de las cuales sería cambiar la función que desempeña el departamento, como por ejemplo: si está trabajando con desarrolladores de software, podría cambiar la función de una determinada persona durante la semana para que hagan soporte para los otros departamentos, lo que requiere que uno o más ingresen a las 9 o antes y si eso no funciona, siempre puede invocar una cláusula de insubordinación que normalmente está presente en cualquier manual de empleo en EE. UU. Personalmente, siempre me he opuesto al uso de esta cláusula, que le da al gerente una vía para reprender e incluso despedir a alguien por una causa , pero en su caso esto puede ser apropiado. Así que revise el manual del empleado y discútalo con su superior si tiene alguno de lo que hará.

La idea básica es la siguiente:

  1. Usted establece la regla de que al menos 1-2 o todas las personas deben estar en el trabajo a la hora X.
  2. Si los miembros de su equipo no tienen una excusa válida para no presentarse o persistir en esta práctica, usted como gerente debe reprenderlos y posiblemente despedirlos.

Como gerente haciendo lo que yo descrito sería el último recurso , pero según lo que describe, es posible que haya llegado a ese punto. Hay muchos artículos que pueden constituir insubordinación de empleados que puede encontrar en línea y estos son solo algunos ejemplos:

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

Habiendo dicho todo eso, tengo una pregunta: ¿Realmente necesitas que tu equipo esté antes cuando lleguen?

En respuesta a su pregunta, sí. Contamos con múltiples departamentos con los que trabajamos habitualmente. Estos departamentos están entre las 8-9 y salen entre las 4: 30-5: 30. Una hora de inicio tardía y almuerzo significa, como mínimo: 1) No hay reuniones antes de la 1 pm y 2) Perder medio día o más si alguien está esperando algo de nuestro departamento. Increíblemente ineficiente.
@JacobG la consecuencia clásica es "Te quedas hasta tarde para terminar el trabajo o atracamos el tiempo de vacaciones". Con respecto a que "todos" encuentren a las 9:30 una hora de inicio razonable: yo no. Por otra parte, trabajo hasta las 8-9 de la noche, a veces más tarde y, a menudo, después de irme a casa. Esas son mis horas más productivas, y no las dedicaría si se esperara que entrara por la puerta a las 09:30 en punto "o si no", me convertiría en un trabajador de 9 a 5. Cada equipo es único y espero que lo esté considerando en su evaluación ...
@Jacob: ¿qué tipo de equipo de desarrollo es este? ¿Son ustedes solo otra empresa que mantiene la aplicación X interna, o estos desarrolladores de alta calidad están escribiendo un código sólido que es la columna vertebral de su empresa? Si es lo último, algunos de ellos esperan poder trabajar hasta tarde desde casa y llegar tarde no parece sorprendente. Le sugiero que intente adaptarse a eso. Los desarrolladores de calidad son * increíblemente * difíciles de encontrar. Y siempre tienen otras opciones si el trabajo actual no está funcionando.
@voretaq7 no se lo toma a mal, pero creo que es una cuestión de costumbre. Si adquiere el hábito de irse a la cama a las 11 p. M. En lugar de a las 3 a. M. Y levantarse a las 7 a. M. En lugar de a las 9:30 a. empieza a tener un poco de sueño. Los humanos se adaptan.
@JacobG ¿Por qué 'desperdiciar medio día'? ¿Llegan estos otros equipos a las 8 de la mañana y de repente se dan cuenta de que necesitan algo de un desarrollador?
@robertc Ciertamente hay ocasiones en las que los otros equipos llegan al 8 y ven que hay algo que necesita la atención del desarrollador. Pero ese no era mi punto. Mi punto fue que si otro departamento está bloqueando algo del equipo de desarrollo, el bloqueo nunca se liberará hasta al menos la mitad del día del solicitante. A veces eso está bien y muchas veces es simplemente un inconveniente.
@JacobG Pero no entiendes mi punto, ¿por qué están esperando hasta las 8 de la mañana del día en que necesitan algo para decidir decirle al desarrollador que necesitan algo?
@robertc Porque no saben que necesitan algo hasta las 8 de la mañana. "Un cliente llamó y estaba experimentando este problema ..." "Parece que estos datos están dañados ..."
@JacobG Ninguno de los ejemplos que ha enumerado son tareas de desarrollo. Incluso si sus desarrolladores brindan soporte al cliente (como está insinuando), ¿por qué todos sus desarrolladores deben estar en la oficina en un momento determinado para brindar soporte? ¿Por qué ha prometido tiempos de respuesta específicos a los clientes y otros departamentos sobre problemas de soporte cuando no tiene personal de soporte dedicado?
He trabajado en un puñado de equipos que se rompieron debido a reglas como la que se sugiere aquí. Un consejo: la gente puede comenzar a llegar temprano durante algunas semanas. Pero después de eso, los verás trabajando para la competencia.
#17
+2
A quiet hum
2018-06-24 21:22:16 UTC
view on stackexchange narkive permalink

Básicamente, tienes que decidir qué es más importante, hacer el trabajo correctamente o sentarte en tu escritorio durante 8 horas en los horarios prescritos.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...