¿Cómo lidiar con un informe directo del líder del equipo que actúa de manera poco profesional?

Al final, la única respuesta correcta a cualquier pregunta sobre la gestión de un miembro del equipo problemático es "Comprender sus motivaciones, reaccionar en consecuencia".

Realmente no podemos decirte cuáles son sus motivaciones. Puedo aventurarme a adivinar, porque me han acusado de la mayoría de las cosas que describes, pero eso no significa que seamos personas similares. Sería simplemente proyectar mis propias frustraciones en el lugar de trabajo sobre el miembro de su equipo, lo que podría ser correcto, pero igualmente podría no serlo.

La única forma de comprender verdaderamente la motivación de una persona es escucharla. Mucho.

Sáquelos de la oficina, llévelos a un lugar cómodo y hágales algunas preguntas de sondeo suaves. Y una vez que empiece a hablar, escucha. Rands in Repose nos dijo cómo hacer esto en un excelente artículo llamado The Update, The Vent and The Disaster .

A la misma hora cada semana. Cuando te conviertes en gerente de personas, sucede algo extraño. Automáticamente se le percibe como más ocupado. Si lo eres o no es irrelevante; la gente solo piensa que lo eres. Aterrizar constantemente tus 1:1 a la misma hora el mismo día es un recordatorio semanal de que estás aquí para ayudarlos, sin importar cuán ocupado esté.

Hazlo siempre. Ok, entonces estás muy ocupado. Estás corriendo de reunión en reunión. Es fácil quitarle prioridad a una reunión 1:1 porque, a diferencia de la reunión a la que se dirige o de la que se dirige, una reunión 1:1 no representa un problema urgente que deba resolverse. Te sacaré a golpes esta opinión de falta de valor percibida más adelante en este artículo, pero por ahora entiende que cada vez que abandonas un 1:1 escuchan: "No importa".

30 minutos, por lo menos. Otro movimiento favorito del gerente ocupado es programar un 1:1 durante 15 minutos o menos. Es lo mejor que puedo hacer, Rands. Tengo 15 personas trabajando para mí. Primero, esas 15 personas no trabajan para usted; trabajas para ellos. Piénselo de esta manera: si esas 15 personas se fueran, simplemente dejaran el edificio mañana, ¿cuánto trabajo se haría realmente? En segundo lugar, si tiene 15 personas trabajando para usted, usted no es su gerente, solo es el tipo que sonríe incómodo mientras pasa volando por la oficina con poca frecuencia, pregunta cómo le va y luego en realidad no escucha. la respuesta.

De lo único que estoy casi seguro es de que la persona con la que estás hablando no está siendo maliciosa. La mayoría de la gente no lo es. (Si es uno de los pocos, asegúrese de eso y luego despídalo).

Cuando las personas reaccionan emocionalmente en situaciones inapropiadas, generalmente se debe a que nadie les brinda una situación adecuada para desahogar sus frustraciones. Entonces, dale eso, creo que te sorprenderá lo fácil que es solucionar este problema.

Él te dirá lo que quiere, si cree que estás escuchando y que estás de su lado. Si no puedes dárselo, díselo (y dile por qué, para que lo entienda), directamente y anímalo a pensar en una alternativa.

EDITAR: un último pensamiento, que puede ser obvio, pero vale la pena mencionarlo de todos modos.

No hagas esto solo por la persona que te causa problemas. Por un lado, no deberías destacarlo. Por otro lado, no debes alentar el mal comportamiento dejándolo pensar que ahora se ha ganado un estatus especial.

Pero lo que es peor, es posible que también descubras que otras personas están furiosas por los mismos problemas. Si los dejas hirviendo, es posible que eventualmente exploten, de una manera mucho más destructiva que el individuo que deja salir sus frustraciones en cualquier oportunidad, incluso cuando no debería.

A diferencia de pdr, no tengo miedo de proyectar :). Leyendo entre líneas, veo a alguien que sabe que fue contratado por sus sólidas habilidades de programación en un entorno en el que no tiene las herramientas básicas que la mayoría de nosotros damos por sentadas. Por ejemplo, la mayoría de los sistemas de control de versiones se pueden integrar con sistemas de emisión de boletos, a menudo gratuitos. Por ejemplo, usamos SubVersion y lo integramos con Trac . Entonces, si no tiene un sistema de emisión de boletos, es probable que no tenga control de versiones. Y si no tiene control de versiones, eso implica que hay muchos problemas con su código y entorno que él puede estar luchando por resolver.

