LeadershipAntiPatterns (examples of bad LeaderShip, a/k/a TeamKilling)

	* DoAsiSay. (with no reasons given)
	* Set impossible time lines, so "people get under stress and work better/faster". 
	* ShootTheMessenger
	* QuickerFasterCheaper Emphasize cost and time over quality.
	* Require time estimations, but give no feedback.
	* Assign responsibility, deny empowerment. 
	''Q: Is this the same as BlameManagement?''
	* Lie
	* BenignNeglect
	* Ignore people's strong skills, the opposite of GetToKnowYourPeoplesSkills

See also: LeadershipPatterns

----
Yes, actual experience. I fired the leader by resigning the job after some time. :) -- JuergenHermann
----
New point 6, been there, had that done to me. o o o HalSmith
----
I'd like to add my views:
	* It is the worker's responsibility to do their work, the manager's to find em something to do if they don't know what to do. However, both the worker and the manager should know what each other is doing. Corollary: if the worker is already doing something, the manager should not intervene unless the work is clearly useless.
	* Most of lost time is because workers are uncertain about what to do, not because of their laziness. Most uncertainness is a result of insufficient worker intercommunication. Corollary: keep meetings. Corollary: meetings are there to enable people to work, and nothing else (except, of course, as a relaxing social habit). Keep them so. Make sure that, after a meeting, everybody knows what to do next.
	* The point of having managers is to, of course, take management off worker's shoulders. Management includes knowing what everybody is doing, prioritising things, and helping with communication. Don't intervene in something the workers can manage themselves. Corollary: the manager's job is to make life easier, not harder.

So my LeadershipAntiPatterns include:
	* keeping superfluous meetings
	* BehaviorCode
	* requiring to be given more respect than you give (and other power-play related things)
	* checking all the time that people are doing what they should be doing
	* not giving clear view of expectations to a worker
	* checking work hours
	* most forms of surveillance (if you already have clear goals set, why would you have to?)
	* not checking goals regularly
----

IMHO there are two key qualities involved here. One is good management ability (the ability to track, assign and control work tasks) and the other is good leadership ability (people skills; the ability to inspire, give direction and generally... err... lead).

From my experience, most of the AntiPattern''''''s I've seen (and there are fair few above which I have), it is a deficiency in one of these qualities which gives rise to the AntiPattern, as a general rule-of-thumb. Not always, but often.

E.g. a manager who regularly calls superfluous meetings, I would argue (from experience) has a deficiency in their management style when it comes to control. They want to know all about what people are doing in detail to try and control the people because they obviously feel out of control, at least to some extent. They see meetings as a way of gathering more information on the (not necessarily well-founded) premise that more information means better control.

Other examples, like checking what people are doing all the time, "power-games" or ShootTheMessenger indicate poor leadership. The manager clearly does not feel as though their talents, people skills and management style inspire team members, and so (at least at a subconcious level) feels the need to throw their weight around to get the respect they believe they should have. 

Sometimes (rarely) you get good managers, who have both good management skills and good leadership skills. Equally (rarely), you get managers who have very weak management and leadership skills (often the senior developer-cum-team leader scenario). Most of the time, managers tend to fall in the middle and have strength in management skills but weakness in leadership, or vice versa.

I propose (therefore) that a lot of these AntiPattern''''''s are reflective of either management or leadership weaknesses.

Management AntiPattern''''''s:

	* IwantItYesterday, TimeIsMoney or QualityIsOptional - The manager has messed up scheduling/timescales and Joe Bloggs developer has to pick up the slack in the shortest amount of time possible without regard for following quality procedures.
	* SuperfluousMeetings - The manager holds too many team meetings, people often feel as though meetings are directionless, or feel that their attendence was irrelevant. The manager is trying to exert too much control.
	* OneWayStreet - The manager views the process of management as a one-way delegation activity. They control all the management but give no proper feedback to team members. Once a problem has been handed to someone in the team, the manager considers their role to be over.
	* NoGoals - The manager doesn't want to set goals for team members. Often spotted in statements like "person X, will you start the code for this", rather than definite targets, e.g. "person X, can you have the code written for this module by Y". Often the manager has a good idea of the actual goals but doesn't communicate these to the team or hides their poor style under the guise of "not wanting to stifle creativity" etc. 

LeadershipAntiPatterns:

	* PenPusher - The manager is so busy drawing up Gantt charts, project plans and constantly revising estimates that the process of actually running the team degenerates, goals are often not set for team members etc. The manager is not acting as a conduit for information flow within the team.
	* IamTheLaw - The manager demands respect by default rather than earning it.
	* QuestionsQuestionsQuestions - The manager believes they know the solution to technical issues better than the engineer who is looking at the problem. As such, the person working on a problem will constantly be asked to either revise or justify all decisions they make. This is what peer reviews or presentations are for.
	''Q: This sounds like what's commonly known as MicroManagement. Is there a difference?''

There are quite a few others, and I think pretty much all of the above comments are good ones. Please feel free to amend/disagree etc. These are all just my thoughts.
----
A few I haven't seen mentioned here yet:
	* SpecifyNothing - This pattern assumes that all elements of a system in flux can be most easily managed if they only exist in the developers' heads.
	* HiddenRequirements - This occurs when system requirements are not adequately documented, either through carelessness, ignorance, or malice.  HiddenRequirements often arise from use of SpecifyNothing;  In extreme cases, SpecifyNothing can be used as an excuse to retroactively create HiddenRequirements in order to sink a project or damage a career ('Your subsystem doesn't implement the XYZ protocol?!?  What do you mean, you "didn't know it was supposed to"?').

''Require time estimations, but give no feedback.''

Or give feedback which is overridden it in practice.  

I had a project manager who would ask me for time-estimates for tasks which I would duly supply; being inexperienced and optimistic these started off light, usually 20-30% short, but certainly in the right order of magnitude (with hindsight a good achievement).  At completion and during my performance reviews I received the feedback that my performance at estimating was poor and I would be marked down.  FF to the next round of project planning and I start adjusting my estimates upwards appropriately.  The project manager starts responding to these larger estimates are to large so "they will need to be adjusted downwards for the plan so that we get the work", around comes the next review and 'my' ability to estimate is once again marked down.

----
See AmeliorationPattern
----
CategoryAntiPattern