¿Cómo lidiar con un subordinado de bajo rendimiento?

Así que aquí está la parte que me parece incompleta: le ha pedido a su empleado, John, que haga horas extra no remuneradas los fines de semana.

• La razón por la que es "trabajo" es porque aprender Angular no es algo que a John le gustaría hacer en su tiempo libre, por lo que aún no lo ha hecho (y sigue sin hacerlo), y no le proporciona ningún valor a John personalmente, excepto en la medida en que aporta valor a la empresa. La realización de una tarea que no es en beneficio propio y en cambio es en beneficio exclusivo del empleador, se denomina "trabajo".

• En cuanto a las "horas extra", eso debería quedar claro; John normalmente no trabaja los fines de semana, por lo que le ha pedido que trabaje fuera del horario habitual. Eso se llama "tiempo extra".

• En cuanto a "no remunerado", presumiblemente no le ha ofrecido a John ningún tipo de compensación por hacer este trabajo el fin de semana y, presumiblemente, no tiene la autoridad para hacerlo. Como resultado, John no será compensado por realizar estos esfuerzos durante el fin de semana. Eso se llama "no pagado".

Ahora que tenemos esto claro, como líder de equipo, y particularmente como nuevo líder de equipo, no debería tener su primera impresión con su nuevo equipo de "pasar el fin de semana haciendo horas extras no remuneradas". Eso no va a funcionar para usted en el largo plazo. No hagas eso.

Desde la perspectiva de John, también pude ver una pregunta (¡y he visto muchas en Workplace SE en el pasado!) que dice algo así:

Hace poco me gradué de la universidad, solicité y conseguí un trabajo en una empresa que buscaba un desarrollador Java backend. Al unirme a la empresa, me colocaron de inmediato en un equipo de desarrollo frontend usando Angular. No tengo experiencia con Angular, y tanto el entrevistador como el gerente de contratación lo sabían durante todo el proceso de la entrevista. Además, debido a estas circunstancias, mi jefe me ha requerido que haga horas extras no remuneradas los fines de semana para compensar mi falta de conocimiento. ¿Qué tengo que hacer?

A lo cual, y debido a que he visto este tipo de preguntas en el pasado, la respuesta de la gran mayoría sería "Las horas extra no pagadas no son buenas, su empresa no lo respeta, lo sorprendieron con un equipo que no coincide con su conjunto de habilidades, encontrar otro trabajo". Y eso es lo que Juan va a hacer.

Si desea ayudar a John en lugar de frustrarlo y hacer que se vaya, esto es lo que puede hacer:

1. No le pida a John (¡ni a nadie más!) que trabaje horas extras no remuneradas. Eso no es cool.

2. Si John necesita aprender Angular, permítale hacerlo durante las horas de trabajo. Prepare algunas tareas de aceleración para él (pequeñas tareas para que se acostumbre al marco y al desarrollo frontend) para que pueda mojarse los pies lentamente y aumentar su nivel de comodidad.

3. Proporcione a John la tutoría que necesita.

De lo contrario, pídale a su cadena de mando que transfiera a John a un equipo que realmente use el conjunto de habilidades para las que fue entrevistado y contratado, y no lo tome por sorpresa tratando de convertir a un desarrollador backend capaz en un desarrollador frontend horrible.

Si yo fuera un CTO y un gerente viniera a mí y me dijera:

No estamos rindiendo porque uno de los miembros de mi equipo es malo en su trabajo.

Mi respuesta sería,

¿Porqué me estas diciendo esto? Eres el líder del equipo, haz algo al respecto. ¿Cuál es tu plan?

En otras palabras, ir a su CTO y explicarle la demora señalando los problemas de rendimiento en su equipo no es la solución , no cambiará nada repentinamente ni resolverá el problema. Debe idear un plan de acción, no solo decirle a otra persona que la persona tiene un desempeño deficiente. Sí, es posible que desee comunicar el hecho de que ella tiene un desempeño deficiente, pero la comunicación es solo parte del proceso, no es lo que hará que todo esto desaparezca.

