Motivation is probably the most significant influence on productivity. Signing Up is a practice that in some cases has led to extraordinary levels of motivation. It has produced remarkable successes on both hardware and software projects in a variety of industries. Its success depends on having a clear vision that team members can sign up to and on actively monitoring the project to ensure that the signed-up team develops the product in an acceptable direction.
Efficacy
Potential reduction from nominal schedule: | Very Good |
Improvement in progress visibility: | None |
Effect on schedule risk: | Increased Risk |
Chance of first-time success: | Fair |
Chance of long-term success: | Good |
Major Risks
Increased inefficiency
Reduced status visibility and control
Smaller available talent pool for the project
Burnout
Major Interactions and Trade-Offs
Trades possible decreases in visibility, control, and efficiency for a major increase in motivation
With the Signing Up practice, a manager or team leader asks potential team members to make an unconditional commitment to seeing that a project succeeds. The team is then allowed to complete the project in its own way. Signing Up derives its rapid-development benefit from its tremendous motivational ability. Developers who sign up make a voluntary, personal commitment to the project, and they often go to extraordinary lengths to make the project succeed. Teams that have signed up work at such a hectic pace that they are bound to make some mistakes, but the sheer amount of effort they put in can swamp the effects of those mistakes.
Kerr and Hunter point out that the Antarctic explorer Shackleton found his crew by advertising for men to perform hard work under dangerous conditions for low pay, with the possibility of tremendous glory if successful (Kerr and Hunter 1994). That, in a nutshell, is how you use signing up. You offer developers little reward except those intrinsic in the work itself: the chance to work on something important, to stretch their capabilities, to surmount a seemingly impossible goal, and to achieve something that no one in the organization has achieved before.
In The Soul of a New Machine, Tracy Kidder describes a signed-up team in which the main benefit of signing up is something called "pinball" (Kidder 1981). In pinball, the only benefit of winning the game is that you get to play again. If you sign up for a development project and succeed, you get to sign up again, on the next exciting project. That's the reward, and that's all the reward that many developers need.
Some people don't like playing pinball, and some people don't like signing up. To them, it seems like an exercise in illogic and masochism. To some, it seems like management manipulation. But to others, it represents a long-awaited opportunity. IBM found that it had no problem getting people to sign up. They found that people wanted to commit to producing extraordinary results at work; all that was missing was the opportunity (Scherr 1989).
CROSS-REFERENCE
For details on motivation and teamwork, see Chapter 11, Chapter 11, and Chapter 12, Chapter 12. For details on creating visions, see Goal setting in Using the Top Five Motivation Factors and Shared, Elevating Vision or Goal in Creating a High-Performance Team.
Frame a challenge and a vision. The keys to success with Signing Up are similar to the keys to success in motivation in general and in building high-performance teams. At the top of all the lists is providing a clear vision of what the project is supposed to accomplish. To get people to sign up, the vision needs to be of an extraordinary accomplishment. Merely completing a project is not good enough. Here are some examples of extraordinary visions:
Be the first group of explorers to reach the south pole
Be the first country to put an astronaut on the moon
Design and build a totally new computer without the company's support
Design the best computer operating system in the world
Be the first team in the organization to develop a complete shrink-wrap software product in less than a year
Create a DBMS package that places number one in its first InfoWorld comparative test and beats all its competitors by at least 0.5 points
Decisively leapfrog the competition in the same software category
Give people a choice about signing up. The Signing Up practice doesn't work if people don't have a choice about whether they sign up. You have to accept the possibility that some of the people you'd like to have on your team won't make the extraordinary commitment that Signing Up requires. The fact that some qualified people don't make the team works partly in your favor. The team members who do sign up can see that some people don't have what it takes to be on it, and that helps to foster their sense of team identity.
If you've already put the team together, you can't use Signing Up unless you're prepared to kick people off the team who won't sign up midway through the project. Signing Up needs to be implemented at the beginning of the project or in response to a crisis. It's not a practice you can initiate midstream.
Once developers have made their choice, however, the commitment must be unequivocal. They must commit to make the project succeed no matter what.
Sign up at the team level. The Signing Up practice seems to work best on teams that are small enough to have a team identity. It's hard for someone to sign up with a large organization. Some companies have used this practice successfully on large projects by creating small teams within the large projects and having people sign up for those.
People need to identify with a group that's small enough so that they know their contribution matters. When people are signed up, each and every one of them will feel personally responsible for completing the product. When the product is done, each person will feel that he or she was the key person that the project could not have survived without. And each of those people will be right.
Because Signing Up is best done at the team level, it doesn't have to be initiated by management. It can be initiated by the team lead or even by a de facto leader—someone who happens to be exceptionally self-motivated and wants to pull the rest of the team along.
Follow through by empowering the team. Signing Up won't work unless you let the team run with the ball. Point the direction, but don't specify how to get to the end.
Don't use Signing Up on a project with shaky requirements. Your highly motivated team needs to be able to charge full-steam ahead, not full-steam right, then full-steam left, then full-steam backwards. The only exception to this rule is when the team itself is responsible for defining requirements. Then sometimes they can tolerate numerous changes in direction without losing motivation.
You can use Signing Up on virtually any kind of project—business, shrink-wrap, systems, and so on. Signing Up always requires an "extraordinary commitment," but the exact nature of that extraordinary commitment means different things in different environments.
In the world of RAD, James Kerr wrote about a dedicated RAD team that signed up, which meant that they were willing to sweep aside their normal mix of responsibilities and work a hard, focused 8 hours a day on one project (Kerr and Hunter 1994). Kerr reports that this team sometimes had to work at home in the evenings or for a few hours on the weekend. The high point of this project for Kerr was the night that the team of four people stayed late to implement a set of help screens. Kerr talks at length about what a grueling day it was. The team worked a full day, took a half-hour break for pizza and beer, and kept going almost until midnight. Kerr describes this as a "breakneck schedule."
In contrast, on the Microsoft Windows NT project, signing up meant foregoing everything to be able to work on the project: evenings, weekends, holidays, normal sleeping hours, you name it (Zachary 1994). When they weren't sleeping, they were working. Developers sacrificed hobbies, health, and families to work on the project. One team member answered email from the hospital while his wife was in labor. The NT development team wore beepers so that they could be called at 3:00 in the morning if their code had broken the build. People kept cots in their offices, and many would go several days without going home. Tracy Kidder describes a similar level of commitment in The Soul of a New Machine (Kidder 1981).
Some organizations, like Microsoft, don't mind if the signing-up commitment results in a lot of overtime. Other organizations, like IBM, have found that part of the commitment can be not to work any overtime (Scherr 1989). They've found that placing a set of severe, seemingly impossible constraints on a project forces the team to consider and implement radically productive solutions that they would normally not even consider.
The level of commitment will vary with the degree of the challenge. The Windows NT team was faced with the challenge of developing the best operating system in the world. Kerr's RAD team was faced with the relatively mundane challenge of developing a business system for in-house use. Not surprisingly, one team was willing to sacrifice much more than the other.