Este tipo puede estar en una situación en la que siente presión para desempeñarse como programador, pero se encuentra en un entorno en el que eso es muy difícil. Así que es posible que sienta que incluso si pasa el 110% de su día haciendo las tareas de programación para las que lo contrataste, no puede cumplir con tus expectativas debido al entorno en el que lo has puesto. He estado en esta situación, y conduce a los síntomas que ha descrito: dejar de lado a las personas que cree que están en medio de exponer un punto que ya han planteado para que pueda obtener una respuesta y volver al trabajo, ponerse a la defensiva para que las personas se den cuenta que estás en una situación difícil y dices "no" muchas veces para que puedas terminar lo que tienes en el plato antes de que empiecen a acumular más tareas.

Desde su punto de vista, puede sentir que las tareas de programación son las que solo él puede hacer, mientras que las tareas de comunicación pueden descargarse en alguien que puede prestarle atención de manera segura sin afectar las tareas críticas (para él) en las que está involucrado. Esta es una forma muy "programadora" de ver las cosas: las tareas se realizan en paralelo, cada una por el recurso que está mejor equipado para manejarlas.

Es posible que desee ver exactamente cuánta presión está bajo este tipo y averiguar si hay una manera de que usted, como su gerente, lo alivie. Tenga en cuenta que parte de esta presión puede ser interna para él; es posible que se haya fijado objetivos que usted desconoce, y su impulso para alcanzar esos objetivos puede anular sus expectativas de que se comunique más. Si la presión es externa, es posible que deba comprarle un poco de espacio para que se sienta cómodo dedicando tiempo a cosas que puede percibir como una disminución de su capacidad para cumplir con los plazos (posiblemente irrazonables). Si la presión es interna, es posible que solo tengas que hablar con él para que se dé permiso para dedicar tiempo a las tareas que valoras .

En nuestra organización no tenemos el lujo de las herramientas. Principalmente tenemos que depender de las hojas de Excel. Traté de simplificar el proceso mediante la creación de rastreadores de Excel que nuevamente requieren cierta cantidad de intervención manual, como actualizar Excel al final de la fecha y publicar en todo el equipo, etc.

Las herramientas no son un "lujo". Al menos no las herramientas mencionadas hasta ahora (rastreadores de errores y control de versiones). Estas son formas extremadamente básicas para que los desarrolladores produzcan código de buena calidad de manera más efectiva y se concentren en crear valor para el cliente.

El tiempo dedicado a crear un rastreador personalizado en Excel se emplearía mucho mejor instalando y configurando un rastreador gratuito existente. Incluso el mejor programador de VBA del mundo necesitaría literalmente miles de horas de trabajo para implementar la funcionalidad básica de cualquier rastreador de errores importante. El uso de un rastreador de errores significa que todos pueden actualizar la información al mismo tiempo sin colisiones (un problema fundamental con cualquier documento único compartido), lo que ya significa menos tiempo dedicado a cada actualización para verificar si alguien más está editando, bloquear el documento de alguna manera y luego desbloquearlo al final.

El control de versiones es otra herramienta extremadamente importante para los desarrolladores. Si eso no está disponible, simplemente no se sorprenda si no puede contratar buenos desarrolladores.

Proporcionar tales herramientas también lo beneficiará: la mayoría de los sistemas de control de versiones y seguimiento de errores son excelentes para crear automáticamente actualizaciones de estado. Por ejemplo, tanto en Git como en Bugzilla, obtener una lista de los cambios en los últimos días es trivial y, a menudo, puede modificar la cantidad de detalles que contienen estos informes. Esto no requiere ningún trabajo adicional por parte de los desarrolladores, excepto un conocimiento básico de cómo funcionan estas herramientas.