Parece que ya has hecho un trabajo a medias al decirle que necesita aprender sobre estos temas. Es posible que desee reflexionar sobre algunas otras opciones:

• Esperar que un empleado aprenda en su propio tiempo no siempre es fructífero, como ha visto. ¿Tiene la oportunidad de incorporar la capacitación en su tiempo de trabajo? ¿Al tener a alguien que la guíe o la entrene? ¿O permitirle "tiempo de desarrollo" en el que pueda concentrarse en aprender?
• Esperar que un empleado pueda hacer un buen trabajo en una tecnología con la que no está familiarizado tampoco siempre es fructífero. Algunos desarrolladores pueden aprender fácilmente nuevos lenguajes o plataformas, otros luchan y es mejor que los traten como "expertos" en un entorno específico. Si ese es el caso de esta mujer, debe decidir si su empresa necesita un experto en Java o si necesita a alguien que sea flexible. No es inherentemente un problema de que sea una mala desarrolladora, puede ser que no sea del tipo que necesitas.
• Asegúrese de entender el enfoque de su empleador para la gestión del desempeño. Si el empleado no puede realizar el trabajo como se describe en la descripción del trabajo, es posible que deba comenzar a tomar medidas más formales. La clave cuando esto sucede es seguir la política (es decir, ¿su departamento de recursos humanos tiene un proceso formal de mejora del desempeño?) adaptar.

Una cosa que es difícil de comprender para algunos líderes recién ascendidos es que su trabajo no es ser un experto en las tareas que realiza su equipo. En muchos entornos, su trabajo se trata tanto de administrar a las personas como de administrar el trabajo. Este es un problema de personas. Sí, puede ser que sus habilidades deficientes estén causando que el trabajo se retrase, pero desde la perspectiva del empleador, ese es tanto su problema como el de ella.

Pero ni siquiera conoce los conceptos básicos de HTML y CSS. Le dije que estudiara estos temas en casa de Codeacademy los fines de semana/vacaciones.

Enorme bandera roja.

Usted (o su empresa, pero como usted es el líder, es su responsabilidad) lo puso en un trabajo que necesita habilidades que él no tiene. Tienes que entrenarlo durante las horas de trabajo si se necesita entrenamiento . Si mintió sobre sus habilidades, despídelo, pero si tenía claro que solo conocía Java, entonces estás equivocado.

La solución es bastante simple: permitirle estudiar estos temas en el trabajo y no hacer nada más relacionado con el trabajo durante un período de tiempo bien pensado (dos o tres días para un ingeniero de software, tal vez más para desarrolladores menos graduados).

No reiteraré la excelente respuesta de dwizum, pero tengo algunas cosas que agregar:

Su principal problema es que no hace el trabajo de una manera lógica, sino que siempre intenta algunas permutaciones y combinaciones aleatorias para hacer que sus golpes de suerte sean un intento exitoso de hacer el trabajo.

¿Ha intentado mostrarle estrategias más efectivas para resolver problemas? (Sí, idealmente un graduado sabría cómo "trabajar lógicamente", pero las estrategias de resolución de problemas generalmente no son parte del plan de estudios formal y, a veces, no se enseñan tan bien como deberían).

Incluso le dije que buscara en Google un concepto que no conoce, pero que ni siquiera es bueno para buscar en Google.

¿Has intentado mostrarle cómo buscar en Google de manera efectiva?

También tenga en cuenta que será un desafío para un desarrollador de Java buscar problemas angulares en Google, ya que el lenguaje de programación, las herramientas de compilación y el entorno de tiempo de ejecución son totalmente diferentes. Comprender una publicación de blog aleatoria de un desarrollador de JavaScript es un desafío si no conoce las tecnologías web.

Consulta tus expectativas

He pasado los últimos dos años entrenando a equipos experimentados de Java en sus primeros proyectos angulares. En mi experiencia, solo alrededor del 20% de los desarrolladores pudieron hacer este cambio sin ayuda. Y sí, a pesar de que todos asistieron a un curso profesional sobre angular y tuvieron acceso a ayuda experimentada, el progreso en el primer proyecto angular fue lo suficientemente lento como para poner nerviosa a la gerencia.

