Como líder de equipo, ¿cómo puedo introducir cambios en el equipo sin resistencia por parte del equipo?

Me han unido a un nuevo equipo y un nuevo proyecto como líder del equipo. Esta posición es la primera vez para mí. Estoy liderando 3 módulos. Estoy por encima de los 3 líderes de módulo. He identificado algunas áreas donde se requieren mejoras en el equipo, incluidas también las prácticas de codificación. Me gustaría introducir algunos cambios en el equipo que sean para beneficio del equipo y que mejoren la productividad del equipo. Tengo dificultades para convencer a estos líderes de módulo sobre mis nuevas prácticas y cambios. Algunas veces conduce a conflictos de opinión y, por lo tanto, a discusiones acaloradas. No quiero imponerlos a la fuerza usando mi autoridad y poder. Mi pregunta específica es,

¿Cómo puedo convencer a los líderes del módulo sin conflictos de liderazgo y traer los cambios que quiero al equipo sin resistencia?

Investigaciones que he hecho:
He buscado en el workspace.SE. Sin embargo, encontré que la publicación Cómo lidiar con un miembro mayor del equipo que se resiste a un líder del equipo me parece relevante. Sin embargo, habla principalmente de una persona específica que tiene una mentalidad diferente. Aquí tengo varios miembros del equipo que se resisten a invitar a cambiar la forma en que lo están haciendo. Por lo tanto, creo que mi publicación es diferente a la especificada.

¿Por qué se resisten? ¿No reconocen el problema que está tratando de resolver o no creen que su solución resolverá el problema?
Me parece que esta respuesta se aplica a su situación: Workplace.stackexchange.com/questions/9603/…
@Sign: Estoy tratando de traer nuevas prácticas de codificación, prácticas de organización que son nuevas en lo que están haciendo. Cada vez que escucho de ellos, es difícil traerlos al equipo y siento que aumenta la carga adicional para ellos.
¿Ha considerado cambiar la forma en que está introduciendo estas prácticas? ¿Ha articulado los beneficios de lo que está proponiendo? ¿Les ha permitido opinar sobre cómo se hace para el equipo para que no sea solo porque usted dijo que se debe hacer de esta manera?
¡Aumenta el número de palizas hasta que la moral empiece a mejorar!
La Resistencia al Cambio ocurrirá el 100% del tiempo. Sé consciente de que nunca te deshaces de él, lo superas.
Un poco de resistencia es saludable y no hay nada de qué preocuparse.

Respuestas (5)

Este es mi mejor proceso para lograr que las personas a cargo de los subcomponentes estén de acuerdo conmigo. Tuve que hacer el mismo tipo de cosas en mi primer trabajo de gestión:

Conozca el problema y su prioridad

Como líder, este es realmente su territorio. Como la parte superior de esta sección particular del organigrama, le corresponde a usted decidir cómo se deben gastar los recursos generales y qué necesita mejorar con mayor urgencia. Asuma la posición de que los líderes del equipo deben convencerlo de que un problema diferente es más urgente, pero esté abierto a que lo convenzan, ya que esta es una conversación de dos vías. Ellos ven cosas que tú no... tú ves cosas que ellos no... así que necesitas colaborar para descubrir cuáles son las verdaderas prioridades más importantes.

Pero al final, la decisión sobre lo que hace y cómo afecta las obligaciones de su equipo es su decisión. Entonces necesitas saber:

  • el problema : ¿qué está realmente mal con el código tal como está?

  • el impacto : ¿por qué y cómo está ralentizando la productividad? ¿Qué te trae a este nivel de certeza?

  • la prioridad relativa - ¿qué tan urgente es esto? ¿Es lo suficientemente importante como para causar un retraso? ¿Es importante que el cambio sea consistente, en cuyo caso, cuándo ocurre la rehabilitación del trabajo existente y qué se baraja para permitir eso? Es posible que los subordinados no avancen si no puede dar una dirección clara al respecto.

  • el ultimátum - ¿Es este un caso que encaja en el modelo "si no lo hacemos... entonces no podemos..."? Entonces hay un ultimátum. Vincular esto a las cosas que tus clientes potenciales quieren hacer es increíblemente poderoso. Por ejemplo, la mayoría de los desarrolladores de software quieren lanzar una pieza exitosa de software, si no puede lanzarlo o venderlo sin estándares de codificación decentes, esa es una motivación poderosa.

Tener un plan incompleto