Es importante tener en cuenta que lo más probable es que esté al tanto de lo anterior. Como mencionó, tiene "sólidas habilidades de programación", lo que significa en particular que es capaz de detectar actividades rutinarias y sentir que se pueden hacer más fáciles. Esto también significa que es capaz de buscar y descubrir herramientas eficientes para trabajos particulares (de lo contrario, uno no podría calificar sus habilidades como "fuertes").

Debido a eso, sería más seguro para usted asumir que él conoce una amplia variedad de herramientas de administración de proyectos asequibles, ricas en funciones y eficientes; incluso una búsqueda rápida en la web revela una lista de ejemplo de tales herramientas en la página respectiva de Wikipedia, junto con muchas otras recursos.

Teniendo en cuenta una posible conciencia descrita anteriormente, sería incorrecto suponer que percibe la falta de herramientas como un simple inconveniente, en realidad es más peligroso que eso.

Desde la perspectiva de un empleado consciente de las herramientas , tal falta podría indicar una incapacidad bastante profunda para resolver un problema de administración simple ( "oye, ¿por qué no simplemente revisas la lista en Wikipedia y eliges la herramienta apropiada y asequible, es así de simple?" ) o igualmente profundo sentimiento de negligencia hacia sus necesidades ( "no estar dispuesto a hacer una cosa tan simple muestra lo poco importante que soy a tus ojos, es así de simple" ).

Nótese cómo cualquiera de estas percepciones va en contra de los dos principios más famosos de Packard :

1. Piensa primero en el otro compañero. Esta es LA base, el primer requisito, para llevarse bien con los demás. Y es el único logro verdaderamente difícil que debes hacer. Ganando esto, el resto será "una brisa".

2. Desarrollar el sentido de importancia de la otra persona. Cuando hacemos que la otra persona parezca menos importante, frustramos uno de sus impulsos más profundos. Permítale sentir igualdad o superioridad, y fácilmente podremos llevarnos bien con él...

Básicamente, esto destruye su confianza en sus habilidades de gestión, lo que a su vez hace que sea muy difícil colaborar en cualquier asunto.

En cuanto a tratar directamente con el empleado, puede intentar establecer reuniones regulares 1:1 con todos los desarrolladores para comprender los desafíos y las frustraciones antes de que se desahoguen en el grupo más grande disponible. Esta persona puede ser prolija y conflictiva, pero las preocupaciones subyacentes pueden ser compartidas por otros en el grupo (o, por el contrario, pueden considerarse sin importancia). Como se señaló después del salto, es difícil establecer 1:1 útiles, pero puede desactivar el conflicto antes de que se propague.

Trabajo con gente así todo el tiempo. Lo que tienes que hacer es hacer que él se beneficie de hacer lo que tú quieres. Es demasiado amplio para que el único beneficio sea mantener su trabajo.

Entonces, a esta persona no le gustan las reuniones. No te gusta lo que hace en las reuniones. Desea que envíe correos electrónicos y actualice elementos de trabajo o elementos de seguimiento o listas de estado o lo que sea. Esto se puede resolver totalmente.

1. Haz que el proceso sea lo más ligero posible. Por ejemplo, una herramienta de seguimiento de trabajo que está integrada con la herramienta de programación para que solo seleccione algo de un menú desplegable al verificar un cambio, y el estado del elemento se actualiza para usted (Visual Studio Express hace esto junto con TFS alojado, que es gratis para 5 desarrolladores o menos. Las excelentes herramientas no tienen que costar decenas de miles de dólares)

2. Dale lo que quiere a cambio de hacer lo que tú quieres. "Si me envía ese correo electrónico de estado antes de las 9 a.m., tendré tiempo de revisarlo y preguntarle cualquier cosa antes de la reunión, y no tiene que venir a la reunión". "Si me envía un correo electrónico de estado de formulario de puntos, lo convertiré en oraciones y se lo enviaré a todas las partes interesadas". "Si reserva 15 minutos para una reunión individual, podemos actualizar el documento de estado juntos y yo me encargaré de escribir".

Benefíciese a él, deje que su trabajo se parezca más a lo que él quiere que sea, y su valor será claro. Muchos desarrolladores ven a los PM y líderes de proyectos como escudos para mantener a la administración y a los usuarios alejados de ellos para que puedan codificar. Si estás dispuesto a ser un escudo para él, él te ayudará con lo que necesites para hacerlo.