Resumen

Sí, los desarrolladores realmente buenos pueden aprender un nuevo idioma sin ninguna ayuda, pero la mayoría de los desarrolladores necesitarán más ayuda que "necesita aprender los conceptos básicos".

Tienes que hacer tu trabajo.

Del lado del equipo, decida si es factible asesorar o no al de bajo rendimiento. Si cree que están dispuestos a aprender y son capaces de ser productivos y que el desempeño a largo plazo de su equipo es más importante que los costos a corto plazo de una tutoría, entonces decida asesorarlos e informar al equipo. Asígneles tareas que sean realistas dado su nivel de habilidad y vuelva a evaluar periódicamente para ver si la tutoría está funcionando.

Por el lado del CTO, debe informar de manera realista a su CTO sobre las capacidades de su equipo. Si trata de decirte que la tarea es fácil o cualquiera puede aprender, responde de la siguiente manera:

1. Está gestionando el equipo de forma adecuada teniendo en cuenta los recursos disponibles. Si tiene consejos específicos sobre las formas en que podría administrar el equipo de manera adecuada, estaría feliz de escuchar.

2. El equipo está rindiendo como está. No es hacer el trabajo más rápido de lo que es. No hay látigo mágico que puedas romper. Sus empleados tienen la productividad que tienen y no puede hacerlos más productivos por arte de magia.

3. Explique su consejo sobre el miembro del equipo de bajo rendimiento. Explique que ha decidido que tiene más sentido comprometerse a asesorarlos aunque eso tenga un costo a corto plazo o abogar por que sean despedidos. Si cree que reemplazarlos ayudaría, explíquelo.

En última instancia, debe decirle al CTO que cree que está liderando al equipo de manera adecuada, pero que el desempeño del equipo no es suficiente para realizar las tareas solicitadas en el tiempo deseado. Ofrezca opciones útiles, como contratar a más personas, reducir el conjunto de funciones, etc. Explíquele que pedirle que produzca un mejor resultado no cambiará su evaluación de lo que su equipo es capaz de lograr de manera realista.

Hagas lo que hagas, no estés de acuerdo con sus afirmaciones de que el equipo puede producir más y luego repites el ciclo de entregar menos de lo que espera el CTO seguido de rituales haciendo promesas poco realistas de hacerlo mejor en el futuro.

Los otros comentaristas tienen razón: es su responsabilidad asegurarse de que este desarrollador pueda desarrollar en Angular (porque se les asignó esta tarea sabiendo que su experiencia es en Java).

Incluso tengo que resolver el 90-95% de sus tareas por mi cuenta y luego aprende

NO resuelva las tareas asignadas a esta persona por ella; está obstaculizando su proceso de aprendizaje. Si no pueden manejar la carga de trabajo y finalmente está completando tareas para ellos, ANTES de mencionarlo con su CTO, le sugiero que:

1. dales un tutorial básico sobre Angular (tal vez concéntrate en las cosas que usarás)
2. Reduzca la cantidad de tareas que se les asignan (cualquier carga de trabajo que tengan actualmente suena demasiado en este momento )
3. No resuelvas sus tareas por ellos, bríndales retroalimentación para que puedan regresar y corregir los errores/hacer el trabajo (ellos entenderán el flujo de su código mejor que tú)
4. introduzca codificación dual/sombreado/revisión de código entre sus desarrolladores para que aprendan unos de otros (menos interferencia de su parte)

Como alguien que está en una posición similar, estos pasos (especialmente 3 y 4) han sido útiles para que ese empleado sea más fuerte en un área en la que no se sentía cómodo al principio. En lugar de echarle la culpa al empleado con "bajo rendimiento", debe preguntar por qué se le asignó este proyecto dados sus antecedentes o si en algún momento sabía que su trabajo requería que aprendiera un entorno completamente nuevo.

Como líder de un equipo, se espera cierta cantidad de gestión del desempeño del resto del equipo.

