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.

19

:joke: I would fire the best developer in order to show the remaining 24 that no one is safe :/joke:
–
TonyOct 26 '10 at 11:53

21 Answers
21

Awesome computers to develop on. At least double the power of the target user, with plenty of RAM and large/multiple monitors... ~$3 to 5k budget.

Nice headphones for whoever needs them, when they prefer to work to music.

Excellent development tools to work with. This depends somewhat on your target environment, but Visual Studio / Eclipse / whatever is the best for the job. This includes things like continuous integration/build servers.

Very few meetings - only what is absolutely necessary and a hard limit on their length (we use a timer); think 'stand-up meeting' like Scrum.

Healthy atmosphere in which to work. Daylight, fresh air options, stable aircon, plants, pictures, good lighting.

10 to 20% downtime to learn something new or flex your skills a little.

A water cooler for each group of desks that is regularly maintained.

Market-competitive salaries with performance-related bonuses, where performance and the remuneration are clearly defined. Performance bonuses would likely be company profit share.

Encourage a collaborative work ethic; have tech debriefs to share learning, rotate people around teams to build their experience.

Free drinks (non-alcoholic).

A fruit basket for healthy snacks that don't ruin lunch.

Establish a level of professional respect from the other parts of the business for the software development department and vice versa. This is a long-term, fuzzy target, but there are ways and means of establishing it.

Clear communication to and from management of expectations and delivery on those expectations.

Clear priorities for work items, reviewed regularly.

Use of best practices in terms of SDLC methodologies - Agile/Scrum, etc.

Clear and documented procedures on what has to be done, why and how for important stuff like release management. Whatever can be automated would be, so this is just the manual bits - there's always some.

Supportive environment for when things don't go so well. No kicking people when they cause bugs, but helping them learn from their mistakes.

24x7 access to the building and remote access for when team members get inspiration outside of normal hours.

Whiteboards for prototyping/thinking out loud.

Celebrations of success - whether a team lunch or a trip to the Grand Prix at the weekend, it's important to recognise great effort and great results.

I would not have:

Nerf guns/frisbees/pool table/toys. The work environment is where we work. There's lots of fun to be had while doing the job without playing soldiers around colleagues that are trying to focus.

Free food - people should take a break to go out and get something to eat.

Internet censorship - I'd leave it up to the individuals to exercise their judgement.

@aggietech: If you're going for an insanely great product produced by great developers, either they're going to be too into the project to spend much time on Facebook, or you've failed to motivate them. I'm not saying blocking sites at work is a bad thing in general, but it isn't suited for this situation.
–
David ThornleyOct 26 '10 at 16:25

1

@David, yes i agree with you, but again we're not working with exceptional products everyday - and not every single developers have the same standard (or for that matter self-control) ... i do believe blocking some sites are good
–
aggietechOct 26 '10 at 18:15

3

In particular, some people do better work with frequent short breaks, and how they spend those breaks should be up to them. As long as you're happy with their productivity, there's no need to micromanage.
–
Tim GoodmanOct 27 '10 at 0:42

1

I'd add to #18: remote access (SSH, etc), so they can work from home if they don't live close to the building, or don't feel like travelling there, but still want to do something in "unconventional" hours.
–
Alex BudovskiNov 23 '10 at 6:12

@Murph: you're bang on, "a willingness to listen to suggestions" is vital. Smart, creative people have no interest in working in an authoritarian, top-down environment.
–
Tom AndersonOct 26 '10 at 16:28

I like the part where he says, essentially, to pay your employees enough so that money is taken off the table as a consideration for why they want to work there. When money is no longer a motivating factor, you get a much better set of results.

I know what motivates me:

Being able to use the tools I prefer. So give your developers the tools they want and need. With a team of 25 people, obviously, you have to come to compromise and consensus, but the bottom line is they need the best tools. This encompasses hardware and software.

Normal work hours. 35-40 hours per work. Nothing more. If they want to come in on their own to do more because they're inspired, fine. But overworking people in jobs where they are required to flex their critical thinking muscles is the fast track to disaster.

Telecommute options. I like to work from the comfort of my own home; not have to deal with the headache of traffic and losing an hour a day to travel. I can be there for my family, for emergencies, as a taxi, etc. If you have employees who can handle it and get their workloads done, give them the telecommute option. Also, it is way easier to take a 20-30 minute power-nap at home (proven to increase productivity, but society still frowns on the nap).