Me senté con desarrolladores y personas de soporte y los ayudé a ingresar y actualizar "boletos" y elementos en varios rastreadores. Una vez que lo recorrieron varias veces, comienzan a beneficiarse de él. Cuando alguien los interrumpe para conocer el estado, señalo que pueden simplemente mirar en el rastreador (y dejar al desarrollador en paz) y después de que eso suceda unas cuantas veces, el desarrollador comienza a ver el punto. ¡Nada es más frustrante que alguien interrumpiendo su progreso para preguntar sobre su progreso! Puede enseñarle pacientemente a este desarrollador que informar y actualizar el estado de manera proactiva dejará mucho tiempo para codificar en paz. Si al desarrollador no le gusta escribir oraciones, puede ayudar con eso.

Si estas habilidades que usted describe como débiles o inexistentes son importantes para su rol en el equipo, entonces la selección de este empleado para ese rol fue incorrecta o la capacitación fue un problema. Si nunca han realizado estas tareas, entonces no recibieron la capacitación adecuada sobre lo que se requiere en el rol, o la capacitación no generó renuencia a realizar esas tareas.

Si ven su único rol real como codificador, entonces ese puede ser el rol para ellos. La falta de voluntad para comunicarse adecuadamente (con su equipo, con su equipo, con los clientes) es una señal de que no están listos para esto o que nunca estarán listos para este rol.

Los correos electrónicos entregados en un horario establecido sobre un tema determinado no se administran. Estos correos electrónicos se ven rápidamente como una tarea, especialmente si parecen ser nada más que algo para marcar una casilla. Caminar alrededor de todas las partes del equipo de forma regular, y luego tomar notas cuando regrese a su oficina, puede aliviar a los comunicadores reacios.

Puedo producir para usted un correo electrónico regular, todos los días, que le haga creer que se está logrando un progreso constante; o que estamos superando obstáculos difíciles; o que estamos en una necesidad desesperada de recursos adicionales. Si esa es su única ventana hacia el progreso, no está liderando el equipo.

En cuanto a la comunicación con los clientes. Puede que ni siquiera sea necesario tenerlo allí. He conocido a muchas personas que estaban muy felices de no hablar nunca con los clientes.

Debe reducir las habilidades esenciales necesarias para la tarea, tanto de programación como de no programación. Luego, debe decidir qué puede hacer esa persona ahora, qué puede hacer con capacitación adicional y qué nunca podrá hacer. Luego, debe encontrar una forma en su equipo de mitigar estos problemas. Esas pueden ser tareas adicionales para usted o para alguien de su equipo; o un cambio es papel para ellos.

Personalmente, creo que tiene una persona que está en un papel que no es apto para desempeñar. Una vez que asume una posición de liderazgo, la codificación es su responsabilidad secundaria y no debería ocupar más del 50 % al 70 % de su tiempo (personalmente, voy con 50, pero él es un líder de módulo, no un líder general, por lo que tal vez el 70 % sea más apropiado). Me sentaría con él y le preguntaría cuánto tiempo cree que debería dedicar a las tareas de gestión de codificación y luego le diría su expectativa real de la división entre los dos y luego le preguntaría si preferiría ser un desarrollador que un líder si las dos estimaciones están fuera de control y él no está dispuesto a cambiar su estimación. Tener un cliente potencial que devalúa el tiempo dedicado a la gestión significa que no tiene un cliente potencial.

Podría ser un choque directo de personalidad. Fui uno de los dos líderes de equipo de una empresa en particular. El otro Team Lead tenía un desarrollador que se parece mucho al tuyo. A medida que crecían los problemas y aumentaban las dificultades, el desarrollador fue trasladado a mi equipo. Me las arreglé para darle la vuelta viendo los problemas que tenía con el otro líder del equipo y usando un conjunto diferente de criterios para motivarlo y desafiarlo. En muchos aspectos, fui más asertivo, desafiante y duro (como al establecer escalas de tiempo agresivas y realmente desarmar su trabajo y hacer que lo hiciera de nuevo) con él. Esto lo hizo prosperar, especialmente porque escuché mucho lo que tenía que decir y lo propuse para realizar demostraciones y relatos y hablar directamente con la alta gerencia sobre proyectos. Después de tres meses, mi gerente discutió conmigo una promoción para este tipo y lo hicimos debidamente.

