No solo es una pregunta incómoda de entrevista, sino también una situación muy desagradable de encontrar en el trabajo. Además, no es que haya una fórmula determinista para tratar a las personas: los seres humanos somos bastante complejos y hay que analizar con pinzas cada escenario.
Aterrizar el problema
Puede parecer trivial trivial, sin embargo, al principio puede ser que solo tengamos la "sensación" de que ese compañero de trabajo está rindiendo menos. Por esta razón, primero tenemos que salir de la sensación, y movernos a datos duros:
- ¿cuál es nuestra medida de referencia?
- ¿cuáles son las expectativas/responsabilidades del cargo?
- ¿las expectativas son visibles? ¿El empleado las conoce?
- ¿las expectativas son medibles?
- ¿cómo estamos midiendo el rendimiento y crecimiento del desarrollador en función de esas expectativas?
- ¿esta persona se está encargando de algún problema importante que ignoro?
- ¿esta persona tiene algún bloqueo que ignoro?
Con base en las respuestas a las preguntas anteriores se puede entender si el problema es el desarrollador o el sistema.
Comunicación 1-a-1
Si está claro que hay un problema de rendimiento, entonces hay que hablarlo de forma amable, respetuosa y directa.
En el pasado evité tener esta conversación. Decidí asumir más carga de trabajo para poder cumplir con las metas del equipo, creyendo que por arte de magia el problema se solucionaría solo. Sin embargo, esto es solo una bomba de tiempo. Solo creía el cansancio, la frustración y el resentimiento, al punto que me era imposible conciliar el sueño. Por esta razón, HAY QUE ARMARSE DE VALOR Y HABLAR.
Para empezar, hay que tener la conversación en privado. JAMAS en una retrospectiva o frente al equipo. Como dice Dale Carnegie en Cómo ganar amigos e influir sobre las personas, "Deja que la otra persona salve la cara" - queriendo decir que no hay que hacer quedar mal a la otra persona.
Una vez en la conversación, se puede plantear el tema sin acusaciones, citar aspectos puntuales y comprobables, y siempre abordarlo con curiosidad y apertura. En lugar de decir "no estás entregando lo que deberías", tal vez puede ser mejor decir "Habíamos acordado que ibas a entregar las últimas dos tareas en las fechas X y Y. Sin embargo, no fue así. Definimos estos criterios de aceptación, pero no se cumplieron en ninguno de los dos casos. ¿Me podrías ayudar a entender, por favor, qué está pasando?
La mayoría de problemas de baja de rendimiento no se solucionan con ordenar "trabaja más rápido". Esto sería equivalente a decir a una persona con depresión: "no estés triste". Hay que entender qué está pasando y ajustar algo.
Cuando falta capacitación técnica
Aquí tenemos dos posibles escenarios:
- Se puede hacer un plan de mejora con trazabilidad y seguimiento activo.
- Se reconoce que la persona simplemente no tiene el nivel técnico que el rol necesita.
Plan A: Plan de mejora
Si se decide hacer un plan de mejora debe ser como un objetivo SMART:
- S - Specific (Específico): Qué se quiere lograr exactamente, respondiendo a quién, qué, dónde y cuándo.
- M - Measurable (Medible): Debe incluir indicadores clave de desempeño (KPIs) para cuantificar el éxito.
- A - Achievable (Alcanzable): La meta debe ser realista y posible de lograr con los recursos actuales.
- R - Relevant (Relevante): Importante para la estrategia general de la organización o crecimiento personal.
- T - Time-bound (Temporal): Establecer un plazo claro o una fecha límite para su cumplimiento.
No se le puede decir al desarrollador: "Tienes que aprender más Swift", sino tal vez, "Tienes que entender y saber implementar los algoritmos de búsqueda A y B, usando Swift. Para ello te sugiero consultar estas referencias. Tienes un mes para alcanzarlo. Cada semana me vas a enviar un reporte de los avances. Cada dos semanas nos reunimos una hora para que me cuentes las dificultades que has tenido."
Plan B: La persona no tiene el nivel técnico
A veces, sin importar cuánta capacitación se de al empleado, simplemente esta persona no cumple las expectativas.
En este caso, vale preguntarse:
- ¿El plan de mejora está sirviendo?
- ¿Con qué velocidad está mejorando?
- ¿Puedo ponerlo en otro equipo mientras tanto?
- ¿Puedo asignarle tareas de menor dificultad?
- ¿Cómo está el ambiente del equipo? ¿Otros desarrolladores manifiestan frustración?
Lo que no funciona: que se vaya solo
Como mencioné antes, en el pasado preferí evadir la situación incómoda, en lugar de enfrentar la conversación difícil. Es horrible para todos: para la otra persona, para el equipo y para mi como empleado (porque llevo una carga adicional) y como líder (porque pierdo credibilidad).
Si alguien no está funcionando en el rol y ya se agotaron las opciones, hay que decirlo directamente, con amabilidad y con respeto.
Impacto en el resto del equipo
A veces se cree que el problema de rendimiento de un desarrollador no impacta a la moral del equipo, pero es algo a lo que se debe echar un ojo.
Hace muchos años estuve en una empresa donde contrataron a otro desarrollador iOS que llamaré "Juan". Juan era súper amable y tenía una gran energía. Era ese tipo de personas alegres de las que te quieres rodear. Juan hizo el onboarding de la empresa y del proyecto al que fue asignado. Hasta aquí todo normal. Luego, se le asignaron tareas. En este punto se hizo visible que entregaba incompleto, tarde y con baja calidad. Era necesario que otros desarrolladores se ocuparan de sus tickets para poder cumplir con los deadlines.
La moral del equipo estaba baja, sin embargo, todavía no había llegado lo peor.
Un día, el equipo estaba llegando del almuerzo a sus puestos de trabajo, cuando Juan exclamó al aire cuánto dinero recibía por salario. Todos nos quedamos paralizados - claramente aquí hay un problema de transparencia en los salarios y falta de claridad en las expectativas de los roles, pero vamos a omitir ese detalle por ahora.
De inmediato puede ver cómo desmejoró el desempeño de todo el equipo: no solo en el código que entregaban, sino porque yo estaba encargado de unas sesiones de capacitación y podía notar que las personas ya no estaban interesadas en ellas. Le pedí a otro desarrollador, que voy a llamar "Pedro", que preparara una charla técnica sobre un tema específico. Su respuesta fue: "¿Por qué me voy a esforzar extra para preparar una charla, si Juan ni siquiera cumple con lo mínimo que se le pide y gana mucho más que yo?" - No fui capaz de responderle. Ni siquiera pude validarlo. Me sentí bloqueado porque incluso yo me sentía así.
Cuando alcé la mano a mi líder y le comenté acerca de esta situación, desestimó la preocupación que le expresé bajo la idea de que "Juan estaba pegando el ladrillo" y que era mucho más costoso despedirlo que dejarlo ahí. Además, al tenerlo en la nómina podían cobrarle al cliente por un desarrollador más.
Supe que más de uno empezó a buscar ofertas de empleo en otras empresas y uno a uno los desarrolladores renunciaron.
No existe una fórmula
Cada caso es distinto. He tenido compañeros de equipo y desarrolladores bajo mi cargo que después de una conversación clara mejoraron mucho, y otros que, a pesar de haber intentado todo por meses, no cambiaron en lo absoluto.
Lo más importante es aprendí es que evitar la conversación NUNCA resuelve el problema. Se exigir sin ser autoritario.
Tú, querido lector, ¿has estado en una situación parecida como lead o como parte del equipo? ¿Qué me recomiendas?
Top comments (0)