A quality workspace. Whiteboards, collaborative tools, conference rooms, etc. A team of 25 employees can only really create something awesome if they're working together, and to work together they have to share ideas freely and collaborate. If they're working remotely, have Skype, etc. But give them the tools to be collaborative.

Clearly defined goals. Not deadlines - those are different. Goals. Implement this however you want - Scrum, XP, I don't care - but your team needs clear goals and milestones.

Don't get locked into one particular dogma; be open to change and new ideas, new technologies, etc. Listen to each other. Don't force architecture on your team; let it evolve through collaboration, feedback, input.

Developers want to make awesome software. If you can give them the opportunity to do that, compensate them well enough that money doesn't factor into their thought processes, and provide them with a healthy work/life balance, they'll produce.

Assuming that the 25 developers will be working on different aspects of the application, split them into sub-teams and nominate 1 member of each team to be the team leader. (NOTE: This role should move around as the project develops and the teams get reshuffled).

Now you have 5 team leads to motivate and they in turn have 4 developers to motivate.

You can concentrate on the "global" motivators (like stock options etc.) while your team leads can concentrate on the individual motivators (being allowed to leave early on a Wednesday).

Make sure you are consistent and the team leads communicate their actions with you and each other to avoid unnecessary frictions.

I'm ready to be voted down, but you can motivate me any way you want (make me work hard hours, give me a 386 for a machine on which to code, work on a shaking card table in the dark in a basement, yell at me, work weekends and holidays, and provide no free coffee) and I will be your crack team as long as you pay me a ridiculous amount of money.

Why, this is what most people want right ?
–
user2567Oct 26 '10 at 16:41

1

@SnOrfus, it may be a generational thing. Just me, but I work for $ and not for life satisfaction. I (and I suspect most folks if you really think about it) have and always will be solely motivated by $.
–
XepochOct 26 '10 at 17:56

1

I see your point. I'm not making any assumptions about your situation, but I've found in myself and my friends/coworkers that the times when I/we were most motivated by money, was when we didn't have any. My POV is that I'm never going to make it rich programming for someone else, so I might as well really enjoy it instead.
–
Steve EversOct 26 '10 at 19:01

I agree with Dima and ChrisF. Except on one of Dima's points: stock options.

I know that this is a regional thing, but in many countries, stock options are taxed by the state at their actual value (inner value) when assigned or issued. This unless you can proof that the volatility does not allow to calculate an inner value.

I once ended up paying in taxes for my stock options much more than what they were worth. They had a value of $40 each when issued, but I could not exercise them for a year, and by then they were down under a dollar.

But back to your question:

Individual working times, great tools, influence in decision making, an environment free of politics (keep it away from them, so they can work).

Fringe benefits like a budget to spend on their own on tools, books, courses.

NO cubicles, at most 3 people in an office with more than 9 m2 per person. If possible, move the team in its own building or at least on its own floor. Let them personalize their desk - no desk police.

Eliminate phones from their desks (email without sound or instant messaging, again without sound, and telephone booths outside the offices with chairs and small desks for their laptops, no interruption of workflow without urgency). Have a secretary to handle incoming phone calls.

As little meetings as possible. Don't do them on Mondays (Mondays aren't fun anyway, some are still in the weekend, some lose the last energy to start through) or on Fridays (what did I just say about weekends), but Wednesdays are perfect (this gives a nice break in mid week).

Administrative rights on their machines. No first and second level support.

I would not like to be forced to eat with the bunch - I know I am different - as I need a break from being with the same people all day. But a croissant break for informal information exchange, a monthly evening out with no peer pressure to participate every time and with spouses (bowling, dinner) would do it for me.

To second ChrisF: I don't think that anybody can handle 25 direct reports. Form teams. And from time to time organize a competition between them.

Edit: Upon reflection, here is the main point: treat employees like people, not like machines or "resources". Make sure they feel comfortable asking you questions or raising issues. Make sure that you can accommodate people when they have personal issues, like a sick child or parent. In other words, do your best to establish a rapport with them. Also, 25 is still a small enough group to celebrate everyone's birthday with a cake. These little things make a world of difference.

Definitely stock options, so that the success of the company would have a significant impact on their own quality of life. In addition to that, be open with them about what is going on in the business side of things. The point is to make employees see at least some of the big picture in addition to their immediate responsibilities, so that they feel more like partners in the company, and less like cogs in a machine.

