views:

215

answers:

8

I recently got promoted to be the Project Manager/Supervisor. What do you think the leadership style a managerial role in Programming Dev't should have?

What's your style?

+5  A: 

Hands-off, servant leadership, unofficial or "tribal" leadership over traditional management, seem to be all the rage these days.

Basically getting out of the way and allowing the team to get their job done seems to make sense to me, but it all depends on the culture.

I would say an effective manager would already have a style, and know how he wants to work, whereas a less effective manager would probably learn from other senior managers and simply emulate "however things get done around here". Actually in a lot of places the latter is the only choice.

If you have the freedom to do things the way you want, I would probably prefer to borrow ideas from the agile/lean camp than the more traditional PMI/Prince2/PMBOK camp, but it all depends really.

Kurt
I agree with being hands off.. but it doesn't work for all subordinates. It really depends on the quality of the team you have. Culture is one thing, but knowing that your devs are independent and don't need hand holding is another. Most teams are often a mix of these and you need to identify who fits which group.
SB
not stopping the devs working yourself is the easy part, preventing numerous other people/things from distracting them is the real key imho
jk
Yes, hands off. I am a developer and I hate when managers come to me all the time asking me if I cant do this, cant do that, and then at the end it must go back to the way it was!
Etienne
Sorry but the worst crap I've ever seen was built with this type of management. It is a managers job to direct and decide not to get out of the way.
HLGEM
+1  A: 

There are plenty of methods with catchy names, but in general I prefer the management style to be lightweight and encourage communication.

I suspect a lot of us have had the experience of having to spend more time filling out forms than actually developing. Than is both frustrating and unnecessary. Controls are important, but a new form is not the solution to every managerial problem.

As far as communication goes, many managers seem to believe that it will work if everyone reports up to them and then they send the collected information back down. That can really lead to disaster. The team needs to communicate with each other well and often.

Finally, I'd like to throw in that as tempting as it is to take a new resource for a project and get them developing as quick as possible, I think it will always work out better in the long run to hold off and get them properly trained and oriented to the project.

wshato
+2  A: 

The job of a manager is to get out of the way and let the developers do their jobs. If they encounter an obstacle it is your task to remove the obstacle.

Bryan Oakley
+1  A: 

My style is a combination of Attilla the Hun, Napoleon Bonaparte and Nelson Mandela. Whatever you do, don't try to adopt my style.

More seriously, to be a good leader you have to develop your own style and you have to integrate that into the culture of the organisation you work in. So, the answer to your question must start with asking yourself some penetrating questions and giving honest answers to them. You must also take some time to understand the traits of the individuals in your team and figure out what makes them tick and how to motivate them as individuals. What works with one may not work with another.

And, while I'm writing, I'll direct a passing kick at the respondents who suggest that it is a manager's job to get out of the way and let the team work: it's the manager's job to manage, you have people you work for who have certain expectations of you and you have to pay attention to them as well as to the losers on your team.

I write 'losers' because you have just been promoted and they haven't. Sure, you have to lead them to great achievement but you won't do that by keeping out of their way, you'll do it by leading them in the right direction, with the right mix of carrot and stick. Oh, and don't let them know that you think they are losers, it will upset them.

High Performance Mark
+1  A: 

First of all; if you try to adopt a "style" that's not your own, you will most likely fail. You basically just have to be yourself! (That's probably why you got promoted in the first place) That said, there are some theorems to embrace, one beeing "you can always be a better leader" ;) I guess that's part of why you posted this question. My advise is to support your co-workers, and remember that it's your job to make them as good as possible. Try to keep yourself on top of all that happens within the project and encourage communication within the team. Agile style development helps with that. Also, try to put yourself in your co-workers shoes and try to imagine what they expect and want from you. Best of luck

sindre j
+2  A: 

I do not believe to simple management guidelines. In an ideal world, the job of a software manager would be to just provide food, computers, electricity and salaries, but we are hardly in an ideal world.

In a way, being a manager is a highway to frustration. There are few opportunities for a direct contribution to the project, you spend most of the time on planning, meetings, writing reports, and proposing future projects. In a nutshell, you have the responsibilities, while they have the joy of building things. In order to avoid quitting the job due to lack of fun, one needs to find a proper motivation which would justify the troubles.

Now, different people are motivated by different things. Some people like to participate in group efforts, some like the achievement in building things which can't be built by a lone enterpreneur, some like the power, some like the money. I think that a management style should be tailored to the intrinsic motivations of all of the involved parties. For example, it is useless to try to motivate your coworkers with money if they are primarily interested in building cool things (and vice versa).

A key competence in managing people is being able to address conflicts as early as possible. The conflicts range from trivial (X keeps committing buggy code to the repository) to critical (we need to hurry up in order to hit a deadline). I think it is very important to be able to express such concerns frankly and clearly, regardless of the managements style. Thus, at the end of day, oral communication capacities would be at least equally important as the management style.

ssegvic
I don't think you have been to real/professional/true programming environment.. "In an ideal world, the job of a software manager would be to just provide food, computers, electricity and salaries, but we are hardly in an ideal world." - Seriously??
ZiG
I am sorry that you did not like my style. Nevertheless, what I've written comes from my own experience and from experience of my more experienced friends and colleagues. Wish you luck in management.
ssegvic
A: 

There is no one "style" that you can or indeed should focus on. The reality is that you are now a people manager and people are all different. You need to learn to recognize the differences in the people you are managing and respond accordingly. This is a technical role, so if you have some technical understanding then this will assist with gaining respect of the team.

Some people need to be told what/how, some people need a gentle prod and some need full ownership of a task. Learning to spot the differences is where you need to apply yourself.

Typically people fall into 4 distinct camps with different names depending on the management course of the day :)

  • Beginner, highly motivated, not much experience, needs a more directive approach
  • Learner, more capable, but may be experiencing frustration, needs coaching
  • Performer, very capable but may lack confidence, needs supporting in their approach
  • Achiever, capable and committed, needs delegation of tasks
Craig McGuff
+2  A: 

I dont think it matters alot what style you choose. When leadership is "broken" it usualy is due to more basic things not done right.

  • Consistency: stick to your style unless you are sure it doesnt work out.
  • Honesty: Might seem obvious but when "fooling arround" too much with carrot and stick it can get out of control
  • Respect: Tech-Guys have all different characters but grasping what they value is easy - being passionate about technology and using it in professional way will open hearts. Waveing about your iphone showing off fancy looking but technologicaly trivial apps might result in the opposite ;)
  • Lead by example: You techs do extra hours? You do extra hours too!
  • Motivation: You dont need a jungle camp every 3 weeks but you can still help everyone to feel better about seeing each other more often than the family. Implement a friday afternoon beer-session if that is acceptable (be strickt about times though, no drinking before 6pm for exmaple). Show interest in what people are working on even if you are not part of operations. When working on abstract subjects people can have a hard time to put into relation what value they add to the company and to the team. When "in the jum" programmers particularily can become like lone astronauts - Having a broader understanding about your business you will need to remind people about the mission (though thats PM tasks mostly, but no PM is perfect too)).

In the end you are good leader when your team says "WE did it!"

Christoph Strasen