Parece que hasta ahora has hecho una cantidad mínima de eso, principalmente diciéndoles que estudien en casa o que lo busquen en Google. Y hasta ahora eso no ha sido particularmente exitoso, probablemente porque son enfoques bastante inútiles para ayudar a un nuevo miembro del equipo de nivel de entrada a comenzar.

Estoy pensando que la única solución que me queda es contarle al CTO sobre esa chica y sus hábitos de hacer el trabajo con estimaciones para que pueda decidir si está lista para trabajar o no.

En última instancia, podría llegar a eso, pero si yo estuviera en el lugar de su CTO, buscaría que asumiera un papel más proactivo para tratar de resolver el problema antes de que me lo presentara.

Lleve a un lado al miembro del equipo con dificultades y tenga una conversación con él, vea si puede a) llegar a la raíz del problema y b) trabajar para mejorarlo.

No es necesario que te hagas grande, chillón y agresivo: un buen líder de equipo debe facilitar el trabajo y no gobernar con puño de hierro.

Parece que estás luchando con algunos de los elementos en los que estamos trabajando en este momento, ¿cómo puedo ayudarte? ¿ Puedes decirme por qué estás luchando? ¿Hay algo en particular en lo que sientas que necesitas ayuda?

Es de esperar que luego pueda trabajar con el miembro del equipo para mejorar las cosas, pero en última instancia, es posible que simplemente no funcione. Entonces puede considerar hablar con el CTO y decir algo como:

[Miembro del equipo] está realmente luchando por comprender algunos elementos clave del trabajo. He hablado con ellos y hemos hecho X, Y y Z para tratar de mejorar la situación, pero en realidad no ha ayudado y me preocupa que esté afectando la capacidad de entregar el trabajo de nuestro equipo.

Como ya han señalado otros, sus problemas se reducen al hecho de que no se le permite brindar la capacitación adecuada a sus empleados. Debería idear una manera de mostrar a sus superiores que la falta de capacitación ha costado más horas de las que les hubiera llevado capacitarlos . En otras palabras, que no capacitarlos adecuadamente perjudica a la empresa.

No hagas el trabajo de tus subordinados por ellos. Si algo no se hace, asigne la tarea a otra persona. De esta manera, debería ser evidente cuántas tareas realizan las personas en un período de tiempo determinado. Ahora puede aproximar las horas de trabajo perdidas debido a las diferencias de habilidades.

Además de la introducción técnica básica, podría sugerir el uso de la programación en parejas para ayudar con las diferencias de habilidades. Esto también funcionaría como medida de control de calidad, en caso de que necesite argumentos adicionales para vender esta idea a su CTO.

Notas al margen: Tuve que aprender nuevas tecnologías en mi lugar de trabajo anterior, incluidos dos lenguajes de programación completamente diferentes. Aunque los jefes eran unos imbéciles cuando se trataba de gastar dinero, dedicaron recursos para aprender estos lenguajes, incluidos libros electrónicos y dándonos tiempo para implementar grandes aplicaciones de tutoriales en el trabajo.

Estúpida analogía: no contratarías camioneros y les pedirías que aprendan a conducir trenes en su tiempo libre.

Aquí está su problema: su equipo no es capaz de hacer el trabajo que se supone que debe hacer en el tiempo que se le permite. Que uno de tus compañeros tenga un bajo rendimiento es secundario. Es un problema para ellos, puede llevarlos a perder su trabajo en el peor de los casos, pero su problema es que el trabajo no se está haciendo.

Hay dos soluciones a su problema: mejorar el trabajo de su equipo o dejar en claro a la gerencia que su equipo no es capaz de cumplir y que no es su culpa. Deberías trabajar en ambos.

Para el primero, hablas con ese compañero, le dices que el equipo está en peligro, y por lo tanto él está en peligro, y su trabajo necesita mejorar. Mejorar solo se puede hacer aprendiendo. Deles tiempo en el trabajo para aprender (es más eficiente para ellos aprender que hacer un trabajo de calidad inferior que necesita ser rehecho). Dígales que pidan ayuda de inmediato si no saben cómo continuar, porque 5 minutos de ayuda pueden dejar de perder dos horas de trabajo.