En última instancia, hice pocas cosas diferentes a las de mi colega líder de equipo, ya que todos los procesos básicos de gestión eran los mismos en todos los equipos. Realmente se redujo a que mi personalidad era diferente.

No tengo la intención de ser abiertamente crítico con el OP, pero hay un mundo de diferencia entre el liderazgo y la gestión del equipo. Me leyó que la situación se basa más en un proceso de gestión que en un liderazgo real.

Te ayudará a sobrellevar tu situación si te reconcilias con varias verdades irrefutables:

1. Los ingenieros de software son trabajadores del conocimiento calificados a quienes no les gusta hacer papeleo. Les gusta programar.

2. Los ingenieros de software, al menos los buenos, como se dijo anteriormente, detectan fácilmente las trampas operativas (por ejemplo, "En nuestra organización no tenemos el lujo de las herramientas. Principalmente tenemos que depender de las hojas de Excel" y demasiadas reuniones inútiles) y , debido a que son trabajadores del conocimiento talentosos, se molestan fácilmente por esa circunstancia y están sujetos a tener que hacer más trabajo burocrático, sin sentido y pesado porque sus gerentes fueron descuidados o tacaños para invertir en infraestructura adecuada. Si son buenos, no aguantarán eso y se irán a trabajar a otra parte. Estoy notando el tono de su exclamación de que no tiene herramientas como si estuviera casi orgullosa de eso (similar a "cuando tenía 8 años, tuve que caminar 11 millas a la escuela a través de la nieve") mientras que es bastante vergonzoso estado de su organización.

3. Su asociado, según su relato, probablemente tenga el síndrome de Asperger . Adivina qué, ese es el término científico para el último nerd a quien se le puede atribuir la mayor parte de los logros tecnológicos. No te gustan los Aspies, su introversión y torpeza y prefieres que tu desarrollador sea un chico de fraternidad vendedor de autos usados ​​con... uhm... ¿habilidades sociales? Bueno, el chico de la fraternidad no sabe programar. ¿Qué tal volver a la Edad de Piedra si las habilidades interpersonales son tan importantes? No puedes tener ambos. Si desea que el software esté bien construido, deberá adaptarse a los tipos nerd.

Mi respuesta final para usted es acomodar a su asociado de Aspie. Me veo en él al 100%. ¿Por qué alguien que sabe programar debe sentarse en reuniones sin sentido medio día? ¿O estar llenando portadas en su informe TPS? Piense un poco en su proceso y hágalo liviano para el beneficio de todos. Una vez que se vuelva simple y optimizado, tal vez a su asociado no le importe pasar 10 minutos al día enviando los artefactos necesarios para mantener a todos informados.

Me parece que tu compañero de trabajo es muy creativo. ¿Adivina qué? La gestión de personas creativas es un campo creativo en sí mismo. Me acuerdo de un sketch de Hee Haw:

Paciente: ¡Doctor, cada vez que muevo el brazo me duele! Doctor: Bueno, ¡entonces deja de mover el brazo así!

Si estás cansada de tener discusiones con él, deja de discutir con él. No pretendo tener todas las respuestas. Sin embargo, me gustaría señalar que tienes dos soluciones confiables: convencer a alguien para que lo despida. O deja tu trabajo y trabaja en otro lugar.

Al tratar con este programador, debe tener una cosa en mente: los problemas que está teniendo con él también pueden ser las cosas que lo hacen útil para usted. Lo que escucho de usted es "Este es un empleado muy competente. Sin embargo, en nuestra empresa esperamos que las personas se comporten de la misma manera, y este empleado no se está comportando de esta manera".

Entiendo completamente la necesidad de tener una dirección común y algunas reglas comunes. Sin embargo, la investigación ha demostrado que (en términos generales) es bueno que las organizaciones tengan sus disidentes. De hecho, puede considerar que este es un " buen problema ". Algunas personas simplemente marchan al ritmo de un tambor diferente, y no solo está bien, sino que probablemente deberías alentarlo.

