Let go

Responsibility - Control Matrix

We observed on a recent program that the program manager was "taking control," but was also "avoiding responsibility" for the current state of the program and its eventual outcomes (it was very late). It seemed like the worst-case scenario in that the manager positioned himself as a gate keeper of information and control, while avoiding responsibility for the root causes of the problems (which were causing the delay).

We made this diagram(quicktime) to explain four possible management styles he could adopt, including the one we observed him doing (#2).

The classic A-Type personality is expressed in #1, but this also has the side effect of disempowering other team members since they are more than happy to let the leader take control and then live with the responsibility of success or failure. However, this can be an effective approach for small-team start-ups where someone needs to drive to a very fast result. Of course the worse case is #3 which we have observed in cultures that punish failure (versus reward success). This pattern has also been observed on very slow development programs.

The most effective team leaders adopt a form of #4 which is somewhat "bimodal" behavior. They delegate control, to milestone team leaders, who assume control of clusters of deliverables on a program. They assume responsibility for the overallprogram outcomes and with this responsibility comes an increased degree of credibility. Delegation of control also expands the leader's credibility with team members and up the management hierarchy. Empowered ("delegated") teams are much more effective, especially on large programs (i.e. >50 people).