Para el segundo, dígale a su gerente que este colega no está a la altura. Dígales qué medidas está tomando para mejorar las cosas. Dígales que con empleados competentes haría sus tareas (si eso es realmente cierto), pero actualmente no tiene esto y le llevará tiempo llegar allí. Si alguien piensa que solo toma horas aprender CSS, por ejemplo, puede decirle que está en desacuerdo respetuosamente, y no importa si está de acuerdo o en desacuerdo, tiene un empleado que no lo está aprendiendo en horas .

Puede sugerir reemplazar a la persona en el equipo, lo que realmente no está manejando su problema.

No estoy de acuerdo con algunas de las respuestas enumeradas anteriormente, específicamente con la expectativa de que John aprenda Angular/CSS/HTML en el tiempo de la empresa.

En concreto, el campo de la Tecnología es un campo muy amplio, y es un campo que está en constante cambio. Angular surgió en 2010. He sido ingeniero web desde 2003. Cuando comencé, Angular no existía. ¿Por qué sigo siendo relevante en mi campo? Porque hice mi propia prioridad mantenerme al día con las noticias de la industria y mantener las habilidades actuales en áreas relevantes.

No creo que siempre deba ser 100% necesario aprender cualquier habilidad nueva para trabajar en el tiempo de la empresa, y no creo que la empresa esté obligada a darte ese tiempo para aprender. Si desea mantenerse al día, si desea mantenerse al día, si desea mantenerse relevante y, a veces, si desea mantener su trabajo, debe verificarse a sí mismo y su conjunto de habilidades y el trabajo que tiene y asegurarse de que son un partido.

Comencé jugando con el diseño de sitios web para mamás y papás de Podunk, y ahora estoy trabajando en un equipo de inteligencia artificial en el que contribuí en gran medida a la dirección y el desarrollo de su pila de tecnología, administrando un entorno de AWS que no existía. cuando empecé.

No conseguí ese trabajo diciéndole a mi empresa que necesitaban darme tiempo para aprender esas habilidades mientras estaba en el trabajo.

A los buenos desarrolladores y, lo que es más importante, a los buenos ingenieros les apasiona dominar su oficio y entienden que eso significa que más de las 40 horas a la semana que trabajan necesitan estar más inmersos en la tecnología que deben usar día a día.

Esa es la conversación que tendría con John, y si él no expresaba interés o no intentaba mejorar, no le ofrecía una transferencia, lo despediría. Los desarrolladores sin pasión por crecer por su cuenta nunca serán más de lo que eran cuando los contrató.

1) Su gente de recursos humanos / contratación está perdiendo la pelota si contratan personas que ni siquiera cumplen con los requisitos mínimos de habilidades para el trabajo. IE: si necesita saber HTML, Angular, etc., entonces la descripción de su trabajo debería haberlo dicho. Si lo contrataron sin esas habilidades, significa que la descripción de su trabajo era mala (que está en la persona técnica de su departamento que les decía qué habilidades se necesitaban) o en ellos (contratar a alguien sin ser estricto con las habilidades). necesario... algunas personas no tecnológicas de recursos humanos piensan "oh, este tipo es un programador que puede programar cualquier cosa"... y contratan a una persona que sabe SQL para hacer el trabajo de Java... .). De todos modos, hable con Recursos Humanos y pídales que actúen juntos.

2) Los recién graduados son impredecibles. La mayoría busca aprender en el trabajo en su primer trabajo y luego abandonar el barco después de un año de "experiencia" para conseguir un mejor trabajo (b/c cuando se gradúan de la universidad por primera vez, se trata de qué tan rápido pueden obtener más dinero... b/c los préstamos estudiantiles no se pagarán por sí mismos, y vivir al día en la universidad los ha motivado a ganar dinero).

Realmente tiene que evaluar el potencial a largo plazo del graduado para ver si vale la pena entrenarlo en el trabajo (y SERA entrenamiento en el trabajo, como han señalado otros... programadores realmente motivados harán cosas en su propio tiempo para aprender y estar al tanto de las tendencias... pero en última instancia estamos hablando de un trabajo aquí, y la gente quiere una compensación por las habilidades que aprenden y el trabajo que hacen).

