Leadership, responsibility, authority and teamwork are crucial ingredients in software projects. Some thoughts, triggered by recent blog entries, readings and accidental finds, may help to shed some light on these aspects.
(Disclaimer: Apologies if parts seem like ramblings but I haven’t been able yet to make more consistent connections between all concepts.)
Responsibility and Authority
When you are charged with managing a project, you are typically charged with achieving some objective with a budget (time, money). But are you always given the right parameters to achieve that objective? One important aspect is the right balance of responsibility and authority. If you feel to have a lot of the former but not enough of the latter then please read on!
As a project manager, you have the responsibility to take authority, rather than wait for someone to give you the authority.
No manager ever has enough real authority to do what he or she wants to do. There’s always someone with a bigger title. Even if you’re a CEO, you report to a board. Even though titular authority is useful, it’s not enough. If the project is strategically important to the organization, act first (doing whatever the project needs) and ask forgiveness later. You’ll know whether the project is strategically important by how many people ask about the status and what levels of people ask. The more people ask at the higher levels, the more strategic the project is. If the project is not strategically important, don’t waste your time trying to accomplish it. In reality, if the project is important enough to the organization, you have the authority to do just about anything you need to do. (You need the self-esteem to do what you need to do.) But if the project is not important enough to the organization, you can never get enough authority to do what you need to do.
A good definition of authority and responsibility:
Authority: The legitimate power given to a person to use resources and exercise discipline to reach an objective
Responsibility: The duties, assignments and accountability for results associated with a function or position
(Definitions on related concepts can also be found there). The author also quips that sometimes you just have to grab it [authority] and run with it and a person should be granted at least as much authority as she can handle, which seems in agreement with Rothman.
How should you use it? You should mainly use to enable your team to perform well, i.e., it’s not a license to tightly control your team but rather to remove obstacles that hinder your team. In other words don’t lead by command but rather by mission, be an enabler. This is at least my understanding of leadership as espoused by SCRUM and DSDM Atern.
Key principles of leading-by-task (or mission) were developed in the 19th century Prussian Army and state that the leader :
- informs what his intention is,
- sets clear achievable objectives,
- provides the required […] resources,
- will only order details regarding execution if measures which serve the same objective have to be harmonized, […],
- gives latitude to subordinate leaders in the execution of their task [mission].
This approach certainly takes a very dim view of micromanagement :
It is, therefore, out of the question that a colonel or even a general appoint himself squad leader to direct traffic at a road intersection or to instruct a patrol leader about his mission.
Rupert Smith, as a former general in Bosnia, demonstrates in  how a lack of clear intentions and goals and a lack of understanding of the capabilities of his resources (viz. armed forces) from his political leaders did leave him in difficult situations and often rendered him unable to use his resources with their full utility. True leadership is not easy.
The Team: Collective Wisdom
Current agile approaches place great importance on the project team, especially one that self-organises and is not managed by an old-style project manager. Important issues and results from social experiments relating to small teams are reported and discussed in , especially in Committees, Juries and Teams: The Columbia Disaster and How Small Groups Can Be Made to Work (Ch. 9). We tend to rely on a single person to make a decision rather than trust a (small) group of people to make a better and more consistent decision, sometimes with disastrous results.  concludes that:
[…] that there is no point in making small groups part of the leadership structure if you do not give the group a method of aggregating the opinions of its members. If small groups are included in the decision-making process, then they should be allowed to make decisions. If an organisation sets up teams and then uses them for purely advisory purposes, it loses the true advantage that a team has: namely, collective wisdom.
(Some people even seem to be able to overturn the image of the genius inventor by using teamwork.)
These are all from wikiquote on leadership and too fitting not to mention them:
Don’t tell people how to do things, tell them what to do and let them surprise you with their results. (George S. Patton)
If it’s a good idea, go ahead and do it. It is much easier to apologize than it is to get permission. (Admiral Grace Hopper)
A clear vision is usually assumed and rarely communicated. (Unknown)