Hace unas semanas, en el artículo sobre escribir para pasar a senior, escribí: «Nos guste o no, hay que vender nuestro trabajo, incluso internamente (ya escribiré sobre ello en otro momento)».
Pues ese momento es hoy. Tiene nombre en inglés, managing up, y muy mala traducción en español: «liderazgo inverso», o «gestionar a tu jefe».
Ahora que lidero el equipo de diseño de WordPress.com lo veo desde el otro lado de la mesa (virtual). Te cuento qué me ayuda.
Qué es managing up
Dicho así suena a hacerle la pelota a tu jefe, pero no tiene nada que ver con eso.
Puede que incluso estés pensando que tú, desde tu rincón, no puedes «gestionar» a tu jefe, que está más «arriba» jerárquicamente.
En la práctica, managing up es encargarte de que tu manager tenga la información que necesita para tomar decisiones contigo, sobre ti y sobre tu trabajo. También para que haga aquello que necesitas pero que tú no puedes cambiar, porque implica cambios a nivel organizacional o de equipo. Para que pueda ayudarte.
Es algo que me costó mucho integrar en mi día a día, porque me parecía un poco injusto. Pero si te paras a pensarlo: igual que un manager te «gestiona» a ti, ¿por qué no deberías hacerlo tú también? La relación debe ser lo más simétrica posible, porque en realidad os necesitáis mutuamente.
Tu manager también tiene un manager
Y objetivos que no siempre te cuenta. Casi nunca por esconderlos, simplemente no se le ocurre que te interesen.
Cuando empecé como lead, lo primero que tuve que hacer fue entender la unidad de negocio: cuál era la situación, qué objetivos teníamos y qué proyectos estaban en marcha. Eso mismo te sirve a ti, un nivel más abajo (pero no por ello menos importante).
Pregúntaselo en vuestro próximo 1:1: «¿Qué te preocupa más este trimestre?».
Si a tu manager le preocupa la conversión del onboarding, tu rediseño del paso dos no es «más limpio». Es el paso donde se pierde gente, y cómo lo has cambiado para que pase menos.
Para eso necesitas saber qué métrica le importa a quien te escucha. Sin ella, cualquier explicación de tu diseño se queda en opiniones (de esto hablé más a fondo en cómo explicar el valor del diseño).
Yo valoro mucho cuando alguien me pregunta: «¿Cómo te puedo ayudar?». Porque, al fin y al cabo, yo tengo una posición intermedia en la que tengo que alinear y ayudar a diferentes niveles. Y también hago managing up 🙂
Si tu manager no viene de diseño, traduce
Puede que tu manager sea alguien de producto, de ingeniería o incluso de marketing. No todos entienden el diseño igual, y en ese caso la mitad del managing up es traducir.
Hace años, el manager que tenía era el CTO. Su formación estaba alejada del diseño, así que me esforcé por explicárselo todo bien sin entrar en cuestiones técnicas, centrándome en por qué resolvía el problema de una manera y no de otra.
No le hables de la jerarquía visual o de la consistencia de los componentes. Háblale de cómo cambia la experiencia del usuario y qué gana el negocio. Eso sí puede repetirlo en su siguiente reunión.
Y ten un poco de paciencia. Tu manager no tiene por qué saber qué es una design critique, igual que tú no sabes cómo se calcula el presupuesto de un equipo o cómo se prepara la infraestructura de un proyecto.
Veinte proyectos en la cabeza
Cuando pasé de individual contributor a liderar el equipo de diseño, mi día a día pasó de uno o dos proyectos a tener visión sobre unos veinte: los actuales y los que vendrán.
Sé cómo encaja cada uno con los demás y con los objetivos del negocio, veo más allá del día a día, y planifico las próximas semanas del equipo a la vez que los ayudo con los proyectos actuales.
Sé quién trabaja en qué. Reviso con producto todos los proyectos que hay en el pipeline antes de que lleguen al roadmap, y estoy en la reunión semanal donde lo repasamos.
Aun así, no lo sé todo (sería imposible sin clonarme).
Mientras tú trabajas en un proyecto, a veces te das cuenta de que el alcance crece, porque aparecen nuevos casos de uso, limitaciones técnicas, o cualquier otra cosa. Pasa mucho. Y eso no siempre aparece en la reunión de roadmap, permanece «oculto» hasta que alguien lo comunica.
Por eso, lo que tu manager sabe de tu trabajo es, en gran parte, lo que tú le cuentas. Si no le cuentas nada, rellena el hueco con la información que le llega por otro lado, o asume cosas.
Si tu manager te persigue, le falta información
No me gusta hacer micromanagement. Pero a veces siento que lo hago, y casi siempre es por lo mismo: tener que perseguir a alguien para que actualice su weekly update o sus proyectos en Linear.
Rafe Colburn tiene una regla para el managing up que resume bien lo que me pasa: no dejes que a tu manager le importe algo más que a ti. Cuando pasa, tu manager te lo recuerda una y otra vez, y eso (desde tu perspectiva) se parece mucho al micromanagement.
Yo no pido esas actualizaciones por controlar. Las necesito para tener una foto clara de en qué está trabajando el equipo y, sobre todo, de cuánta carga de trabajo tiene cada persona.
Si el alcance de tu proyecto ha crecido y no lo sé, puedo asignarte otro proyecto encima. O prometerle a producto una fecha que ya no es realista, porque tienes otros proyectos entre manos.
Cuanto más fácil me sea entender en qué punto está un proyecto y qué lo bloquea sin tener que preguntarte, mejor.
Normalmente lo veo, pero agradezco mucho cuando mi equipo me cuenta si un proyecto se retrasa, si hay un bloqueo, si una propuesta no convence a producto o si hay un conflicto con alguien de otro equipo.
Como manager, puedo mover prioridades, hablar con otro equipo o pedir más tiempo, pero solo si me entero a tiempo y tengo suficiente información. Si el problema me llega por otra persona antes que por ti, el margen es mucho menor.
Pedir ayuda también es informar
Desde fuera puede parecer que escribirle a tu manager para pedirle algo es molestar.
A mí no me molesta.
Agradezco mucho cuando alguien de mi equipo me escribe, en un canal público o por privado, para pedirme mi opinión, contarme una idea o que le ayude a desbloquear algo. También para pedirme feedback sobre un Figma, un prototipo en código o un dashboard con datos que han montado.
Y cuando me mantienen al día, no me importan los detalles. Los agradezco siempre.
Cada vez que me escriben así, me ahorran tener que ir a buscarlos. Y ellos deciden qué me cuentan y cómo, en lugar de que lo decida yo con una pregunta en el peor momento.
Si recibo muchos pings durante el día es mi problema, y es mi trabajo gestionarlos de manera que pueda contestar a lo más importante sin agobiarme.
Esta «política» la saben porque se la he comunicado. Si tu manager no lo ha dejado claro, pregúntale qué tipo de interacción prefiere.
Nadie defiende lo que no conoce
En algún momento del año, alguien va a preguntarle a tu manager por ti. En una revisión de rendimiento, en una conversación sobre ascensos o cuando haya que decidir quién lleva el siguiente proyecto importante.
Ese día tu manager necesita ejemplos concretos, y probablemente no se acuerda en detalle de todo tu trabajo de marzo.
Yo tampoco me acuerdo de todo.
En Automattic todo pasa por escrito. En una reunión gana quien habla más y mejor; en un documento suele ganar el argumento mejor construido. Con tu manager pasa lo mismo: si tu trabajo está escrito (en el weekly update, en Linear, en un P2), lo puede citar.
No hace falta nada complicado:
- Un resumen corto y periódico. Qué has hecho, qué has decidido y qué te bloquea. Tres párrafos son suficientes, sobre todo si añades enlaces que contienen más contexto.
- Una lista de logros. Con números si los tienes. Sirve tanto para tu manager como para tu próximo portfolio (te lo contaba en documenta tu progreso).
- Lo que otros han dicho de tu trabajo. Un mensaje de alguien de ingeniería dando las gracias cuenta mucho 😉
Apuntes finales
Al final, managing up es hacer visible tu trabajo a la persona que más puede ayudarte con él.
Si tengo que perseguirte para saber en qué estás, ese tiempo no lo dedico a ayudarte. Cuéntamelo antes de que te lo pregunte.
