I came across this list of management behaviors (http://suven.posterous.com/dos-and-donts-leading-software-development-te).  I think it has some gems, but I'm not 100% on some of them. I've marked those ones with italics and my name.Do you, as a software developer, think that these are appealing? Which three would be your TOP gotta have 'em items from your management?Don'tDon't scale teams vertically by adding more peopleDon't create a team with more that 10 peopleDon't call people resources, its not cool and is really offensiveDon't assume that people in teams are interchangeableDon't compare teams to each other when highlighting weaknessesDon't pitch teams against each otherDon't create fake deadlinesDon't force standardisation of tools and processes across teams (I think this one can be argued for some situations - Todd)Don't hire product managers who don't have a clue about software developmentDon't exclusively use KPI's to drive your teams (Not only is it ineffective, but developers will find ways to drive the KPI metrics - You want lines of code? I've got your lines of code! - Todd)Don't force your teams to work overtime, even asking is bound to create tensionDon't assume that double the people equals half the timeDoDo scale horizontally by creating more teams of about 5-8 peopleDo have a vision for the product and teamDo appreciate that every team is different, so allocate projects appropriatelyDo motivate your teams (Wow - that is one slippery, hard-to-define one. I agree with the sentiment, but it's like saying Be effective with no guidelines. -Todd)Do allow people to move between teamsDo have sessions to discuss the product vision, strategy, technology and processDo involve the team when determining the team/product nameDo allow your teams to make their own decisions especially if they are the ones with the expertiseDo involve your team on any decision that impacts how or what they work onDo encourage a development methodology that matches the team and the projectDo pay attention to every individual's personal development plan
Does this list of management behaviors actually appeal to software developers?
management
My guess is this list actually appeals to software developers because it validates their self-image as pampered creative divas rather than hard-as-nails problem-solvers (a l Winston Wolf) and expect to be treated professionally as a result.I also suspect if we improved software development techniques to the point where our trade was certifiable like that of architects, lawyers, medical professionals and the like, we would be better able to direct how software developers are managed.