Una vez más, la gente de recursos humanos debería haber evaluado la viabilidad a largo plazo de la persona con preguntas BS como "¿dónde te ves en 5 años?"

Pero, solo debe tener una conversación sincera con el candidato. Si parecen humildes y realmente motivados para querer hacer un buen trabajo y complacerlo... entonces necesita capacitarlos y ponerlos al día... b/c es muy probable que se queden a largo plazo y se conviertan en valioso activo.

Si actúan engreídos o distantes o no parece importarles que se están quedando atrás... van a abandonar el barco rápidamente. Eres solo un trampolín para que lo usen mientras se dirigen a otro lugar.

Entonces, simplemente siéntate con ellos para conversar media hora o una hora en tu oficina y pregúntales "¿a dónde crees que va este trabajo?" "dónde te ves en 5 años" etc, etc, etc... mira lo que están pensando. Ellos ya saben lo que estás pensando (estás pensando que necesitas a alguien que pueda producir en este momento).

Pero, los programadores son trabajadores del conocimiento de alto nivel. No es como el trabajo de excavación de zanjas, donde un buen excavador de zanjas es un 1,05 % mejor que el promedio. Un buen programador puede ser muchas veces más productivo que un programador promedio. Si este nuevo graduado tiene la materia prima para ser un buen programador (rápido para aprender, motivado para trabajar, buenas habilidades para resolver problemas... no importa qué lenguajes sepa si no tiene un impulso de causa raíz para hacer tipo de trabajo de programación).. entonces son un diamante en bruto esperando ser pulido.