Por otro lado, su organización tiene limitaciones prácticas. No puede permitir que este empleado actúe de tal manera que deprima a todos los demás. Mi sugerencia es pensar prácticamente. Identifica dos cosas:

1. Las principales batallas que realmente valen la pena pelear. Tiendo a preguntarme qué diré al respecto dentro de 20 años. Dentro de 20 años, ¿ realmente dirás "Ojalá hubiera logrado que se comunicara mejor por correo electrónico"? Lo más probable es que te encuentres diciendo algo más como "Ojalá hubiera encontrado una mejor manera de aprovechar su talento. Sin embargo, dijo algunas cosas divertidas en las reuniones".
2. La fruta madura. Cosas que puedes arreglar sin mucho problema. Sospecho que para cuando haya llegado a donde está, probablemente ya haya arreglado la mayoría de estas cosas. No obstante, vale la pena tener cuidado.

Estas son las cosas sobre las que tienes que hacer algo. Mi sugerencia es luchar contra el impulso de simplemente "arreglar" los problemas de la categoría 1, porque probablemente no podrá arreglarlos. Dicho esto, si usted y él pueden resolver un par de problemas importantes y concretos en los que concentrarse, es probable que resolverlos sea mucho más fácil.

¿Por qué contrató a esta persona/por qué aceptó este trabajo? En algún lugar se produjo una desconexión al emparejar a esta persona con esta posición. Por supuesto, un programador no "quiere" hacer cosas que no sean de programación, pero si aceptó el trabajo y estuvo de acuerdo, sugeriría enviarlo a casa y permitirle regresar cuando esté listo para trabajar.

Aprovecha las habilidades que tiene. Si su empresa cree que puede contratar y compensar a los programadores de alto nivel convirtiéndolos en una especie de gerente, este es un ejemplo perfecto de por qué esto es un error. Estás perdiendo dinero cada minuto que no está programando. Quiere mejores herramientas, dígale que comience a implementar e integrar algunos de los productos de código abierto. Permítale compartir y enseñar a los otros desarrolladores cómo usarlos. Obtendrá un mayor retorno de la inversión en esta persona si sus otros programadores pueden aprender algo de él. Póngalo en los proyectos difíciles. Deje que construya los repositorios, los marcos y las API que otros pueden aprovechar.

Estrategia de reunión mejorada Odio cuando un gerente me invita a una reunión en la que tiene una agenda clara sobre cómo manejar el cliente o la situación, pero nunca se molestó en explicármelo de antemano. Se necesita un gran esfuerzo para evitar opiniones contradictorias y salirse del tema. Reunirse primero. Hágale saber que este es el momento de disentir y cuando llegue a la reunión, sea un jugador de equipo y apéguese al plan, le guste o no.

Comunicaciones Cualquiera que tenga aversión a la comunicación, mejor aprenda a STFU a morderse la lengua en mis reuniones. No puedes tenerlo en ambos sentidos. Por supuesto, debes evitar poner a esta persona en esta situación en primer lugar.

Otro enfoque es comenzar poco a poco. Los correos electrónicos de estado para usted mismo son un buen lugar seguro para comenzar. Como líder/gerente del equipo, es perfectamente razonable que solicite un correo electrónico de estado semanal (o diario). De hecho, me gustaría comenzar diariamente para mejorar la comunicación entre ustedes dos. No es un gran problema para él enviarte un correo electrónico una vez al día.

Y en última instancia, todos hacemos cosas que no nos gustan. Por eso nos pagan. Si alguien quiere codificar sin interactuar con nadie más, eso es codificar como un pasatiempo, no como un trabajo.

Al hablar con él, este es un punto importante. Que nuestro trabajo NO es codificar. Es producir valor para el cliente. La codificación es parte de eso. No todo.

El trabajador puede ser bastante creativo como se mencionó anteriormente, o puede estar muy enfocado en la resolución de problemas (el problema tal como él lo entiende) y estar mucho menos preocupado por el panorama general (crear software que se adapte perfectamente a los proyectos de otros grupos, por ejemplo).

