Advice for When You Apply These Ideas

As we move through the rest of this course, keep the “ARC” acronym firmly at the front-and-center of your thoughts, particularly as we approach the “actions” part of the performance cycle. We’ll revisit some of this again when we talk about “Rewards,” because as someone who is interested in their employees’ motivational outlook, you’ll want to make sure you don’t accidentally undermine your peoples’ ARC.

Keep in mind that motivation is not something you can impose on people—trying to push people into doing something is much like trying to push a damp spaghetti noodle uphill. You’re far better off finding out your peoples’ “why” and looking for ways to align with that. If you have developers who write code because they love to write code, then don’t reward them by promoting them to a position or role where they write less code—that won’t feel like a reward in the slightest. Those developers who write code because it helps the team, though, are ripe for being rewarded with a role that allows them to interact and connect with others even more—even if they’re not the best developer on the team. Above all, look for ways to build that sense of psychological safety by building the relatedness of the team to itself and the larger purpose of the company. (And if you yourself don’t know the larger purpose of the company, it’s time to work with your boss, and possibly their boss, to figure it out.)

Much of this chapter derives from Susan Fowler’s book Why Motivating People Doesn’t Work (And What Does), which is highly recommended reading.