InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Motivation 3.0: McGregor’s Theory Y Can Work

Posted by Vikas Hazrati on May 11, 2010

Sections
Process & Practices
Topics
Agile ,
Agile in the Enterprise
Tags
Best Practices

McGregor’s theory X suggests that employees are inherently lazy and will avoid work if they can and that they inherently dislike work. Thus, they need to be closely supervised. Theory Y, suggests that employees may be ambitious and self-motivated and exercise self-control. They enjoy their mental and physical work duties. Most Agile teams would like to be associated with theory Y. Mike Griffiths suggested how this might be easy to achieve.

Mike mentioned that Motivation 1.0 is meeting the basic needs, as mentioned in Maslow's hierarchy of needs. Motivation 2.0 is the traditional stick and carrot type of management. It is based on the If-Then logic. If you do this … then you get that. Mike suggested that there are fundamental issues with this type of motivation. According to Mike,

The trouble with IF-THEN rewards is that while we like them at first we quickly tire of them. Then because the reward can never continue to escalate at levels that excite us, we grow used to them and get discouraged if we fail to meet the IF condition and do not get the reward or worse, if the IF-THEN reward is removed.

Daniel Pink suggested that there needs to be more than just stick and carrot. Motivation 3.0 is based on the intrinsic concepts of

  • Autonomy,
  • Mastery and
  • Purpose.

Mapping the concept to Agile teams, Mike suggested that Autonomy needs to go beyond the current set of process and practices. He quoted that instead of the teams to be in the workplace for a stand-ups, the teams should have the autonomy to decide the task that they would do, time and technique to do the task and create a self organizing team. He stressed on the concept of result based organizations. Mike quoted the example of Semco, which is a poster child for Result Only Work Environments (ROWEs).

Mastery denotes the pleasure of doing something that one is passionate about. People need to be in a state of “Flow”

“Flow” is a great term to describe the state of mind when time seems to disappear and we are just immersed in the task. This feeling of flow can be difficult to find when our work environment puts obstacle after obstacle in font of us, whether it is admin and rules that limit our time in the role that we love, or restrictive work processes that impinge too much to allow us to get into this flow.

Purpose is making people believe that there is more to the work that they are doing than just making money. Mike quoted the following example,

This is why companies like TOMS Shoes were created that give away a pair of shoes to poor countries for every pair sold. Buyers feel good since their purchase has a charitable impact and the workers at TOMS feel good since they are doing more than just generating shareholder value.

Are Agile teams there yet?

Mike suggested that the good news for Agile teams is that they can potentially reach Motivation 3.0 with little effort. Autonomy of task, technique and team are inherently encouraged by Agile. The aspect of time is also finding a favorable corner with Kanban. Further, teams should promote mastery by encouraging enthusiasm for the craft and having local events like code camps, conferences and presentations. Apart from this teams should start looking for a purpose in what they are doing.

Perhaps your project can help your company become environmentally more responsible, or you can use your role to help rally support for community events. The “forced fun” and “manufactured moral” of team building events can wear thin on many people, but if redirected into a Habitat for Humanity Build or other such tangible benefit, suddenly we are engaging the motivation of purpose and gaining the side effect of team-building.

Thus, Agile teams seem to be in the striking distance of Motivation 3.0. The key lies in giving the right amount of autonomy, promoting mastery and defining a purpose. The combination promises to unleash the true potential of the team.

  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

Two-factor Theory by Sergio Bogazzi Posted
  1. Back to top

    Two-factor Theory

    by Sergio Bogazzi

    Dan Pink's findings are certainly interesting but Herzberg's two-factory theory hit on them much earlier: en.wikipedia.org/wiki/Two-factor_theory

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.