archivo

Archivo de la etiqueta: empire building

Una conducta que puede considerarse un antipatrón es la orientación que determinadas personas (siendo extensible incluso a equipos de trabajo) tienen hacia ir incrementando el número de medallitas que van obteniendo en la realización de su trabajo, sin tener cuenta a costa de qué se están obteniendo las mismas.

No es malo ir acumulando méritos, lo malo es pensar que para ello todo vale:

– Asumir logros que no te corresponden y lo que es todavía peor que eso: si todo sale bien es gracias a mi y si todo sale mal es culpa de otro.

– Dar información parcial o falsa sobre el estado de un proyecto, de una tarea, etc…

– Que los logros sean como consecuencia de un perjuicio de otros compañeros o del cliente, como por ejemplo, vender proyectos imposibles que tienen que ejecutar otros, romper equipos de proyecto consolidados de otros compañeros para traerte a componentes de los mismos hacia tus proyectos sin que existe justificación objetiva (antipatrón “Empire building“), ganarte la confianza ante el cliente a costa de crear desconfianza sobre otros compañeros, hacer que otros asuman tareas que te corresponden, conseguir márgenes de beneficios más importantes en el proyecto a costa de la satisfacción del cliente, etc…

– Por la relación de amistad existente con personas que se encuentran en un nivel superior en la jerarquía de la organización.

Se puede tener un espíritu competitivo, ser ambicioso, pero no todo vale, hay reglas escritas y no escritas. No vale conseguir determinados objetivos a costa de romper el equilibrio de un grupo, tal vez a corto plazo pueda dar buenos resultados pero a la larga resulta nefasto.

Todo gestor quiere contar con el mejor equipo posible para realizar sus proyectos. Cada gestor tiene una idea de equipo ideal, ya que la escala de valores de cada persona suele ser distinta, no obstante, hay “jugadores” que tienen cabida en más de un equipo (cuando no en todos) y ahí es donde se pueden producir conflictos.

Lo más habitual en las organizaciones es que cada gestor tenga un equipo de personas a su cargo más o menos fijo (su personal de confianza) y otro grupo de técnicos que colaboran en proyectos que se estén ejecutando pero que su adscripción al gestor es coyuntural, salvo que de alguna u otra forma destaque en una o más variables valoradas por el gestor y éste decida la inclusión en su equipo (si hay hueco).

Los gestores suelen pelear por mantener a su equipo fijo como sea, para lo cual se requiere la existencia de carga de trabajo. En ocasiones aceptarán compartirlo con otros gestores de manera parcial o total (se marcha a otro proyecto durante un tiempo con compromiso de volver cuando termine o cuando sea posible), con tal de no perderlos definitivamente, pero si no entra trabajo suficiente pasarán a formar parte del equipo de confianza de otro gestor y se perderá la posibilidad de recuperarlo.

Hasta ahí, todo normal en lo que es una empresa de desarrollo de software. El problema viene y de ahí este antipatrón, cuando un gestor impone su fuerza (ya sea por su mayor grado de influencia con la dirección o por tener a su cargo proyectos importantes) para quitarle a otros gestores a técnicos de su equipo, cuando estos los tienen asignados a proyectos. Es decir, se quita capacidad a otros gestores para que tu equipo gane capacidad.

Los desarrolladores no son todos iguales, en productividad, conocimientos, experiencia, adaptación a un entorno, contexto o cliente, etc…, por lo que si a un proyecto le quitan alguno de sus baluartes, indudablemente le afectará (a lo que hay que sumar el tiempo necesario para que un posible sustituto pueda adquirir un nivel productivo aceptable), afectando también a la productividad del equipo de proyecto en su conjunto sobre todo si el mismo estaba bien consolidado.

A eso hay que sumar el deterioro de la relación entre los gestores y el hecho de que concentrar mucho talento en un equipo no necesariamente garantiza nada.

Siempre he defendido que una organización debe intentar asignar a cada proyecto al mejor conjunto posible de personas para poder realizarlo dentro del conjunto de técnicos que puedan estar disponibles (estén o no asignados a proyectos, es decir, se puede estar asignado a un proyecto y por la naturaleza del mismo o su estado, puedan ser sustituido sin mucha pérdida por otras personas).

Ahora bien, también defiendo que si hay equipos que funcionan bien, no hay por qué romperlos, de manera que el mejor conjunto posible de personas que indicaba en el párrafo anterior no lo será si para ello se fractura a un equipo que produce buenos resultados, están contentos y trabajan eficientemente.