If you were the manager of a team of 25 developers, how would you motivate them? [closed]

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/14720

Question

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.

Was it helpful?

Solution

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.

OTHER TIPS

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.

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

http://www.chrisholmesonline.com/2010/06/02/the-surprising-truth-about-what-motivates-us/

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.

Delegate.

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.

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

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.

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.

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.

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.

Licensed under: CC-BY-SA with attribution
scroll top