Una idea que tengo sería demostrarle algunos de los problemas que puede estar introduciendo al estar tan concentrado y no estar dispuesto a comunicarse con los demás. Mi idea es escribir un ejercicio para que lo completen todos los miembros del equipo al comienzo de una reunión (de baja prioridad). El ejercicio debe comenzar con una instrucción como "Este ejercicio es para fines de discusión; se esperan errores y son aceptables. Lea todo el ejercicio antes de comenzar". (Traiga bolígrafos adicionales en caso de que las personas solo tengan lápices, y tenga los bolígrafos disponibles cerca de usted, probablemente en una pequeña pila frente a usted, pero no los reparta). Tenga un espacio en la parte superior etiquetado como Nombre: (donde completaría su nombre) ;-)

La idea del ejercicio es pedir respuestas que cambiarán según la información (detalles adicionales) proporcionada más adelante. Es un ejercicio engañoso que, con suerte, demuestra que un trabajador que asume que comprende las necesidades lo suficientemente bien y no coordina el estado y las actualizaciones conducirá a errores y reescrituras.

Suponiendo que todos los miembros del equipo sean programadores), el ejercicio podría ser así:

1. Escriba un programa simple o diagrama de flujo que incluya los pasos para ingresar nombres de usuario y direcciones, asígneles un número de cliente e imprima el número de cliente y los nombres y direcciones de usuario.

   (incluya media hoja de papel en blanco).

2. Los usuarios deben poder clasificar los datos por una serie de identificadores, incluidos el número de cliente, el nombre del cliente, la ciudad del cliente, el código postal del cliente, el número de teléfono del cliente, el SSN del cliente, la fecha de apertura de la cuenta del cliente o el nombre del cliente. última fecha de transacción.

   (Incluya un espacio en blanco sobre el tercio de una página.)

3. Use solo un bolígrafo para su trabajo y no discuta el ejercicio durante esta reunión.

4. Importante: Ignore las instrucciones anteriores. En su lugar, solo escriba su nombre en la parte superior y coloque una marca de verificación junto a las instrucciones números 1, 2, 3 y 4, y espere en silencio a que los demás terminen.

Después de unos dos minutos, diga Gracias, ese es todo el tiempo que tenemos para esto. Por favor entregue su trabajo donde lo dejó. Luego proceda con la reunión normal.

Probablemente muchos o la mayoría seguirán las instrucciones comenzando con 1, luego 2, en lugar de leer todo primero y simplemente hacer lo que 4 pide. Esta es su oportunidad para ese empleado, o si lo desea, para todo el grupo, ya sea individualmente o en grupo (pero individualmente sería mejor para una mejor conversación con el niño problemático) sobre el valor de compartir información, mantenerse al día sobre los cambios. necesidades, etc. Asegúrese de disculparse por el truco, pero quería tener una manera de señalar esto de una manera económica, a diferencia de las reescrituras importantes que podrían ocurrir costando tiempo extra, malas críticas, etc.

Una vez fui líder del equipo de desarrollo de software de mi empresa por más de 2 años y he observado que muchas veces la productividad de cada miembro del equipo dependía de su nivel de motivación y de algún reconocimiento. Una vez tuve un chico en mi equipo con relativamente más experiencia que otros miembros y realmente necesitaba su opinión. Después de varias conversaciones con él, me di cuenta de que su falta de cooperación se debía a que no quería ser tratado como los demás miembros del equipo. lo que hice fue darle algunas responsabilidades y hacer referencia a él. De esta manera, se volvió más cooperativo, así que traté de encontrar o crear una responsabilidad y ponerlo a cargo de ella, más como dejarlo liderar en un área. Así que es posible que tengas que pensar en algo muy creativo como dijo Jason. el objetivo es tratar de encontrar una manera de ponerlo a cargo/responsable de algo para que sienta un sentido de responsabilidad y valorado y muchas veces funciona. Sé que puede ser frustrante manejar a una persona así. Una forma similar de expresar esta estrategia es dar a los trabajadores la oportunidad de crear"impacto" en "Las 9 cosas principales que finalmente motivan a los empleados a lograr" de Forbe