Imagine yourself hired by a new startup backed with few millions coming from venture capitalists.

Your mission: organize the development of the next killer app.

25 developers is too much to take care of each individually, so what decision(s) you would make to motivate them?

I will appreciate any answers from stock options to free cookies ;)

Of course the trick here (unless you are really a manager of a such startup), is put yourself in the shoes of one of those programmers.

EDIT: it's an imaginary context. The purpose of this story is to stimulate your wishes. I want to capture what motivates developers.

  • 19
    :joke: I would fire the best developer in order to show the remaining 24 that no one is safe :/joke:
    – Tony
    Commented Oct 26, 2010 at 11:53
  • 2
    I will appreciate stock options or cookies for free answers :-)
    – Stephen C
    Commented Oct 26, 2010 at 12:21
  • 1
    with beer and cookies
    – Muad'Dib
    Commented Oct 26, 2010 at 15:21
  • I'm not sure I would want to debug any CDIs(Coding While Intoxicated)... That would not be pretty.
    – Adamizer
    Commented Oct 26, 2010 at 16:10
  • I get motivated by Beer and Steak.
    – Phill
    Commented Feb 24, 2011 at 23:31

21 Answers 21


Here's my checklist, in no particular order:

  1. 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.
  2. Nice headphones for whoever needs them, when they prefer to work to music.
  3. 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.
  4. Fast internet access - perhaps with a caching proxy server to pre-cache things like SO, TheRegister, Reddit, etc
  5. 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.
  6. Healthy atmosphere in which to work. Daylight, fresh air options, stable aircon, plants, pictures, good lighting.
  7. 10 to 20% downtime to learn something new or flex your skills a little.
  8. A water cooler for each group of desks that is regularly maintained.
  9. Market-competitive salaries with performance-related bonuses, where performance and the remuneration are clearly defined. Performance bonuses would likely be company profit share.
  10. Encourage a collaborative work ethic; have tech debriefs to share learning, rotate people around teams to build their experience.
  11. Free drinks (non-alcoholic).
  12. A fruit basket for healthy snacks that don't ruin lunch.
  13. 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.
  14. Clear communication to and from management of expectations and delivery on those expectations.
  15. Clear priorities for work items, reviewed regularly.
  16. Use of best practices in terms of SDLC methodologies - Agile/Scrum, etc.
  17. 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.
  18. Supportive environment for when things don't go so well. No kicking people when they cause bugs, but helping them learn from their mistakes.
  19. 24x7 access to the building and remote access for when team members get inspiration outside of normal hours.
  20. Whiteboards for prototyping/thinking out loud.
  21. 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.
  • 1
    True - there is a lot of ongoing discussion about it on this site: programmers.stackexchange.com/search?q=social+networks Commented Oct 26, 2010 at 14:29
  • 4
    @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. Commented Oct 26, 2010 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
    – aggietech
    Commented Oct 26, 2010 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. Commented Oct 27, 2010 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. Commented Nov 23, 2010 at 6:12

Give them interesting problems to work on, and their choice of tools to work on them, then get out of their way.

Great programmers are not motivated by money, or by status within a company. They need enough money and status to be comfortable, but that's it. Great programmers are motivated by interest.

Paul Graham agrees with me.

  • 3
    Paul Graham's agreement doesn't necessarily mean much to many people - but fortunately he's not the only one to share this view; Joel Spolsky and a lot of other developers do too. Commented Oct 26, 2010 at 13:13
  • Yes - with the qualification that "choice of tools" may in fact be "input into the choice of tools". But interesting problems, decent environs and a willingness to listen to suggestions
    – Murph
    Commented Oct 26, 2010 at 13:38
  • There is only one reason that I have left any job - BOREDOM. You have to pay a decent programmer an absolute shedload to stay working on something that is not interesting.
    – uɐɪ
    Commented Oct 26, 2010 at 15:34
  • @Peter: ah, you got me! Indeed, this is one of the few things which Paul agrees with me about (and one of even fewer things Spolsky agrees with me about). Thanks for the link to the previous question - i'd tentatively suggest this question be closed as a duplicate of it. Commented Oct 26, 2010 at 15:41
  • 2
    @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. Commented Oct 26, 2010 at 16:28

