The agile community have taken to Daniel Pink’s Drive with gusto, but I’m not sure that it is always with complete understanding.
The science shows that the secret to high performance isn’t our biological drive or our reward-and-punishment drive, but our third drive — our deep-seated desire to direct our own lives, to extend and expand our abilities, and to make a contribution.
Pink, Daniel H.. Drive: The Surprising Truth About What Motivates Us
Purpose (making a contribution to a cause) vs Purpose (what is this piece of work about?)
“the richest experiences in our lives aren’t when we’re clamoring for validation from others, but when we’re listening to our own voice — doing something that matters,… and doing it in the service of a cause larger than ourselves.”
Pink, Daniel H.. Drive: The Surprising Truth About What Motivates Us (p. 146).
Purpose is the easiest of the three intrinsic motivators to highlight the difference between how many in the agile community talk about it and how Dan Pink talks about purpose.
Purpose in the context of Dan Pink’s internal motivators is “doing something in the service of a cause larger than ourselves.”
Purpose as commonly used in the agile community: the context behind a work item that your company is asking you to do. For example, this story is part of this feature, which is part of this epic, which is part of this OKR. So yay, that is important information, but know that the OKR/feature/epic may or may not even relate to the company’s purpose (if it even has one other than profit). The reasoning behind why the work item is needed is a type of purpose sure, but it is not what Daniel Pink was talking about in his book. Don’t go hijacking it.
Purpose as Pink talks about it has two contexts — what is the purpose of your company, and what is your personal purpose?
Company Purpose: Sometimes a company is able to articulate an altruistic purpose. A reason for existing beyond making money or helping other companies make money. And sometimes that purpose is able to attract people and give them a reason for going to that place of work over and above working for a paycheck.
Personal Purpose: Example — I chose the medical profession because I like helping people.
Maybe it’s: “He raised four kids who became happy and healthy adults.” Or “She invented a device that made people’s lives easier.” Or “He cared for every person who walked into his office regardless of whether that person could pay.” Or “She taught two generations of children how to read.”
Pink, Daniel H.. Drive: The Surprising Truth About What Motivates Us (p. 155)
I hope this illustrates the difference between Pink’s use of purpose vs. why a job needs doing to fulfil a business goal/objective.
“There are many examples to show that people will work more for a cause than for cash.” — Dan Ariely
Mastery (to extend and expand our abilities) vs Mastery (here is a software task and here is a definition of what success looks like)
“the first law of mastery: Mastery is a mindset.”
Pink, Daniel H.. Drive: The Surprising Truth About What Motivates Us (p. 121)
Software developers love writing software. It is like a game or puzzle for us (I still count myself as a developer). The challenge of that puzzle can often make our work fun and rewarding (if the surrounding Office Space or Dilbert conditions are not crushing our spirit).
But — if the puzzle gets repetitive and is not longer stretching us, that element of fun is gone — even if you are knocking it out of the park every time. If you are into solving puzzles or playing games, you want to find harder and harder ones as you get better. In software, this is part of the mastery of one’s craft.
So don’t go assuming that every piece of software you ask a developer to do will somehow feed their soul in some way. And your acceptance criteria and definition of done don’t touch that itch. Don’t kid yourself, please. Yes people like to know that they are doing what is expected of them, and yes they like clear definitions of how success will be measured, and yes there is a sense of accomplishment in getting through tasks — but don’t confuse these with mastery.
Personal story /side note on Mastery. I once had a very well paid cushy software job. I decided to leave that position for a lower-paying job at another company because of Mastery. The job I was in was not stretching me, I was working with people that were not interested in mastery of their craft, and the technology we were using was dated and moving toward obsolete. I knew if I stayed there I would be falling behind the industry and would get dumber and dumber. So I left and took a lower-paying job that would feed my need for Mastery.
Autonomy (a deep-seated desire to direct our own lives) vs Autonomy (here is a work item, come up with the tasks)
There are layers of autonomy that an organization can make available to its people.
The agile manifesto hints very strongly at leveraging the intrinsic autonomy motivator with the words “self-organizing” and “trust”. Yay! (Except, I have rarely seen this practised.)
“Type I behavior emerges when people have autonomy over the four T’s:
their task, their time, their technique, and their team.”
Pink, Daniel H.. Drive: The Surprising Truth About What Motivates Us (p. 94)
- Do you have an architect that designs the software? Are developers able to have some input into the architecture?
- Are developers being assigned work/tasks?
- Can developers choose who they work/collaborate with?
- Is there flexibility in working hours? Workplace?
- How much command and control still exists in your workplace and management style?
- Do you give developers time to experiment and play with ideas they have — separate from getting work items done time?
At the far extreme of Autonomy is Open Allocation. Personally, I’m a fan. But, it takes a lot of work to get your workplace and people to this place if you are in a strong command and control mode right now. Gore and Valve are the two most famous examples of Open Allocation. Check out the Valve Handbook for New Employees for what extreme Autonomy can look like. You can get some ideas from there and start taking steps toward creating more autonomy for your people.
“researchers at Cornell University studied 320 small businesses, half of which granted workers autonomy, the other half relying on top-down direction. The businesses that offered autonomy grew at four times the rate of the control-oriented firms and had one-third the turnover.”
Pink, Daniel H.. Drive: The Surprising Truth About What Motivates Us (p. 91)
Be sure to read Daniel Pink’s book Drive in full if you are going to use the words Autonomy, Mastery, and Purpose together, as there is a context to them when used in conjunction.