La mayor preocupación es que está atrapado con un programador que vino de CS o IS porque entraron en los programas de grado por el dinero, no por la pasión. Estoy en un programa MIS en la universidad en este momento con un 90 % de estudiantes indios... alrededor de 2/3 de ellos NO quieren estar allí, pero están allí porque su familia los empujó a hacerlo. No les importa la programación, la gestión de datos, los sistemas de información, los análisis... es solo un trabajo para ellos y hacen lo mínimo para sobrevivir en clase (a veces engañando a otros) y solo quieren salir al mundo laboral. y seguir con la vida y ganar dinero. Solo va a ser un trabajo para ellos. Hablo con algunos, y no dudan en decir cómo preferirían estar en el arte, la literatura o las ciencias sociales, pero su familia los empujó a una carrera de alto nivel (generadores de dinero STEM... medicina, tecnología,

Por lo tanto, debe evaluar si su chico está haciendo un trabajo que le apasiona, o si es solo una forma de ganar dinero.

Probablemente haya interactuado con los otros miembros del equipo. Obtenga su evaluación... su evaluación social... ya saben que le faltan habilidades. PERO, si sienten que es un jugador de equipo, solucionador de problemas, etc., entonces tiene potencial.

EG: A veces está bien tener un "programador holgazán" en el grupo si es un gran solucionador de problemas que hace que los demás piensen diferente. Las otras personas compartirán ideas con ellos, y el "vago" puede darles buenas ideas con las que trabajar y producir un trabajo excelente. Pero, sin ese "vago", los otros programadores son solo máquinas de codificación sin buenas ideas para codificar. Cualquiera puede generar código. No significa que sea bueno. No significa que esté resolviendo un problema de una manera elegante o innovadora. La persona más holgazana puede tener ideas increíbles, solo que carece de las habilidades de codificación y la velocidad para implementarlas. Una persona "floja" también puede ser un estímulo moral para el resto del equipo si es agradable y trabaja bien con los demás. No todos los programadores pueden ser estrellas de rock lanzando código como cajas en una fábrica.

Entonces, le daría al tipo una evaluación social para ver si vale la pena perder el tiempo de la compañía para entrenar. Si no está motivado, no es un jugador de equipo y no le importa... evítelo y contrate a otro. No tiene sentido capacitar a alguien solo para verlo tomar todo lo que le diste a un trabajo diferente de 6 meses a 1 año después.

Lo que está tratando de hacer demuestra que no comprende la diferencia en el conjunto de habilidades de su personal y lo que se necesita.

Un desarrollador de Java, si no tiene experiencia en desarrollo web, no comprende el lado del cliente y el lado del servidor de las cosas.

El paradigma es diferente a un Java independiente. Incluso si ha trabajado en applets de Java, eso sigue siendo programación dentro de una VM autónoma, no una en la que un cliente habla con un servidor.

Por ejemplo, cualquier tipo de verificación de errores en el lado del cliente es superficial y simplemente se usa para reducir las visitas al servidor. NO se supone que se debe confiar en él, porque omitir la validación del lado del cliente es absolutamente trivial . Algo así como un "nombre de usuario", las comprobaciones básicas del lado del cliente no estarán en blanco y eso es todo, tal vez agregue alguna combinación de requisitos alfanuméricos, pero incluso podría no funcionar debido a la necesidad de admitir diferentes idiomas.

En el lado del servidor, verificaré que no esté en blanco, y también cualquier tipo de datos que no pueda manejar (fuera de UTF-8, por ejemplo), luego también verificaré los ataques de inyección SQL (las declaraciones preparadas resolverán eso, pero quiero detectarlo y posiblemente poner la IP en una lista negra), y probablemente registrar los intentos repetidos de tráfico de gran volumen para evitar el acceso malicioso (piratería, creación masiva de nombres de usuario, usurpación de nombres de usuario, etc.). Todas esas opciones son solo del lado del servidor.

Luego, también querrá pensar en cómo se comunica el cliente con el servidor y si será apropiado ingresar a AJAX para una mejor experiencia de usuario. Todo este conocimiento no es trivial y un CTO es bastante tonto si espera que un personal pueda aprender todo esto en un par de meses.

Creo que te estás perdiendo las partes clave de lo que significa ser un líder de equipo. Ser mentor de los miembros de su equipo para que mejoren es parte de su trabajo. Darles el apoyo para tener éxito es parte de su trabajo.

Por ejemplo, dele a su miembro junior del equipo un ejercicio de entrenamiento para que lo aprenda. Dale lo que creas que es la cantidad de tiempo adecuada, o mejor aún, pregúntale cuánto tiempo necesita. Si el CTO tiene un problema con eso, defiéndelo. El equipo cuenta contigo para protegerlos y guiarlos.

Además, el poder no está en mis manos para simplemente asignarles la tarea de capacitación o la tarea del proyecto real. Hago lo que mi CTO me dijo que hiciera y cada vez que he tomado la decisión de brindarles capacitación por mi cuenta, el CTO me dice siempre: "aprender HTML, CSS, JavaScript no es algo para lo que tengan que dedicar meses". Enséñales los conceptos básicos en 4 horas y dales un día para hacer una tarea simple y luego estarán listos para el proyecto. Descansen, aprenderán mientras hacen el proyecto. No tenemos mucho tiempo para dedicar a su capacitación. ."

No compro esto. Si eres su líder, tienes absolutamente el poder de ayudarlos a tener éxito. Si su CTO le dice que haga lo contrario, entonces ese es un problema entre usted y su CTO. Deje a su miembro del equipo fuera de esto. Tu trabajo es ayudarlo. Educa a tu CTO. Tienes que enfrentarte a él. Es por eso que te pagan mucho dinero ahora.

A veces los gerentes se equivocan. A veces los gerentes tienen expectativas poco realistas. Especialmente los CTO. Los CTO quieren todo, lo quieren ahora, lo quieren perfecto y quieren que no cueste nada. Confían en usted para que les explique cómo funciona realmente.

Debe mostrarle a su CTO la compensación entre darle a este empleado el tiempo necesario para aprender, que es:

1. Menos tiempo disponible para crear características ahora, pero más capacidad más adelante.
2. Ahora hay más tiempo disponible, pero no se hará a tiempo ni con la calidad correcta.

Todo se reduce a la previsibilidad y la velocidad. No solo a nivel individual, sino a nivel de equipo. Si cada miembro del equipo tiene que seguir ayudando a este individuo porque no sabe cómo hacer su trabajo, entonces el golpe de productividad es de todos.

Mostrar los hechos a su CTO de esta manera 1) lo persuadirá 2) demostrará su competencia, por lo que es probable que retrocedan y lo dejen hacer las cosas a su manera.

