Ayer, en el cumpleaños-despedida de un Big-Padawan, el festejado hizo un comentario más o menos así: “capaz que cuando vuelva, me encuentro a todos como gerentes”. Mi cerebro lo procesó un poco lento debido a que los niveles de alcohol lo estaban afectando.
¿Quién demonios quiere ser gerente?
La gente que hace software, pero que REALMENTE nos apasiona hacer software no se puede separar del código mucho tiempo. Con cada proyecto intentamos volver a sentir ese mind-blow de la primera vez que programamos: creador todopoderoso, genio y poseedor de uno de los secretos del universo que son vedados para los mortales.
Por eso, vemos gerentes y líderes de proyecto que a la primera oportunidad se meten a hacer código (o pruebas, ja). No hay definiciones de puesto lo suficientemente rígidas que alejen a un “mando superior” de “ensuciarse las manos”.
¿Por qué queremos ser gerentes?
Existe la presión social de escalar. En las tarjetitas de presentación se llaman Developer Jr y Senior. Líder, Gerente, Subdirector, CEO, Presidente Mundial. Nos han enseñado que si queremos ganar más dinero, prestigio o simplemente, poder decidir e influir, necesitas tener un puesto de mando.
Nos cuadramos ante el título y aplicamos el organigrama para presionar a otras áreas. Eso es tristísimo. Eso quiere decir que no sabemos trabajar en equipo, que aplicamos el CYA (cover your ass) y no aprendemos. Ser gerente y servir sólo para eso es, desde mi punto de vista, un trabajo horrible y sucio. Cuando trabajamos así, tenemos unas enormes anteojeras que nos impiden ver más allá de nuestro mundito.
No se necesita ser gerente para ser líder, para proponer nuevas formas de trabajo, para influir en la gente. Sólo se necesita un ambiente en el que te sientes feliz trabajando. Que te permite equivocarte y ser creativo. En el que todos son escuchados y se sienten seguros. En el que tenemos oportunidad para aprender cosas nuevas.
Ése es mi sueño. Creo firmemente que es la única manera en la que la gente dará todo su potencial. Pero es muy, muy difícil. Espero que cuando volvamos a ver al Big Padawan, no seamos gerentes.
jueves, 22 de noviembre de 2012
martes, 6 de noviembre de 2012
Aprendizaje y retroalimentación
Alguna vez leí que para comprender e interiorizar un concepto nuevo, es necesario que te lo digan siete veces. No estoy segura que sólo decirlo sea suficiente. Hoy me di cuenta que la retroalimentación es parte importante en el proceso.
Siempre he tenido el sentimiento que el programador no tiene idea de cómo va el release o el sprint. Y no es su culpa; durante mucho tiempo, hemos instruido sólo a líderes de proyecto sobre gráficas y seguimiento de proyecto y les decimos que afinen su puntería para atinarle a los programadores que necesitan latigazos.
Con el equipo auto-organizado, este seguimiento recae en todos. Todos deben tener visibilidad de cómo va el equipo (no sólo sobre su trabajo) y si van a terminar a tiempo. A veces se piensa que con la junta diaria se tiene esta visibilidad. Falso: ahí te enteras, si es que el programador lo dice, los problemas que hay. El impacto de esos problemas en el equipo completo, puede no verse con claridad.
Ayer les mandé por mail, el dashboard para el seguimiento. El mail lo ignoraron la mitad de los integrantes; el resto que sí lo leyó, ninguno entendió de qué se trataba. Y por supuesto, nadie me comunicó lo que les pasaba por la mente.
Aunque no tenía intención de revisar el dashboard en equipo, el contarles la técnica pomodoro para mantener el WIP (Work in Progress) bajo, nos hizo revisar las actividades planeadas. Entonces ocurrió la magia que sólo pasa en equipo. Los que no saben preguntan, los que saben contestan con su experiencia. Yo apenas intervengo.
Un par de horas después de la junta, el gap entre la fecha esperada y la planeada se ha cerrado en la gráfica de burn-down. Pero más importante: aprendí que ignorar el ser ignorada es una piedrota para dar una efectiva retroalimentación.
Suscribirse a:
Entradas (Atom)