For an in dustry that prides itself on its analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.

In my last column, “On Motivation,” I brought up Susan Fowler's book Why Motivating People Doesn't Work - And What Does, and in particular mentioned that:

An important truth emerges when we explore the nature of motivation. People are always motivated. The question is not if, but why they are motivated. ... One of the primary reasons motivating people doesn't work is our na�ve assumption that motivation is something a person has or doesn't have. This leads to the erroneous conclusion that the more motivation a person has, the more likely she will achieve her goals and be successful. ... As with friends, it isn't how many friends you have; it is the quality and type of friendships that matter.

This, then, begs the question: What are the quality and types of motivation, and which ones are better than the others?

Optimal and Suboptimal Motivation

In her book, Fowler introduces six different kinds of motivation, and describes three as “optimal” (yielding the best benefits) and three as “suboptimal” (yielding lesser benefits). She aligns these along a “Spectrum of Motivation” and, in order of suboptimal-to-optimal, describes them as “Disinterested,” “External,” “Imposed,” “Aligned,” “Integrated,” and “Inherent.” Assume that you and your team are invited to a meeting. Again, the question isn't “Are you motivated to attend the meeting,” but “Why are you motivated to attend the meeting?”

Disinterested. You just can't care less. That meeting you went to - you just can't find any value in it whatsoever. It felt like a waste of time, and as a result, it adds to your sense of feeling overwhelmed.

External. The meeting provided an opportunity for you to exert your position or power. It enabled you to take advantage of a promise for more budget, or it allowed you to show off your skills to your peers, and possibly raise your status with your boss in the room.

Imposed. You went to that meeting because you had to. Everybody else was going, and if you were going to avoid the guilt or the implicit “What makes you so much better than the rest of us that you can blow off the meeting like that?” gazes of your coworkers, you had to go.

Aligned. You found that the meeting had some value to you - you discovered something about the project/process/client that you didn't know beforehand, or had the chance to explain to somebody else why a particular obstacle was blocking you and they (finally!) understood.

Integrated. This meeting helped you further a work or life purpose - you warned people in the room about an upcoming danger that nobody else seemed to recognize, or you got a tremendous “A-HA” moment out of the conversation about something that had been bothering you about your job or career for a while now.

Inherent. Strange as it may seem, you just enjoy meetings and thought it would be fun.

The first three are the “suboptimal” motivational outlooks, and offering cash bonuses or prizes fall into the “external” category, the second-worst of the lot. Motivating somebody with peer pressure (the imposed approach) rates only slightly above that. Fowler suggests that using these approaches (prizes, rewards, threats of punishment, pressure, or using guilt/shame/emotional blackmail) are the “junk food” of motivation; they may feel good for a very short time, but inevitably they do far more damage to the system as a whole.

Instead of offering up “motivational junk food,” Fowler suggests that we need to offer employees things that actually help them: the optimal motivational outlooks. Or, similarly, as employees, we need to approach management and tell them that these “bug hunts for money” don't work and that you'd prefer to opt out of the exercise. (True story: While working as a contractor very early in my career, the company offered a “bug bounty” of $50 for every bug squashed. As a contractor, I wasn't eligible. But as it turned out, I started drawing all the really hard bugs - the ones that weren't easily fixed in an hour or two - and ended up being the only one sleeping under my desk the night before a big release. Did I make any money? Nope. But I earned the respect of my peers - and my boss - and it felt really good to have tackled the hardest of the bugs in the list and squashed them all. It felt a lot better than the $750 that most of the rest of the team earned, in fact.)

In essence, we need to understand a new model of psychological need, one that discards Maslow's Pyramid of Needs (described in my November/December 2015 CODE Magazine column) in favor of a simpler and more nuanced model: autonomy, relatedness, and competence, or ARC.

Autonomy. Our human need to perceive we have choices. We need to feel that what we're doing is of our own volition. It's our perception that we are the source of our actions. Those of you who've ever been around small babies and toddlers, think about feeding them - when we bring the spoon close to their mouths, they instinctively reach for the spoon or fork in order to do it themselves. They may or may not have the skill yet, but they need to be the source of the action - they need to be in control. “Autonomy doesn't mean that managers are permissive or hands-off but rather that employees feel they have influence in the workplace. Empowerment may often be considered a clich�, but if people don't have a sense of empowerment, their sense of autonomy suffers and so do their productivity and performance.”

Relatedness. Our need to care about and be cared about by others. We need to feel connected to others without concerns about ulterior motives. It's our need to feel that we're contributing to something greater than ourselves. For developers, in particular, this seems odd - isn't software development a “heads-down” kind of job, where we are hunched over the keyboard for hours on end, slamming out line of code after line of code? And yet, years ago, when I interviewed Ward Cunningham (of agile and patterns fame) and asked why pair programming was such a hot topic among programmers, he looked at me square in the eye and said, “Think about it - you go home, and your family barely has any idea of what you do all day. Here's an opportunity to sit in close proximity with someone who actually understands you, and is now deeply interested in whatever you have to say about the code you're about to write. For the first time, somebody is actively listening to you.” That's a pretty powerful thing. As Fowler puts it, “One of the great opportunities you have as a leader is to help your people find meaning, contribute to a social purpose, and experience healthy interpersonal relationships at work. ... The role you play as a leader is helping people experience relatedness at work.”

Competence. Our need to feel effective at meeting everyday challenges and opportunities. Demonstrating skill over time. It's feeling a sense of growth and flourishing. This one, surely, developers can relate to; after all, what feels better than suddenly “getting it” about some technology or pattern or system? Squashing the hard bug that nobody else could fix, putting in the feature that makes all the users go “ooooh,” shipping the revision on time when everybody else said it would be late…. In a lot of ways, developers seem to live for those moments. Ironically, popular thinking seems to be acting in opposition to this - the “everybody gets a trophy, just for participating!” model common in many schools and sports teams offers a false (and clearly manipulative) sense of competence that most recipients (including just about every kid who ever got a participation trophy) can see through from a mile away. Competence feels best when it is earned, not awarded. It comes from actual growth and learning - not a trophy.

Resonating yet? My guess is that unless you're one of those very few who've achieved complete self-actualization (in which case, you should probably start a religion around what you've learned), a position that offers and a manager who encourages autonomy, relatedness, and competence sounds pretty damn good.

Summary

From time to time, I run across people who describe themselves as “driven.” “I'm driven to success” or “I'm driven to do good in the world” or similar statements. Fowler nails this best when she asks, “What's driving you?” The term “driven” implies that something external to the individual is whipping them along, and it's often highly enlightening to find out what is doing that driving - is it a deep desire for parental acceptance, a desire to prove to somebody else that yes we can actually “make it” as a programmer, or perhaps a deep desire to prove to ourselves that getting that CS degree wasn't a mistake after all.

It turns out that we seek self-regulation: “mindfully managing feelings, thoughts, values, and purpose for immediate and sustained positive effort.” It's the mechanism that counters the emotional triggers and distractions that tend to undermine our psychological needs. But a deeper understanding of that will have to wait until next time.

(Yeah, this is the literary equivalent to clickbait to end an article on a cliffhanger like that - but space limits are a hard thing to work with sometimes. You'll manage, I'm sure. grin)