"Carrots & Sticks are so last Century. Drive says for 21st century work, we need to upgrade to autonomy, mastery and purpose." So says Daniel Pink as a summary of his best-selling book Drive that has popularized the astonishing research into the nature and power of intrinsically motivated behavior. How can a software development organization apply these principles to create a competitive advantage?
Pink popularized the research of many behavioral scientists, particularly Edward L. Deci, which began with his landmark publication Intrinsic Motivation published in 1975. Pink uses the Open Source software movement as an example of the power of intrinsic motivation. In Open Source projects, we see people creating world class software, such as Linux, without any extrinsic motivation - no carrots (no financial incentives) and no sticks (fear of being fired). Something from within - something intrinsic - drives them to these creative heights. (If intrinsic motivation seems too abstract or academic, feel free to substitute "fun" anywhere you read "intrinsic motivation". They are nearly synonymous in application.)
Research has demonstrated that when people are acting in an intrinsically motivated way they are much more creative (Amabile), more persistent (Deci and Ryan), and more flexible (McGraw and McCullers) in completing a task. Equally important and especially relevant to technology, which often entails significant learning curves, is the strong association between intrinsic motivation and learning, particularly conceptual learning (Deci and Ryan).
So recognizing the need to harness this creative energy, how can we create an environment within a software organization that encourages and facilitates intrinsic motivation? How can an organization ignite that rocket fuel?
Pink describes the three factors that researchers have identified as encouraging (or undermining) intrinsic motivation for any given activity: a sense of autonomy, a sense of mastery, and a sense of purpose. It seems obvious that the most direct and important factor for software development is giving the developer significant freedom to make choices about the work they are engaged in. This includes the freedom to choose the projects he or she wants to work on, the freedom to collaborate with others of their choosing, and the freedom to work in the manner in which he or she is most comfortable. Giving developers significant discretion around their work obviously supports a sense of autonomy (what researchers often call self-determination), but equally important, developers will naturally gravitate to those projects that will help them build their sense of mastery; they will choose projects that will give them the opportunity to exercise their existing skill sets and extend their skills into new areas of interest.
So, how could an organization implement this principle, and what are some practical hurdles and objections to overcome? Someone might ask, "Wouldn't that just be chaos if everyone just did whatever they wanted?". Perhaps, however I've found it surprising how well people tend to self-organize if given the opportunity, but some minimal structure would seem to be appropriate especially in larger organizations.
An example of how this could be implemented - each proposed project could be required to have three initial sponsors - volunteers who feel strongly about the value of the project:
(1) a product owner - in the Agile Scrum sense - someone probably from product management or marketing who will define the goals of the project and approve the outcomes.
(2) a technical lead - a senior developer who is capable of implementing the technical aspects of the project independently if necessary but ideally someone who can recruit and manage a larger team.
(3) a management sponsor - someone at an executive level who can approve expenditures, provide resources, and provide general advice and oversight.
Once these three sponsors are on board, the next phase would be to formally, and/or informally, begin to spread the word to the rest of the developers about the nature of the project - its goals, scope, technologies, duration, importance, visibility, etc. Developers would then volunteer for the project based on their skills and interests. The technical lead should probably have ultimate discretion in the makeup of the team.
Other objections / concerns:
"What if no one volunteers to work on the project?"
It's possible that the project could start with just the tech lead and then as others see the progress they may choose to join later. But assuming you need more contributors right away, you might consider changing the project in some way to "sweeten the pot". Consider why the project isn't attractive. For example, if the project involves fixing bugs in some legacy system, a more attractive project might involve refactoring or rewriting sections of the legacy system that include these bugs. Project sponsors might also consider marketing the project in a way that emphasizes the importance and high profile nature of the project (if that's the case) - again, from Pink's Drive - providing a sense of purpose and importance can be very motivating.
"What if key people leave ongoing projects to join new projects?"
I expect professionals to manage their participation in projects in such a way that it preserves their reputation and standing within the organization. However, even in extreme cases, it would be better to have that talented developer switch projects, even if it sets the project back some, rather than switch companies because they want to work with different technologies or people.
Many successful technology companies are already harnessing the power of intrinsic motivation with great success. Valve - one of the most successful game developers (Half-Life) and online game distribution companies (Steam) - has taken these ideas to the extreme. In their company handbook (which is worth reading just for the illustrations) they describe a process where new employees are basically just told to go and figure out for themselves where and how they should plug-in to contribute to the success of the company.
Everyone has heard about how Google allows their people to spend 20% of their time on discretionary projects and how that has lead to some serious innovations and some seriously happy developers, but what is not commonly known is that the developers also appear to have a great amount of freedom to choose the projects that they work on with the other 80% of their time.
How does this approach differ from the way things are managed in a traditional software development organization? Typically, project staffing is handled by managers who assign developers to projects based on their perceived skills and availability. Even if you assume that the manager is aware of the interests and ambitions of the developer and takes this into consideration, it still significantly undermines the developer's sense of autonomy. As research has demonstrated, to the extent a person perceives the cause of his or her actions to be external to him or her; he or she will lose intrinsic motivation for that associated activity because it diminishes his or her overall sense of self-determination (Deci and Ryan).
I believe the trade-off for devolving more control down to the developers would be levels of creativity, innovation, determination, excitement and satisfaction that a traditional approach could never come close to matching, and as many have observed, highly motivated people may be the only real sustainable competitive advantage.
References:
Amabile, Teresa M. The Social Psychology of Creativity. New York: Springer-Verlag, 1983.
Deci, Edward L. Intrinsic Motivation. New York: Plenum Press, 1975.
Deci, Edward L. and Ryan, Richard M. Intrinsic Motivation and Self-Determination in Human Behavior. New York: Plenum Press, 1985.
McGraw, K.O. and McCullers, J.C. “Evidence of a Detrimental Effect of Extrinsic Incentives,” Journal of Experimental Social Psychology, 1979
Pink, Daniel Drive. New York: Riverhead Books, 2011
Pink popularized the research of many behavioral scientists, particularly Edward L. Deci, which began with his landmark publication Intrinsic Motivation published in 1975. Pink uses the Open Source software movement as an example of the power of intrinsic motivation. In Open Source projects, we see people creating world class software, such as Linux, without any extrinsic motivation - no carrots (no financial incentives) and no sticks (fear of being fired). Something from within - something intrinsic - drives them to these creative heights. (If intrinsic motivation seems too abstract or academic, feel free to substitute "fun" anywhere you read "intrinsic motivation". They are nearly synonymous in application.)
Research has demonstrated that when people are acting in an intrinsically motivated way they are much more creative (Amabile), more persistent (Deci and Ryan), and more flexible (McGraw and McCullers) in completing a task. Equally important and especially relevant to technology, which often entails significant learning curves, is the strong association between intrinsic motivation and learning, particularly conceptual learning (Deci and Ryan).
So recognizing the need to harness this creative energy, how can we create an environment within a software organization that encourages and facilitates intrinsic motivation? How can an organization ignite that rocket fuel?
Pink describes the three factors that researchers have identified as encouraging (or undermining) intrinsic motivation for any given activity: a sense of autonomy, a sense of mastery, and a sense of purpose. It seems obvious that the most direct and important factor for software development is giving the developer significant freedom to make choices about the work they are engaged in. This includes the freedom to choose the projects he or she wants to work on, the freedom to collaborate with others of their choosing, and the freedom to work in the manner in which he or she is most comfortable. Giving developers significant discretion around their work obviously supports a sense of autonomy (what researchers often call self-determination), but equally important, developers will naturally gravitate to those projects that will help them build their sense of mastery; they will choose projects that will give them the opportunity to exercise their existing skill sets and extend their skills into new areas of interest.
So, how could an organization implement this principle, and what are some practical hurdles and objections to overcome? Someone might ask, "Wouldn't that just be chaos if everyone just did whatever they wanted?". Perhaps, however I've found it surprising how well people tend to self-organize if given the opportunity, but some minimal structure would seem to be appropriate especially in larger organizations.
An example of how this could be implemented - each proposed project could be required to have three initial sponsors - volunteers who feel strongly about the value of the project:
(1) a product owner - in the Agile Scrum sense - someone probably from product management or marketing who will define the goals of the project and approve the outcomes.
(2) a technical lead - a senior developer who is capable of implementing the technical aspects of the project independently if necessary but ideally someone who can recruit and manage a larger team.
(3) a management sponsor - someone at an executive level who can approve expenditures, provide resources, and provide general advice and oversight.
Once these three sponsors are on board, the next phase would be to formally, and/or informally, begin to spread the word to the rest of the developers about the nature of the project - its goals, scope, technologies, duration, importance, visibility, etc. Developers would then volunteer for the project based on their skills and interests. The technical lead should probably have ultimate discretion in the makeup of the team.
Other objections / concerns:
"What if no one volunteers to work on the project?"
It's possible that the project could start with just the tech lead and then as others see the progress they may choose to join later. But assuming you need more contributors right away, you might consider changing the project in some way to "sweeten the pot". Consider why the project isn't attractive. For example, if the project involves fixing bugs in some legacy system, a more attractive project might involve refactoring or rewriting sections of the legacy system that include these bugs. Project sponsors might also consider marketing the project in a way that emphasizes the importance and high profile nature of the project (if that's the case) - again, from Pink's Drive - providing a sense of purpose and importance can be very motivating.
"What if key people leave ongoing projects to join new projects?"
I expect professionals to manage their participation in projects in such a way that it preserves their reputation and standing within the organization. However, even in extreme cases, it would be better to have that talented developer switch projects, even if it sets the project back some, rather than switch companies because they want to work with different technologies or people.
Many successful technology companies are already harnessing the power of intrinsic motivation with great success. Valve - one of the most successful game developers (Half-Life) and online game distribution companies (Steam) - has taken these ideas to the extreme. In their company handbook (which is worth reading just for the illustrations) they describe a process where new employees are basically just told to go and figure out for themselves where and how they should plug-in to contribute to the success of the company.
Everyone has heard about how Google allows their people to spend 20% of their time on discretionary projects and how that has lead to some serious innovations and some seriously happy developers, but what is not commonly known is that the developers also appear to have a great amount of freedom to choose the projects that they work on with the other 80% of their time.
How does this approach differ from the way things are managed in a traditional software development organization? Typically, project staffing is handled by managers who assign developers to projects based on their perceived skills and availability. Even if you assume that the manager is aware of the interests and ambitions of the developer and takes this into consideration, it still significantly undermines the developer's sense of autonomy. As research has demonstrated, to the extent a person perceives the cause of his or her actions to be external to him or her; he or she will lose intrinsic motivation for that associated activity because it diminishes his or her overall sense of self-determination (Deci and Ryan).
I believe the trade-off for devolving more control down to the developers would be levels of creativity, innovation, determination, excitement and satisfaction that a traditional approach could never come close to matching, and as many have observed, highly motivated people may be the only real sustainable competitive advantage.
References:
Amabile, Teresa M. The Social Psychology of Creativity. New York: Springer-Verlag, 1983.
Deci, Edward L. Intrinsic Motivation. New York: Plenum Press, 1975.
Deci, Edward L. and Ryan, Richard M. Intrinsic Motivation and Self-Determination in Human Behavior. New York: Plenum Press, 1985.
McGraw, K.O. and McCullers, J.C. “Evidence of a Detrimental Effect of Extrinsic Incentives,” Journal of Experimental Social Psychology, 1979
Pink, Daniel Drive. New York: Riverhead Books, 2011
Comments
Post a Comment