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't scale teams vertically by adding more people

  • Don't create a team with more that 10 people

  • Don't call people resources, its not cool and is really offensive

  • Don't assume that people in teams are interchangeable

  • Don't compare teams to each other when highlighting weaknesses

  • Don't pitch teams against each other

  • Don't create fake deadlines

  • Don'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 development

  • Don'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 tension

  • Don't assume that double the people equals half the time


  • Do scale horizontally by creating more teams of about 5-8 people

  • Do have a vision for the product and team

  • Do appreciate that every team is different, so allocate projects appropriately

  • Do 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 teams

  • Do have sessions to discuss the product vision, strategy, technology and process

  • Do involve the team when determining the team/product name

  • Do allow your teams to make their own decisions especially if they are the ones with the expertise

  • Do involve your team on any decision that impacts how or what they work on

  • Do encourage a development methodology that matches the team and the project

  • Do pay attention to every individual's personal development plan

  • 4
    The one I really have an issue with is involving the team with the product name. This is a subject on which everyone has an opinion but there are actually people in marketing (or at least in decent marketing departments) who know more about this than just having an opinion. If you want to have your skills respected you should also respect the skills of others. – Jon Hopkins Nov 8 '10 at 14:18
  • This is an awesome list! What science fiction novel is this from? – Rob Jul 21 '14 at 21:34

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.

| improve this answer | |
  • 1
    There seems to be a dichotomy between the perception of developers that they have of themselves versus the managers. I think that in both cases you need to look at the developers as individuals and recognize the individual differences more than you need to make sweeping generalizations about a group. I think you're right about improved techniques but I don't think that you will ever see an across the board certification that is universally accepted. The ones that are out there are vendor-based or are focused on a particular kind of development. – Todd Williamson Oct 15 '10 at 18:48
  • 3
    Stereotypes, or sweeping generalities, are part of our thought processes. This is why stereotyping systems such as job titles and certification programs (such as college degrees) are in use. But certification of an industry isn't to manage differences between individuals, but the process to produce particular products. – Huperniketes Oct 15 '10 at 18:57
  • I suspect that if it were possible to improve software development techniques to the point where our craft was certifiable (e.g. a "known ideal" set of rules), then it'd also be possible to write software that develops software (using the same "known ideal" set of rules) and our craft would become worthless. – Brendan Dec 22 '16 at 6:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.