1

I've just been put in charge of a software development team, and don't want to stuff it up. I'm interested to find out what are some of the things you valued most about the best managers you've worked for? And what are some of the things you hated the most about the worst managers you've worked for?

closed as too broad by Marv Mills, Todd A. Jacobs, Zsolt, jmort253 Mar 2 '16 at 10:45

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I'm voting to close this question as off-topic because it is not about Project Management. Your question may be more on-topic at Stack Overflow or Developers Stack Exchange sites. – Marv Mills Feb 29 '16 at 12:44
  • 1
    Open-ended, list-generating questions are off-topic. This question is really an opinion poll, and doesn't fit within the guidelines defined by our help center. If you can rewrite it to allow for a canonical answer, it may be reopened. – Todd A. Jacobs Feb 29 '16 at 17:54
  • StackOverflow is for code not for developers management. Programers is for designed, still not developpers management. The question fits here but is quite broad. Maybe this should be rephrased like : what's the principal point of software development management this could lead to point like explaining that a lot of code is not UI, what is a technical debt,.... – Walfrat Mar 4 '16 at 13:24
2

Do:

  • Give lots of credit where credit is due; a lot of code is under the hood and nobody really gets to see or use it directly
  • Become somewhat knowledgeable in the field
  • Give incentives (Employee of the month or outings or bonuses)
  • Find out what people are doing and why
  • Remember that programming is brain-work; someone staring out the window or pacing around may be doing more work than the person bashing away at the keyboard
  • Get access to the bug base and version control system so you can see work happening in real time, understand the throughput rate of the team and get a feel for the status
  • Read the specification documents and become an early user of the software so that you can make knowledgeable decisions about future feature request and reported bugs

Don't:

  • Don't give advice on things you don't know much about
  • Don't try to get people to work harder or longer hours
  • Don't accuse people of not working on their project; rather find out what they were doing instead (usually helping other people with their coding issues)
  • Beware of refusing to purchase software/hardware that they request; unless you really understand why they don't need it
  • Don't argue about schedules and deadlines; it's not usually possible to code faster - unless you want poor quality code. (And if you don't understand that, then review to Become somewhat knowledgeable in the field)
  • 2
    I'll complete the last point : if you're not technical, don't argue about technical point. However if a task is said by your developer to be too long to fit, you can ask to them if there is a way to answer your need in another way that will still fit be be cheaper – Walfrat Mar 4 '16 at 13:19

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