What are the best and worst policies you have seen used to run a programming team?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

Worst:

• 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)

Best:

• 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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.