Good working conditions. Comfortable chairs, fast machines, large monitors, keyboards and mice they are most comfortable with. A window is nice... Good air flow. Buy them books on programming if they want to improve their skills.

Also, having a meal together regularly, like once a week, preferably with beer, is great for morale. 25 people may be a bit too many for that, though. So maybe individual teams should have pizza and beer together once a week. Payed for by the company, of course. :)

Stock Options only motivates people if the company is publicly listed and/or profitable. 2% stock of no profit is worthless.
–
JBRWilkinsonOct 26 '10 at 12:39

1

25 people will mean cake twice a month, you will get a fat team when you project is over. :) Also, there's an above 50% chance of two people having birthday on the same day.
–
Bjarke Freund-HansenNov 17 '10 at 6:41

I manage a team of six programmers, so I give this topic a bit of thought. Here are my ideas -

Give them time to work - Interruptions kill productivity and motivation. Programmers like it best when they can get their heads down and get on with the work. You also need to give them time to do a job well - programmers hate rushing to get something finished by an arbitary deadline. I usually ask my programmers how long a task will take, and then respect their estimate. Part of my job as team leader is to manage that off with the business, and help them develop realistic expectations.

Give them good equipment - It is terrible having to program on slow computers, and most programmers hate using old development tools as well. Make sure your programmers have really good equipment - fast computers, latest tools, big screens, and also a very good chair. These things are not all that expensive in the grand scheme.

Give them respect - Programmers strongly desire respect for their technical skills. Honour the work that they have already done, and the work they are doing. Respect their opinions on technical matters. When you ask a technical question, take the answer at face value. If they have made a mistake, find a way to bring this up without them losing face. You can say things like, "I followed what you suggested, but I came across this issue. What do you think I should do?"

Give them permission to go home - Working long hours soon becomes counter-productive. When programmers know they can go home at 5pm, they are much more likely to come back the next day feeling motivated to work.

Give them responsibility - Programmers like making technical decisions, so give them the space to develop things the way they think best. If you have architectural or design standards, make sure these are understood up front. If problems come out during a design review, make sure these are communicated in a respectful and encouraging way.

Give them support - Make it easy for them to come and ask for help if they need it. Say, "if you've got any questions, don't hesitate to ask." Don't make them feel bad for not knowing some technology, instead say, "If you need a couple of hours to brush up on that tech, go ahead."

I'm going to take a different tack here than the other answers: try as hard as you can to not demotivate your employees. You can give your employees all of the coffee, snacks, computers, etc. that they want and still not have motivated employees if you engage in many common (bad) management practices which may seem very reasonable to you as a manager, but which are pathological to employee motivation. For examples of these bad practices, you can invert many of the suggestions in the other answers:

"treat employees like people, not like machines or 'resources'" --> treat employees like faceless interchangeable resources or "FTEs."

"Give them a reason to make quality products" --> insist on quick and dirty development (since the customer is willing to live with bugs)

My point is, creating an environment that movitates employees takes a lot more than a checklist of affirmative actions*. You have to monitor every aspect of your actions as a manager to make sure you're not contradicting this goal.

Peopleware: Productive Projects and Teams is a book that I think is very relevant to programmer motivation. It has many chapters about management practices that demotivate employees (and thus prevent effective teams). One of my favorite chapters is "Teamicide," which posits that there isn't anything a manager can do to create an effective team, but a lot he can do to destroy one or keep one from forming.

* In fact, some affirmative "motivational" actions can have a de-motivational effect if there are other de-motivational factors present.

IMO, stock options in startups are a bit of a scam. It typically goes like this:

1) A team of bright energetic young developers is recruited with promises of getting rich through stock options.

2) The startup runs through its initial capital and second round of VC funding is injected. The options are diluted to 1/2, 1/4 of there initial paper value.

3) This is repeated once, twice, ...

Eventually the startup folds and the developers' options are totally worthless. Alternatively, they are so diluted that the developers' return is tiny.

I think that you should be paying your developers a decent salary in real money. Whether this motivates them depends on their personalities. But at least they will be getting a fair return for their labor ... not some flim-flam.

You want to find out about the personalities of the people.
According to recent leadership theories, it is important that you are authentic and share common behavior and goals with your team members. Leadership can also be seen as coaching your team members to achieve their goals (here would be some theory)

Perhaps a good place to start would be to let them KNOW that they will do so, in a way so they can see the long term perspective on this. Such a goal should be highly motivating on its own - IF it really is a killer app.