Una empresa contrata formación para su área de sistemas y manda a todos a la misma clase: los tres desarrolladores, el líder técnico y el gerente de tecnología. Parece razonable y ahorra plata. Es un error, y se nota a la media hora.
El desarrollador quiere saber qué decir cuando le piden que sean dos semanas. El líder quiere saber cómo defender a su equipo sin quedar como el que siempre pone trabas. El gerente quiere saber cómo presentar el presupuesto del año sin que se lo recorten. Los tres están en la misma reunión de comité, del mismo lado de la mesa, y sin embargo tienen tres problemas distintos que se resuelven con tres criterios distintos.
El mismo hecho, tres problemas
Tomemos una situación concreta y miremos cómo la vive cada uno. Comercial pide una funcionalidad para el cierre de trimestre. El equipo la estima en cinco semanas. El trimestre cierra en tres.
Para quien construye
Su problema es de credibilidad individual. Tiene que explicar por qué son cinco semanas frente a alguien que no puede evaluar el argumento técnico, sin sonar a que no quiere. Si acepta el recorte, va a trabajar de noche. Si se niega mal, queda marcado como difícil. Necesita herramientas de conversación de a uno: cómo estructurar una estimación, cómo ofrecer una alternativa, cómo decir que no sin decir que no.
Para quien conduce el equipo
Su problema es distinto y más incómodo: tiene que sostener a su gente hacia arriba mientras le explica hacia abajo por qué a veces hay que ceder. Está en el medio, y las dos partes esperan lealtad. Si defiende siempre al equipo, arriba lo leen como que no entiende el negocio. Si cede siempre, abajo lo leen como que no los banca. Necesita otra cosa: criterio para elegir qué peleas dar, y cómo comunicar una decisión que él tampoco quería.
Para quien responde por el área
Su problema no es esta funcionalidad. Es que este caso va a repetirse doce veces este año, y cada vez que su área diga que no, se gasta capital político. Necesita algo completamente diferente: cómo instalar un mecanismo —un comité de priorización, una regla de compromiso, un tablero compartido— para que la discusión deje de darse caso por caso. Y cómo presentar eso a sus pares sin que suene a burocracia.
Por qué mezclarlos empeora la clase
El problema de juntarlos no es solo que el contenido le sirva a un tercio. Es que la presencia de unos cambia lo que los otros están dispuestos a decir.
Con el jefe en la sala, nadie cuenta lo que salió mal. Y el material más valioso de estas clases son justamente los casos que salieron mal. Un desarrollador no va a contar delante de su líder que la semana pasada aceptó un plazo imposible por no discutir. Un líder no va a contar delante de su gerente que no supo qué contestar en el comité.
La conversación se desplaza hacia arriba. Cuando hay alguien de mayor jerarquía en el grupo, la clase deriva sola hacia sus temas. Los demás participan menos, y a las tres semanas dejan de venir.
El nivel de abstracción no coincide. Lo que el gerente necesita es estructural y a doce meses. Lo que el desarrollador necesita es una frase para el martes. En la misma hora, uno de los dos se aburre.
Por qué sí son acumulativos
Separar los públicos no significa aislarlos. Nuestros planes son escalonados: quien está en Líderes ve también todo lo de Equipos, y quien está en Dirección ve los tres niveles. Y eso no es un argumento comercial, es una necesidad práctica.
Un líder que no entiende qué le pasa a su desarrollador cuando le recortan un plazo, no puede defenderlo. Necesita haber visto ese material, no porque vaya a usarlo él, sino porque tiene que reconocer la situación cuando la vea en su equipo.
Y un gerente que nunca vio el contenido de líderes va a diseñar mecanismos que no se pueden ejecutar. La cantidad de comités de priorización que fracasan porque nadie consideró qué implican para el que está en el medio es enorme.
La regla es simple: cada nivel necesita conocer el problema del nivel de abajo, aunque no lo tenga. Al revés no es cierto: un desarrollador puede trabajar muy bien sin saber cómo se arma el presupuesto anual del área.
Qué se trabaja en cada uno
Equipos de desarrollo
La conversación de a uno. Estimar y sostener la estimación. Preguntar antes de construir. Dejar rastro sin que cueste. Explicar un problema técnico a alguien que no lo es. Decir que algo no está listo. Pedir ayuda sin que parezca que no se puede.
Líderes
Todo lo anterior, más: elegir qué peleas dar. Comunicar hacia abajo una decisión que uno no comparte. Proteger al equipo sin bloquear a la organización. Distribuir trabajo cuando todo es urgente. Dar una devolución difícil. Sostener un compromiso de equipo cuando alguien no cumplió.
Gerentes y directores
Todo lo anterior, más: presupuestar un área técnica y defenderlo. Presentar riesgo a un directorio que no quiere escuchar riesgo. Instalar mecanismos que sobrevivan a las personas. Negociar con pares de otras áreas que compiten por los mismos recursos. Explicar una decisión técnica en términos de plata y de tiempo.
El caso de la empresa que manda a todos
Cuando una organización contrata para varias personas, la pregunta correcta no es «cuántos van» sino «quiénes van a cada grupo». Y la respuesta casi nunca coincide con el organigrama.
Hay desarrolladores sin gente a cargo que en la práctica lidian con áreas usuarias todo el día: esos necesitan el contenido de líderes aunque su cargo no lo diga. Hay jefes con título que no negocian nada porque su gerente lo hace todo: esos están mejor en el nivel de abajo hasta que eso cambie.
La ubicación se decide por la conversación que la persona tiene que sostener, no por lo que dice su contrato. Esa es una de las cosas que conviene definir en la reunión, antes de armar el presupuesto.
Cómo saber en qué nivel está usted
Si tiene dudas sobre cuál le corresponde, la pregunta no es cuánta gente tiene a cargo. Es esta: ¿de qué tiene que responder cuando algo sale mal?
Si responde por su propio trabajo —lo que usted construyó, lo que usted estimó—, el nivel es Equipos, aunque haga diez años que programa.
Si responde por el trabajo de otras personas, aunque no sea su jefe formal, el nivel es Líderes. Alcanza con que en la reunión de comité le pregunten a usted por qué el equipo no llegó.
Si responde por el área frente a sus pares de otras gerencias, y su problema no es una entrega sino doce por año, el nivel es Dirección.
La ganancia menos obvia
Hay un beneficio de esta separación que aparece recién a los meses y que las empresas no anticipan.
Cuando el desarrollador, el líder y el gerente pasaron por los tres niveles —cada uno en su momento y en su grupo—, empiezan a compartir vocabulario. El líder reconoce cuando su desarrollador está haciendo el movimiento de ofrecer una alternativa con su costo, y lo apoya en vez de interrumpirlo. El gerente entiende por qué su líder pidió postergar una discusión.
Ese vocabulario común no se logra poniéndolos en la misma clase. Se logra dándoles el mismo criterio en tres formas distintas, cada uno con la suya. Es más trabajo y funciona mucho mejor.
Vea los tres planes y qué abre cada uno, o pida una reunión para definir quién va a cada nivel en su equipo.