El bosquejo es tan importante como el plan... he aquí por qué:

  • Un requisito de la gerencia sin pensarlo parece imposible. Es frustrante pensar que su gerencia solo hace demandas al azar y no ha pensado en si es realmente factible o cómo podría lograrse. Tener un plan muestra que intentaste ver un camino hacia el éxito.

  • Debe ser incompleto, no solo se equivocará en los detalles, porque no sabe lo que sabe su equipo, sino que le digan con detalles insoportables cómo hacer algo es desmoralizador. Estas personas están en posiciones de liderazgo porque son capaces de desglosar y ejecutar grandes porciones de trabajo; permítales aprovechar sus capacidades. Si no pueden, tiene un problema de habilidades de equipo y no un problema de "seguir órdenes".

Hay muchas posibilidades de que te equivoques en el plan. Serás demasiado específico en los lugares en los que pensabas que tenías una pista y no lo suficientemente específico en un área que alguien en el equipo llamará "absolutamente vital". Bien, entonces el trabajo de sus clientes potenciales es ayudarlo a refinar el plan.

Refinar el plan juntos

Si ni siquiera lo intentan, pregunta por qué. ¿Por qué es esto tan loco? ¿Por qué es imposible? ¿Por qué no hay valor aquí? Siga volviendo al problema que ve y pida mejores ideas. Tal vez los estándares de codificación NO SON la forma de resolver este problema o son demasiado costosos para ser factibles. Así que desafíelos para que lo ayuden a solucionar el problema. He tenido muy pocos casos de personas que se niegan a admitir que HABÍA un problema. Sin embargo, me han corregido (muchas, muchas veces) sobre el hecho de que el problema no tenía la causa raíz que yo creía. Otra razón por la que ese plan es incompleto: te da la oportunidad de tirarlo por la ventana sin invertir mucho tiempo.

El desafío es que tienen que convencerte. No acepte una proposición sólo para evitar conflictos. Haga preguntas y obtenga soluciones alternativas examinadas. Convénzase de que su equipo tiene razón antes de estar de acuerdo.

Una vez que tenga una solución, puede elaborar el plan real; tal vez esté arreglando el plan con el que entró a la reunión. Tal vez sea crear un plan completamente nuevo juntos...

El objetivo aquí es ser lo suficientemente flexible para hacer el trabajo. Sepa lo que le importa y lo que no le importa. Sepa en qué está dispuesto a gastar dinero y tiempo y qué no es razonable.

Use uno a uno como respaldo

Hay momentos en que las personas discutirán sin razón aparente. Pueden ser demasiado emocionales, ilógicos o simplemente sin sentido. Aquí es cuando las reuniones uno a uno son un buen respaldo. Las personas expresarán sus temores y preocupaciones de manera diferente cuando hablen con usted en privado. Y, a veces, las personas inteligentes con buenas ideas no las expresan en las reuniones.

Cuando encuentre una resistencia verdaderamente inexplicable, elimine el caos de las comunicaciones grupales y llévelo a uno a uno. También te permite forzar la retroalimentación. No hay nada como hacer una pregunta provocativa y luego esperar en un silencio incómodo hasta que su persona se acerque y diga algo, particularmente porque su "silencio incómodo" puede ser el "momento de bendito alivio" de su persona mientras ordena sus pensamientos y piensa en algo. verdaderamente perspicaz. Es difícil lograr esto en un entorno de equipo, ya que todos los miembros del equipo se suman a la mezcla.

Hacer cambios desde el principio en un rol recién implementado no siempre sale bien. El cambio por sí mismo es difícil de digerir para las personas, pero aún más difícil para aquellos en los que no se confía.

A lo largo de los años, siempre he respetado a los nuevos gerentes (clientes potenciales, lo que sea) que examinan el panorama primero en su nuevo rol (independientemente de si son nuevos en la empresa o veteranos) para evaluar la situación actual antes de recomendar cambios.

También he trabajado para lo contrario, donde los individuos recién nombrados en el poder salen a hacer cambios para tratar de probar algo y resulta grosero, vulgar y arrogante. La mitad del tiempo no vería cómo podrían saber qué cambios sugerir sin primero comprender el entorno específico en el que trabajan ahora. ¿Están simplemente aplicando ciegamente políticas y prácticas de la industria sin saber cómo opera el equipo actual? (es decir, "¡Todos vamos a utilizar una metodología ágil con reuniones diarias de scrum, estos estándares de código y estas 2 arquitecturas de aquí en adelante!")

Un buen líder tomará un asiento trasero y aprenderá el nuevo entorno, equipo y rol (usted dijo que es nuevo en el rol) antes de realizar cambios. La única excepción a esto podría ser en el caso en que la alta gerencia lo haya incluido en este rol con la introducción de "Bob fue contratado para este nuevo puesto para cambiarlo y limpiar las deficiencias de la persona x". Sin embargo, creo que esta es la excepción. en oposición a la regla.

Conozca su nuevo rol, equipo y entorno antes de sacudir el barco. Obtendrá más respeto y éxito con su equipo a largo plazo.

