For an industry 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 Motivating,” 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.

I talked about Fowler's “Spectrum of Motivation” (Disinterested, External, Imposed, Aligned, Integrated, and Inherent), and went over a new way of thinking about the ARC of motivational needs: autonomy, relatedness, and competence. But those are the targets - the endpoints we want motivational tactics to reach - and as a result, we need to talk one last time about how we achieve that, for both ourselves and our employees. Fowler calls this “self-regulation” (“the mechanism for countering the emotional triggers and distractions that tend to undermine our psychological needs”). As managers, we can help with this self-regulation tactic, although it's obviously best if practiced by the employees themselves.

The MVPs of Self-Regulation

Fowler argues that:

“Leaders and organizations need to work harder at creating a workplace where people don't have to work so hard to self-regulate. Unfortunately, even the best workplaces can disappoint us, engender bad feelings, promote vulnerabilities, and provoke emotions that drive our impulse to gobble junk food as fast as we can. People cannot count on the perfect workplace - they need to learn how to self-regulate. They need to learn how to drive, instead of being driven.”

I'll have more to say in a second, but Fowler goes on to talk about the “MVPs of self-regulation,” for those employees who can't count on finding the perfect workplace:

  • Mindfulness. This has emerged recently into the mainstream, and it usually centers around our ability to be aware of the moment. It means being aware and attuned to what's happening in the present moment without judgment or an automatic reaction. It's a state of being, but also a skill that can be acquired through practice and patience. And it's damn hard to do. Numerous texts and Web resources (and even no small number of mobile apps) all provide far better guidance than I can on how to do this, so I'll leave that to the experts to do.
  • Values. Premeditated, cognitive standards of what a person considers good or bad, worse, better, or best. Values are enduring beliefs that a person has chosen to accept as guidelines for how she works and lives her life. Many within the software craftsmanship movement talk up their commitment to good development practices as the values that all developers should hold, but two things come to mind: first, I disagree with their values, in that as a software developer I think my primary value lies in what I can deliver to my customer, not the quality of my code (although the two are often tangled, agreed); and second, it's one thing to talk about the values that we think we as an industry should hold, or our organization holds, but precious few can elucidate on what they, personally, hold as work-related values. What do you treasure about work? And how does it align with the organization as a whole?
  • Purpose. A deep and meaningful reason for doing something. Purpose is acting with a noble intention, when your actions are infused with social significance. It turns out that the people who perform best are not driven by goals, but by being values-based and “inspired by a noble purpose,” as Fowler puts it. Many twenty-something developers are all about this - either the startups they want to create are aimed at environmental issues, poverty, or homelessness, or they insist on working only for companies pursuing a noble purpose to which they subscribe. I've had a sense of purpose for twenty years: On top of the traditional “provide for my family,” I've lived for the moment when a hiring manager who turned me down shows up at a conference, looks up at the stage and says, “Wait, don't I know that guy?” (I never claimed to be a noble guy.) Today, that purpose takes on a new flavor in that now, instead of being able to point to a system and say, “I built that,” I want to be able to point to a system and say, “My team built that.” A former boss once described his job as the Director of Software Development as “an umbrella over the developers, keeping all the bureaucratic BS off of them so that they can get the real work done.” And so on. Sure, if you can cure cancer with your Web app, that'd be nice. But few of us will ever get that chance, so instead, find the nobility of purpose in the purposes that matter to you.

All of the above might feel a little….touchy-feely. And it's no secret that I live in Seattle, one of those “far left” places when people start speaking of the “Left Coast.” There's a lot of discussion around mindfulness around town. Meditation. Finding your purpose. And so on. And yes, it's pretty easy to discount all of this as “touchy-feely crap” and discount the whole mess.

And yet….

High-Performing Teams

Anybody who's ever been part of a high-performing team will feel these things resonate. Agile teams that have “formed, stormed, and normed” will often speak of the ARC values (autonomy, relatedness, competence) even if they never use those words. Agile as a whole embraces ARC: the autonomy of the team to set its own direction as part of sprint planning, the mutually-supporting nature of standups, and people looking for ways to eliminate blockers (not to mention the direct connection people often find when they pair on a tough problem and the subsequent elation when they find the solution), and it's been well-known for years that pairing is a mechanism that helps both people in the pair, even if there's a drastic skill imbalance between them.

Are you not convinced that agile is the silver bullet? I don't blame you - and I agree - it's not. Don't get me wrong, I think an agile approach is a better way of turning out software in most situations, but simply cargo-culting agile isn't going to create a high-performing team. I've been a part of teams that were well outside the agile circle on the Venn diagram of software processes, and yet were pretty high-functioning. Memory is, of course, always a fuzzy thing as time goes on, and certainly I can't speak for everybody's experience, only my own, but on at least one of those high-functioning teams, we had levels of autonomy, we felt connected to one another (we routinely went to lunch together, and sometimes even met for dinner after work), and we were constantly “testing” each other in a good-natured way about our skills on various topics. And, yes, I've seen agile teams that were following Scrum to the letter - and turning out crap.

It's my job as a manager to create an environment in which teams' motivations lead them to do good things. It's my job, therefore, to find ways to encourage mindfulness (so we remain calm under pressure, focused on what needs to be done and not giving in to negative emotions). I need to discover the values within the team and the people on the team, and encouraging them in activities that promote both their values and the company's. For some, that's encouraging them to make use of the Pluralsight subscription we got for each of them. For others, that's helping them get home in time to pick up their kids from school. And for yet others, it's about helping them revise and edit blog posts or working with them to prepare for presentations at community events, so they can grow their own brand.

And then stand back, and let them do their thing without you.

Summary

Being a manager is, in some ways, not all that hard if you realize that it's not about what you can do, but what you can help your team to do. Management is, in some ways, like parenting: You may spend a lot of time doing thankless chores and chauffeuring. You may fight with them over what the right thing to do is, or trying to get them to see that there is a broader context than just the one they see. Sometimes, you just want to chuck it all, quit, and abandon these incredibly frustrating creatures to whatever fate lies in store for them. But when it all goes well, when the hard work on your part (and the even harder work on their part) pays off, and you see them in the spotlight, collecting that praise and accolades and success…

Well, shoot, man, it's all worth it.