PM encouraged self-organization

Similarly to Organization leaving maximal freedom to a PM (see PM Rules vs Organization Rules post), a PM is responsible to leave as much freedom for Development Teams as possible. My experience shows that trials to impose uniform cross-project set of rules always result in some pathology or at least turn out to be a sub-optimal choice in a context of a project. Remember that different Development Teams work out usually different set of rules based on specific project needs and needs of individuals. 

It is a PM role to encourage such self-organization processes and not to sacrifice them by any means for a set of rules applied dumbly from managerial layers. (The technics for supporting self-organization are described very interestingly in Mike Cohn’s Succeeding with Agile.) One can be truly surprised with an amount of ways a Team can self-organize. I have worked with many Teams and to be honest the way of self-organization is almost always different.

Since all value emerges from the level on which a piece of work gets done, it is a mature’s PM and Organization role to be responsible to spot the most valuable set ups, or Best Practices if you like, and propagate the value to higher levels – a Programme level, Account level, Department level, and so on, up to an Organization level. A challenging intellectual effort here for management is a creation of a work environment in which such propagation is not only possible but happens by default in a natural way, or I would say unconsciously, without any case-based encouragement.

Still it is very common in ego-based, or pecking-order-based Organizations to go in the opposite direction. Producing too rigid suite of formalized processes, sticking to these in an inflexible manner, managing based on a position in a hierarchy rather than creativeness, neglecting a need for a continuous improvement, etc. is seen too often. This is one of the key managerial anti-patterns and the shortest way to a disaster.