Hacer cambios desde el principio en un rol recién implementado no siempre sale bien ; está de acuerdo al 100%. Hace que sea muy fácil para cualquiera que no esté impresionado por los cambios simplemente decir "este tipo no entiende nuestro trabajo/situación/equipo/etc." Necesitas que crean que entiendes la situación actual.

Cómo ganar amigos e influir en las personas tiene estas sugerencias que pueden valer la pena considerar:

Doce maneras de ganar a la gente a su manera de pensar

  1. La única manera de obtener lo mejor de una discusión es evitarla.
  2. Mostrar respeto por las opiniones de la otra persona. Nunca digas "Estás equivocado".
  3. Si está equivocado, admítalo rápida y enfáticamente.
  4. Comience de una manera amistosa.
  5. Comience con preguntas a las que la otra persona responderá que sí.
  6. Deje que la otra persona hable mucho.
  7. Deje que la otra persona sienta que la idea es suya.
  8. Trate honestamente de ver las cosas desde el punto de vista de la otra persona.
  9. Sea comprensivo con las ideas y los deseos de la otra persona.
  10. Apelar a los motivos más nobles.
  11. Dramatiza tus ideas.
  12. Lanza un desafío.

Sea un líder: cómo cambiar a las personas sin ofender ni despertar resentimiento

  1. Comience con elogios y aprecio sincero.
  2. Llamar la atención sobre los errores de las personas de manera indirecta.
  3. Habla de tus propios errores antes de criticar a la otra persona.
  4. Haga preguntas en lugar de dar órdenes directas.
  5. Deja que la otra persona salve las apariencias.
  6. Elogie cada mejora.
  7. Dale a la otra persona una buena reputación a la que estar a la altura.
  8. Utilice el estímulo. Haga que la falla parezca fácil de corregir.
  9. Haz feliz a la otra persona por hacer lo que sugieres.

El otro punto a considerar aquí es qué tan bien está escuchando los problemas que tienen los líderes del módulo sobre lo que quiere hacer. Si tienen inquietudes que son cosas que usted no sabía acerca de la empresa, eso bien podría indicar por qué las cosas no se están haciendo como pensó que deberían hacerse. Si eres relativamente nuevo, entonces consideraría la idea de tratar de hacer sugerencias en lugar de órdenes enérgicas que solo agregarán más tensión.

Comience preguntando qué puede hacer para facilitar su trabajo. Cualquiera puede saltar a un equipo/proyecto existente y encontrar fallas. Nunca sabes; es posible que deseen las cosas más simples: computadoras nuevas, un mejor sistema de seguimiento de errores, horario flexible, acceso a materiales de capacitación, mejor café, etc. Tendrá más credibilidad cuando haga sus sugerencias y serán más receptivos si usted He eliminado algunos de sus obstáculos y proporcionando una capa de abstracción .

La confianza no se gana pidiéndole a la gente su confianza sino brindándoles la tuya.

Votaría este +100 si pudiera. Las personas no se resisten al cambio, se resisten al cambio en el que no creen. Ayude al equipo con los cambios que quieren hacer en lugar de forzar los que usted quiere hacer, es casi seguro que saben mejor lo que debe cambiar de todos modos.

La palabra clave aquí es Equipo.

Si adoptas la postura de "Así es como lo vamos a hacer, fin de la historia", vas a recibir un empujón.

Por otro lado es mejor tener objetivos claros de lo que se quiere lograr y permitir que el equipo construya el camino hacia ese objetivo.

Entonces, si cree que el proceso X tiene fallas, señale las fallas en el proceso y los problemas que causa. Es útil tener algunas métricas para respaldar sus puntos. Después de eso, hable con el equipo sobre la mejor manera de resolver esto.

En este punto, puede sugerir cómo desea que se aborde, pero no fuerce el problema. Si alguien lo derriba, pídale que sugiera una mejor opción.

Sugiera ejecutar esta opción durante un tiempo fijo para determinar las métricas, luego, si no hay una mejora importante con respecto al sistema actual, la cambiará nuevamente.

Si no pueden ofrecer una solución, dígales lo que sugirió que es el camino a seguir, y todos harán un seguimiento en unas pocas semanas para ver si el enfoque se puede refinar o cambiar.

El punto para transmitir que el equipo está buscando soluciones a los problemas que ha visto en los procesos actuales.

En los casos en los que tenga cambios basados ​​en la opinión (p. ej., el formato del código fuente siempre es divertido), haga que todos estén de acuerdo en un formato fijo y, si no pueden, usted lo configura, entonces lo hace. Si alguien se niega, entonces dígale que es libre de escribir en el estilo de codificación que desee, pero que no podrá registrarse hasta que ese código cumpla con el estándar establecido para el proyecto. Cualquier registro que rompa esta convención no se insertará en la compilación.