There's a great YouTube video about the "Surprising Truth About What Motivates Us". I blogged this a while back:


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.

  • +100! 25 reports is the path to insanity! Commented Oct 26, 2010 at 12:47
  • Great comment, I like the Global, Individual motivators. People are motivated by thier own reasons and not your reasons.
    – Geek
    Commented Oct 26, 2010 at 16:51
  • +1! I would choose "delegate" as well. Nobody can effectively manage 25 people alone - split into teams and motivate leaders, that's a good choice! Commented Oct 26, 2010 at 18:44

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.

  • 1
    Why, this is what most people want right ?
    – user2567
    Commented Oct 26, 2010 at 16:41
  • Some studies (especially one I can think of recently) say that monetary compensation has diminishing returns for the vast majority of the population. (I believe the number where the returns being to noticeably diminish is $70K yearly with North America as the reference location). Commented Oct 26, 2010 at 17: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 $.
    – Jé Queue
    Commented Oct 26, 2010 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. Commented Oct 26, 2010 at 19:01
  • It is tough to follow $, and it is true that expectations are aways being reset. I think it is also however to compensate people given specific metrics: if the software brings in $1m in revenue (i.e.) then 15% of that is allocated to a bonus pool against which you're bonus will be paid. Unpopular, but that can put incentives to programmers to do it right (downtime=-$, bad UX=-$) vs. we programming prima donnas who think our way is the right and only way...well put $ against it and find out.
    – Jé Queue
    Commented Oct 26, 2010 at 19:19

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.

  • +1. Agree great environment rewards and motivates now (stock options are more "maybe jam in the future"). But I would want a phone -- that I can direct to voice mail. Too many times need a phone (e.g. doing support, talking to remote team member).
    – Richard
    Commented Oct 26, 2010 at 12:31
  • I don't know about to 'no monday meetings' rule. I'd prefer to have them then, because it would help me ease into the week. Mondays are hard to get started, but a planning session would definately get me pumped back up.
    – Michael K
    Commented Nov 10, 2010 at 17:20

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. :)

  • A meal together now and then is good. My company of 20-30 programmers goes for lunch at our local pub on fridays - not everyone goes, although everyone can; there were 17 of us last week. Some good food, a pint or two, a bit of a chat. It helps everyone get to know each other a bit better, and smooths off some of the rough corners of the week. Commented Oct 26, 2010 at 12:18
  • @Tom Anderson: This works as long as the other employees don't call black sheep on "that one bloke who never makes it round the pub Fridays with the rest of the office".
    – Jon Purdy
    Commented Oct 26, 2010 at 12:24
  • 1
    Stock Options only motivates people if the company is publicly listed and/or profitable. 2% stock of no profit is worthless. Commented Oct 26, 2010 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. Commented Nov 17, 2010 at 6:41
  • 1
    Oh my GOD don't call me a "resource".
    – Dan Ray
    Commented Feb 25, 2011 at 14:02

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."
  • "Pay above-market rates" --> your employees are costs, good managers minimize costs.
  • "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.

  1. Avoid the temptation to hire all 25 at once.
  2. Try to attract known top developers at the beginning.
  3. Once you have a small team of very talented people, who know what they are doing and have established a high-level of expectation.
  4. Keep adding more people. They need to know that they are surrounded by good people who are willing to help them, but they have to keep up.

The less-talented (I'm not saying they suck, but these things are relative.) people will be able to achieve if put in the right environment (good people), are trained well, and supervised.

It's much easier to manage people when you get the right people and build culture and attitudes instead of trying to establish a bunch of rules.

  • Also, have very talented people design your framework for whatever product you are making. Having a well designed framework vastly improves the quality of what less-talented people produces. Commented Nov 17, 2010 at 6:49

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.

  • I had a colleague once who liked collecting worthless stock options, although I really doubt he'd have been disappointed if some had paid off. Still, 25 developers isn't a startup, and there does need to be an established company. Commented Oct 26, 2010 at 16:28
  • @David - the question says "Imagine a startup ...". Can it be any more clear?
    – Stephen C
    Commented Oct 27, 2010 at 6:57
  • While I like to think I have a good imagination, there are things I've tried to imagine and failed. One is a startup with 25 developers. After over ten years as a technology company that's very heavily dependent on software, we don't have 25 developers. Commented Oct 27, 2010 at 14:28

Get to know each and every developer individually, personally, and genuinely by meeting their needs on these dimensions:

  1. Giving clear direction of responsibility and expectations (tell them what is needed)
  2. Give access to the tools needed to do the job correctly (monitors, beefy systems)
  3. Give them a way to measure their performance (geeks like graphs)
  4. Give ample of opportunity to develop professional skills
  5. Give them plenty of acknowledgment when they do a good job (who doesn't like praise)
  6. Give them jobs that that will be successful at (what are they individually good at doing)
  7. Give them a way to voice their opinions, ideas, and feelings (in a safe way)
  8. Give ways to encourage and foster friendship (work culture)
  9. Give them a reason to make quality products (pride in what they make)
  10. Give a higher calling pointing out why what they do is significant to another person (there seems to be almost a 'spiritual' dimension to work)
  • Sub teams (DB, middle layer, GUI)

  • Wot no testers? Replace some code monkeys

  • Wot no analysts? Replace some code monkeys

  • Who will manage tools/source control/wiki/infrastructure/environments? Replace some code monkeys

  • Free coffee, free water, free fruit

  • Friday beers


You mean, they're building "the next big thing" and they're not motivated already?

Get rid of 'em and find people who enjoy what they do.

  • SnOrfus, that may be a solution that I suggest often, but the context of the question is that they have normal motivation and you want to improve it.
    – user2567
    Commented Oct 26, 2010 at 15:30
  • @Pierre 303: The point I'm trying to make is that intrinsic motivation is the most powerful, and beneficial. Other forms of perceived motivation can be a detriment. For instance: ted.com/talks/dan_pink_on_motivation.html Commented Oct 26, 2010 at 16:53
  • That TED talk is amazing! I plan to go to a local TED talk in December. Those presentations are rarely boring.
    – user2567
    Commented Oct 26, 2010 at 17:06

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)


You are to motivate developers to write the next killer app?

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.

Then show them in action that you actually mean it!


in order or importance:

  • shared vision
  • clear expectations
  • predictable environment (TDD, nightly builds, daily team chats, weekly check-ins, whatever works for your team and product)
  • the best tools possible
  • serious salary with overtime
  • telecommute
  • stock options

Steve McConnel has a good overview of this in his book Rapid Development, as well as a list of sources (including the much-praised Peopleware) for further reading.

It is a bit dated, but still a well-rounded summary and very relevant.

  • Pay above-market rates
  • Give them clear requirements (filter out the non-essentials)
  • Be passionate about software development, even do some programming yourself
  • Be the enabler, not the "boss"

Hire someone more knowledgeable than me who I can learn from, and recognise both the time when I correctly follow their lead, and the times I'm right and they're wrong.


Team Events might help. Events like going to a sports game and so forth might motivate part of the group. I guess the balance is finding out an event that will include everyone.

  • 2
    Except they find place on weekends or after work in general. Commented Oct 26, 2010 at 21:26