En mi opinión, el momento de involucrar a su CTO en una decisión de personal sobre el desempeño de este empleado es si ha agotado sus esfuerzos y cree que esta persona nunca tendrá éxito en su equipo. Debería ser un último recurso. No querrás que los otros miembros de tu equipo se preocupen constantemente de que los arrojarás debajo del autobús cuando algo salga mal. Necesitas proteger a tu equipo. Despedir o escalar a su jefe, que probablemente sea lo mismo, debería ser el último recurso absoluto.

Dar oportunidades a John, proponer incluso formación remunerada si es necesario, pero dejar que fracase llegado el momento.

Parece que hay aquí varias cosas muy malas:

• Está permitiendo que alguien permanezca en su equipo, que no está calificado para estar allí.
• Esa persona está robando el lugar de otra persona que podría ser un miembro productivo;
• Estás dañando tu propio trabajo tomándote el tiempo para hacer el trabajo de John
• Estás bajando la moral del equipo: si John no necesita actuar, ¿por qué deberían hacerlo ellos?
• Está construyendo un rastro de trabajo probado para que sea más difícil despedir a John en el presente y en el futuro.

No buscas tus propios intereses a corto plazo haciendo el trabajo de John, y mucho menos a los objetivos de tu equipo a largo plazo.

Si yo fuera un subordinado suyo, no esperaría que hiciera mi trabajo, pero esperaría que tratara con los jefes y se deshiciera de un miembro del equipo que no puede contribuir.

A corto plazo, ya que tienes a esa persona, puedes asignar a John parcialmente para ayudar con la documentación y otra parte del día/semana para estudiar durante las horas de trabajo.

También definiría plazos y objetivos. Una contratación de aprendiz/universidad tiene que hacer un esfuerzo honesto en los primeros meses y mostrar interés y algo de ingenio, para ser mínimamente competente después de seis meses y mínimamente productivo para el equipo alrededor de 9-12 meses. Por lo general, las personas también serán moderadamente competentes en un nuevo entorno/trabajo, dependiendo de la complejidad, después de 1 año a 1 año y medio, como máximo dos años. Tu CTO debería saberlo, o lo más probable es que lo sepa pero solo quiere que aproveches al máximo el equipo que tiene en sus manos. Los factores de costo podrían influir en eso.

PD. En el pasado vi a personas en el lugar de John, que después de 2 años de ser "ayudados" se quejaban de que ya era hora de que consiguieran un ascenso... uno de los casos tenía veintitantos años y se quejaba de no tener un aumentar en los tiempos que no estaba durmiendo en el trabajo, por ejemplo, cuando estaba despierto.

Volviendo al caso específico de John, trataría de asegurarme de entender si el esfuerzo es genuino, o si todavía cree que puede salirse con la suya fingiendo trabajo como si todavía estuviera en la universidad. Podría suceder que John no sea lo suficientemente maduro para comprender que ahora está en el mundo real, y eso podría explicar el desempeño irregular del que hablas.

Ponlo en un Plan de Mejora Personal.

En pocas palabras, no está trabajando al nivel que se espera de su posición y está empeorando activamente las cosas para los otros miembros del equipo, ya que tienen que dedicar tiempo a ayudarlo y corregir sus errores.

Como tal, el mejor curso de acción es hablar con RR. HH. para incluirlo en un Plan de mejora personal, que enumera los requisitos mínimos de desempeño para su puesto y requiere que los cumpla en una fecha determinada para conservar su puesto en la empresa.

O cumple con los requisitos para la fecha, en cuyo caso el problema se ha solucionado, o no los cumple y lo despides, en cuyo caso el problema se ha solucionado.