It has been a long year. Month after month you have worked hard to deliver on project promises, and so have the programmers on your team. You are starting to think about year-end bonuses. It is the season for gifts—Winter Solstice, Hannukah, Christmas, Kwanza, or plain-vanilla New Year's—the celebrations seem to come tumbling one after another. What do you give your high-performing programmers to let them know you appreciate them? More generally, what do you do to recognize, reward, and motivate your applications and software developers? That was essentially the question posed from the audience on one speaking tour I did in Australia with industry luminaries Rob Thomsett and Ed Yourdon. It got us all to thinking about some of the more creative and effective incentives for developers.
This is a perennial problem. Many of us have a tendency to think in simple terms when it comes to incentives. Some years ago, I was working with Russian and Ukrainian managers from what were then recently privatized former Soviet-run firms. At one point, I found myself caught up with them in the ever-popular management game of “Why-Don't-You-Yes-But.” I would suggest ways to work more efficiently and they would say, “Yes, but we don't have reliable lines of supply here.” “Yes, but our workers do not expect to take initiative.” “Yes, but we cannot fire workers and we cannot change their pay. We have no ways to motivate them.” At first, these bright, motivated former-Soviet managers could see no way to motivate their workers, but when I suggested they brainstorm, they devised dozens of ways and means to motivate others without resorting to the axe or the pocketbook. Certainly we can do as well.
Most of us propeller heads love technology toys. The real test of kinship with the glorious granfalloon of dweebs and dweebettes is simple. Do your eyes light up at the thought of a cool new GUI widget or a 3-D video card driving a 21-inch flat-screen monitor or a gigahertz laptop with a 20 gig hard drive? Are you one of those who cannot wait to get your hands on the beta release of every new product that appears? Do you find yourself ripping off shrink-wrap to see if release 2.0 finally solves the problems of 1.1?
One of the payoffs for delivering your software in time might be to get on the beta test panel for someone else's new software. Or maybe the first copies of a new CASE tool or the newly purchased development suite go to members of the team that performed the best last quarter. Teams that deliver on promises might get first dibs on delivery of the next round of hardware upgrades.
This tactic will not work for everyone, of course. Some of us would rate installing beta release software on our machines somewhere between swimming in moldy oatmeal and replacing a rooftop satellite dish during a thunderstorm. I myself have managed to avoid participating in all but one beta test over the last several years. Maybe a better answer is offering a menu of new software and hardware toys. Top performers get first pick. Yet another variation would be to give the best developers more say over what tools and languages and libraries will be purchased next.
While we are on the subject of toys, have you ever noticed the feeding frenzy that results when some exhibitor at a developer conference comes up with a real cool give-away? Never underestimate the power of a T-shirt. The full range of “promotional” gimmicks—team jackets, special ties, limited edition mugs or mouse pads—can all be ways of singling out the winning teams and team members to recognize them as something special. The best team might get the chance to design its own team-insignia fashion, with the company picking up the tab for production.
I have to credit Rob Thomsett for one of the most creative ways to give a bonus to your best and brightest and get an unexpected bonus in return. He suggests you reward excellence with time, giving those who deliver quality software on time the time to pursue whatever project might interest them. What programmer wouldn't jump at the chance to spend several months learning a new language or experimenting with image compression techniques or creating a new free-text search method? The project could be anything, and they get paid for it! What really turns most of us techo types on is learning things, trying things out, playing around with new tools and techniques.
Thomsett says that, in his experience, most programmers would rather have more time than more money anyway. The bonus to the company of this sort of sponsored research is not just a happy developer with new skills and ideas but maybe a new piece of software or some useful new technology as well. This approach to reward may make even more sense for whole teams. When a project team demonstrates their ability to perform above and beyond established best practices, reward them by turning them loose on the research and development project of their choice.
If time really has more value for your programmers than money, you might offer extra days off as a bonus. On a grander scale and in a larger time-frame, the Australians have an interesting custom known as long-service leave. After you have been with a company or organization for ten years, you get to take an extended holiday, typically 8-12 weeks at full pay. In a field where loyalty is lean and turnover is such a major problem, it makes a lot of sense to use incentives that help you keep the good people you worked so hard to recruit.
Keeping abreast of current developments in software is a challenge, but it is also one of the fun things about working in a fast-changing technical profession. It certainly is never boring. Attendance at an extra training seminar or a ticket to the next Embedded Systems Programming or Software Development Conference could be a cost-effective way to recognize hard work. Books and magazine subscriptions are another low-cost way to escalate the stakes.
Once a group has learned how to work together well, why break them up? One reward for high performance teamwork could be the option of staying together for the next project. More broadly, getting to pick your working partners might be an effective incentive for peak performance. In a related vein, a free choice from among the next projects to be started might be the payoff for doing well on the last one.
What about better working conditions, a redecorated office, or rearranged partitions that make it easier for people to work alone or to meet? The possibilities are only limited by your imagination and your willingness to step outside the conventions of traditional management thinking. At least one company motivates its professional staff through access to inside information, taking an open-book approach to management that keeps everyone informed on financial and production details, so all can see the ultimate impact of their work.
Of course, in designing rewards and incentive schemes, there is no substitute for knowing your people. One person might be quietly pleased to get a gold-lettered, best-of-show coffee mug while another would be insulted. A long weekend could be completely lost on that diehard data analyst who lives at the office anyway.
You might even ask your high-performers what they would like. Now there's a novel idea!
From Software Development, Volume 3, #12, December 1995.