Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
19  
joelonsoftware.com Read as much of his blog as you have time for. –  P.Brian.Mackey Apr 20 '11 at 13:33
    
@P.Brian.Mackey awesome link! –  Avatar Apr 20 '11 at 13:40
2  
That the senior programmer has a Miyazaki-related avatar is perhaps not a must, but surely a big plus :-) –  leonbloy Apr 20 '11 at 15:46
1  
Interesting... My boss scored a 4 out of 5 on that test... I should alert him of the good news ;) –  Aeo Apr 20 '11 at 15:57
1  
related: programmers.stackexchange.com/questions/27164/… –  Machado Apr 20 '11 at 15:59
show 1 more comment

8 Answers

up vote 76 down vote accepted

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.

share|improve this answer
    
@bethlakshmi great details. Thank you. –  Avatar Apr 20 '11 at 15:56
1  
great answer, I would add to this give them freedom. Nothing worse than being micromanaged or having to ask permission for every little detail. –  shiznit123 Apr 20 '11 at 16:23
3  
Truly Awesome.. I wish StackExchange could provide support for following users (a short note to Joel and Jeff) :) –  PrinceCoder Apr 20 '11 at 16:33
2  
WAAOW !! ... that was one of the best answers I have ever come across @Stackexchange –  explorest Apr 20 '11 at 19:06
2  
@PrinceCoder every user has its own feed, you can follow that in some RSS reader. –  svick Apr 22 '11 at 8:42
show 4 more comments

Well, one of the biggest things to learn is that very often you won't be able to keep them happy as you simply won't have the ability to give them what they want.

The best managers I've worked for I've found have been the most honest guys, who will defend their team from all the crap that upper management try to throw at them, and that above all LISTEN to their team.

share|improve this answer
2  
There's a big difference between a manager and a senior programmer. I've yet to meet a manager like you describe. Please tell me where I can find them ;-) –  fretje Apr 20 '11 at 15:37
    
Fair enough that's what the title says, but the question goes on to talk about bosses. I've had plenty of good managers/dev leads in my career. –  Ozz Apr 20 '11 at 18:39
    
+1 @James someone has edited the title it seems. By questions stands about the leads/managers. The word "boss" looks fierce, so I choose the word senior programmer. –  Avatar Apr 20 '11 at 19:04
add comment

I firmly believe one of the most critical parts of being senior or lead is availibility to the junior people. Seniors and leads often have tasks that only they have the rights to do (we don't give juniors write rights to staging and prod for instance). Plus a significant part of your job is to mentor the junior people which means answering questions not ignoring them. The more senior you are the more likely it is that you will be interrupted by others who need something from you. You need to give up that "do not disturb" sign and learn to work with interruptions.

Listening is important.

Please and thank you are important and cost nothing.

Don't expect more than you are willing to give. If you want me to work til 3 am, you had better be there beside me working too. Nothing is more discouraging than working for someone who leaves on time every day immediately after giving you a task that needs to be done by 7 am.

Be fair. Don't play favorites (especially don't play favorites by giving your girlfriend or boyfriend the best stuff). Treat all employees with respect (even people you personally don't like).

Be decisive. Don't leave decisions hanging out so that no one can progress or worse change them every five minutes.

Stand up for your people. You won't win them all but people will walk through fire for someone who supports them up the chain.

Be willing to be the bad guy when necessary. One bad apple can destroy a dev team, don't hold on to that person because you don't want to confront their bad behavior (this applies more for leads and offcial supervisors). When you have bad news, tell the team, don't keep it a secret (they will find out eventually and then they are mad about both the bad news and the secret keeping). You are not there to be popular but to get the job done. Anyone in a management or quasi-managment position has to be willing to be unpopular.

Learn how to sell ideas to higher ups and teach these skills to your devs.

Understand the importance of the business domain and become expert on it as well as programming.

share|improve this answer
add comment

The keywords here are trust and responsibility.

You'll just have to trust that your team members are competent and focused on completing their tasks. By not meddling too much, you are essentially letting them "own" responsibility for their work.

IMHO, this alone does wonders in creating a healthy atmosphere.

share|improve this answer
2  
Provided they are decently competent and motivated. If the team is inherited as is, this is unfortunately not a given. If you selected the members yourself, it is of course a different story. –  Péter Török Apr 20 '11 at 14:05
1  
Well, in my opinion, even those that are not too competent, when given a full responsibility, a.k.a. "ownership" over a part of the project will do -everything- it takes to get their piece done. I don't even care if a part of the code is collected by asking questions on forums and boards, as long as the job gets done. –  Jas Apr 20 '11 at 16:03
    
unfortunately I have met counterexamples :-( In the worst case I have seen, a developer produced absolutely nothing when he was given freedom and full responsibility for about two months - as it turned out, he wasn't even coming in to the workplace. Some people are just not pulling their weight in a team, and if you let them run freely without close scrutiny, you just make things worse. If you don't get rid of these people in time, they can damage the whole team. –  Péter Török Apr 21 '11 at 8:27
    
@Péter Török - sure, everyone knows a few such people at every company (actually reading this I thought you know the same guy as me:). But from my experience, most people do focus and try to do their best. –  Jas Apr 21 '11 at 8:33
    
I agree, most people try to do their best. (Or shall I say everyone tries to do his/her best - just for some, "best" doesn't hit the threshold of noticeability? :-) One should still be alert to notice the exceptions in time - because there are exceptions. Just as in production code, we must handle the error cases correctly, even though they are rare under normal circumstances. –  Péter Török Apr 21 '11 at 8:52
add comment

Well IMO I expect the senior developer/lead/whatever to side with the development team against things like idiotic deadlines, no resources but expected to build Rome, mandated overtime, etc. all of the things that reduce productivity and make people unhappy.

The main thing IMO to avoid is being a "yes-man" to upper management and always agreeing no matter what they say (an ass-kisser, in other words)

share|improve this answer
    
+1: Right. And if you find yourself reporting to a 'Yes-Man', leave ASAP. –  Jim G. May 4 '11 at 16:46
1  
Sadly, there are many environments where the senior/lead/manager programmer is nothing but a Yes-Man (or as I prefer to call them, "Smithers"), and the worst part is most of the time you won't know it until after you take the job. –  Wayne M May 4 '11 at 17:40
add comment

People Skills. Sometimes people are given the title "Senior" and they forget they aren't omniscient. They feel the promotion is commentary on their supreme technical skills and latent genius. In reality they are super low level managers now. They should understand how and who to motivate, who to let be, how to compromise, and when to listen.

Ownership. The worst Senior programmers don't take ownership of what they were "senior" on. They fall back on the tactics of work-dodgery and blame gaming that led to their promotion(more than likely while dancing on the grave of the person they tossed under the bus). Now they need to understand its their butt in the sling and that its their responsibility to own the design, the plan, and a large share of the work.

Experience. I expect senior developers to have seen everything twice. They should understand the domain and the technology. They should aggressively attack risks and be able to spot time wasting red herrings.

share|improve this answer
add comment

Consistency is one of the most important things. If developers can predict how you will act they will be happier. Even if you are constantly a total tool it is better then sometimes being cool and some times being a tool. That being said don't be a tool.

share|improve this answer
add comment

Knowledge and communication. Knowing the source and much, much, more importantly being able to explain it to anyone, in a way that they will understand and retain.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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