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.

If I were to begin managing a team of programmers (which I'm not, I'm just asking out of curiosity) what are some of the office / team policies you have seen that are either particularly conducive or particularly prohibitive to productivity and teamwork? Some of the well known bad ones include regular overtime, micromanagement, not having admin rights, very strict hours, and endless meeting requirements. What else is there to avoid, and what interesting policies have you seen that do wonders for a team?

share|improve this question

put on hold as too broad by gnat, durron597, Kilian Foth, GlenH7, Dan Pichelman Apr 15 at 21:19

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

I have seen that small rewards and recognition usually boost programmer's morale. Try to develop a software culture in your team. The rewards could be as little was a certificate that can be proudly displayed on the team-member's mantle. –  abhi Mar 1 '11 at 23:48
You might want to ask this question on the project management stack exchange, too. –  blueberryfields Mar 1 '11 at 23:59
@Abhi: there is a lot of scientific evidence that finds the opposite to be true: amazon.com/gp/aw/d.html/ref=redir_mdp_mobile/… –  whatsisname Mar 2 '11 at 0:10
@whatsisname Interesting book. I may read it some day. I am speaking from my own experience. –  abhi Mar 2 '11 at 0:16
@whatsisname, joel also has a good article on it joelonsoftware.com/articles/fog0000000070.html –  CaffGeek Mar 2 '11 at 16:51

7 Answers 7

Show your staff that you value their time. Give them a quiet place to work. Make sure they have the resources to be maximally effective. Replace their workstations every two years -- if you save ten minutes a day you will break even in four months. If they want another monitor, or a larger one, buy it. If they want a book, order it. If they want to work from home, and are productive, accept it.

If you do these things, you will be able to hire and retain the best.

share|improve this answer
aww this sounds awesome. –  sevenseacat Mar 2 '11 at 1:43
Pipe dreams! Pipe dreams! –  Sergio Mar 2 '11 at 1:47
Sounds like Joel talking. –  Erin Mar 2 '11 at 3:12
Can I work for you? :) –  System Down Mar 2 '11 at 20:01

Here are but a few...

  • Having no sense of direction, control, or leadership.
  • Being unable to manage risk and defend your developers.
  • Telling your developers "everything" is a priority.
  • Allowing non-technical people to poison the direction of the team.
  • Allowing crazy people/poisonous personalities to stay on the team.
  • Being a "yes man" to other departments.
share|improve this answer


  • Ties required
  • No internet access (it distracts you from the task at hand)
  • No "socializing" (hard to tell when you're socializing versus discussing a code issue)
  • Half hour lunch
  • A litter box in the bullpen (aargh, cat lovers)
  • Pat-down on entrance and exit (high security contract)
  • Priorities determined by who yells the loudest
  • Active social media tracking (keep your shirt on or you're fired)


  • Beer trolley at 4:00PM on Friday
  • Strip-o-gram birthdays
  • Over 60 hours in a week wins you a massage
  • Weekly off-topic tech show-and-tell (share your free-time projects and interests)
  • Internal start ups - Have a great idea? Launch it from inside the company.
  • On-site shower for an afternoon run
  • On-site, healthy, gourmet food
  • Bidet/toilet combo
share|improve this answer
I rather like the show-and-tell thing. –  Maxpm Apr 29 '11 at 6:11

Specifically, asking testers to file lots of bugs. Then asking the test team to stay late and work (file more bugs presumably and test recent changes) while the developers stay late fixing the bugs. More generally, asking people to work hard, then asking them to work longer and do additional work that will only result in more late nights.

Also lack of clarity. For me a pet peeve is the idea I have the ability to read minds. I wish I did but I don't. So if there is something that needs building I need very clear requirements. Otherwise, I need full control to build something without the risk of being punished if it's not what management expected.

share|improve this answer
+1 for emphasizing requirements clarity. –  Jas Mar 2 '11 at 6:56

The policies that work depend directly on the team, the office and the type of work required. Here are some examples:

If you're looking at a team of programmers where the division of work is 80% creative, original, research type work, and compensation is commensurate with published papers, flexible hours, full access to all hardware and employment arrangements that allow working from home might be appropriate.

If you're speaking about an office performing mostly outsourced spec work, where payment is based on lines of code written with penalties for bugs, you'll want a set of policies that match (for example, fixed working hours, low wages with expected overtime, bonuses for code which doesn't fail client tests).

If the software is new, and the field is young, with programmers spending their time writing mostly new code or solving novel issues, you might want a startup feel and motivation.

If the software is old, the field well mapped out, and most of the work is fixing bugs or directly driven by support/maintenance contracts, fixed working hours and limited access to the codebase make sense.

share|improve this answer

I would say to thank you team. This is best when coming form the business owners and the execs of the company not just the manager of the dev team. I would also say rewards work. I personally don't think they should be carrots to get the team to work, but more like gifts for a job well done when a developer or a team of developers really bust out a product.

share|improve this answer

No documentation of anything. Not using source control No documented coding style No project planning system Lots of useless meetings that get nothing done or resolved.

share|improve this answer

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