Recently I read the following 5 Types Of Bosses and How To Deal With Them, which describes the attires of the worst boss. I've just started leading a small team of software developers.I would like to know what are the main things a programmer expects from the senior programmer or what are the things we should avoid while managing a team. Also, I would like to know how to keep the programmers satisfied and create a productive & completeness environment for my team.
What are the main things a programmer expects from the senior programmer?
management;team;team leader;team building
Things that seem to work well for me:Give meaningful work and encourage ownership - even when a problem arises, don't solve it, talk through it and give the person insights so they can solve it themselves.edit - addition - this was also meant to include - stay the heck out of details.  Assume your people know enough to do the assignment without micromanagement or the requirement to constantly check in.  Build a set of guidelines for when they should check in - which should only be when the work is either done or so truly messed up that serious intervention is needed.  If possible, stay away from even needing to be in the loop on interteam support issues.Be honest - that has several corollaries:Be honest about yourself - I won't have time until Tuesday, I've never done that, here's my best guess, etc.Be honest about the team and where they fit in the company - if you know something about the business stuff, tell them if you can, and tell them what you know as the straight facts.Be honest in giving feedback - don't mince words or soft pedal if you have give negative feedback.  That's different from brutally honest - you can still have compassion, but if something's wrong, say so.Be honest when you know the work is more about redtape than getting something meaningful done.  Into everyone's life, some meaningless work will fall.  Don't pretend it's meaningful.  Call it like is, so you can all focus on getting past it and getting on to something useful.Listen.  At least 50% of your job is listening, maybe more.  You have suddently become responsible not just for the technical work, but the people doing it.  You have to listen to learn not just about the problems the team is having, but also how your people approach the problem and what the team's shortcomings as a group are.Important corollary - listening can directly lead to point #1 - giving meaningful work - engineers are great at coming up with ways to make development easier.  You can't approve everything, but where the idea is good, give the engineer the assignment, and they have essentially done you work for you - they created the meaningful work and told you just what it is.Say thank you.  I know, it seems obvious.  While we all love money, better tools, a nicer work environment and promotions - the way to get to these things is by a series of good efforts, each of which deserves a thank you.  Thank you is totally free, you'll never run out of them, and knowing that your manager has seen and appreciated your hard work is definitely motivating.Spend time on the big picture, even if it means sacrificing some portion of the day to day work that got you the position.  It's probably true that you can code better than some of your people, but if you don't spend a decent set of time on the big picture - the team, the overall project direction, the state of your codebase, the efficiency of your processes, your team's environment - then you won't be doing the job they need you to do.Learn to be a buffer for your team.  Engineering teams work best when they have the time to do ... engineering.  Corporate bureaucracy is not engineering.  Anything you can do to take the annoying 1 per year/month/week meetings with external people is better.  NOTE:  That doesn't mean agile meetings with stake holders - that's engineering, your team needs to be there for that.  I mean the meeting with facilities who wants to put a loud shrieking piece of machinery near your team, or the process group that wants your team to fill out papers in triplicate before any code gets checked in.  You are the flak absorption system.Assume problem people are not evil, they are people who want to do good but haven't figured out how yet.  You're not going to be able to fix everyone, but often the first few complete screw ups are as much a factor of failed communication as they are incompetence or deliberate malice.  If you start with the assumption that people are not evil, you have a decent hope of avoiding a number of the evil boss archetypes of the list above.And probably most important... respect.  If you honestly can't respect the members of you team, you have to work on changing that (whether that's teaching people or changing your headcount).  Give respect day one and you will get it back, treat people with a lack of respect and you will never get respect in return.Taken together, if you do most of these things, most of the time then your team will give you the benefit of the doubt when you show you are human and totally screw something up yourself. :)  Every boss has their own drawbacks, and it's as much about working out a relationship with your team where they can help you compensate for your weaknesses as you help them with theirs.