The world of work has changed, but in many ways the model of motivation hasn’t. Are the traditional rewards of today’s organizations up to the challenge of motivating people to complete creative, complex tasks in creative ways? And can the open source way offer inspiration?
Daniel Pink is a bestselling author and one of the country’s top business speakers. His latest book is Drive: The Surprising Truth About What Motivates Us. You can watch him deliver an insightful and entertaining introduction to Drive at the TED Conference.
Pink has written several books about changing the world of work. Among them, one of my favorites, A Whole New Mind: Why Right-Brainers Will Rule the Future, remains one of the strongest cases for right-brain thinking, creativity, storytelling, and design in organizations.
In Drive, Pink asserts that we need a new model of motivation to match the demands of today’s highly competitive, globally connected environment--and the creative, complex tasks this environment requires of us. The three building blocks of the model: autonomy, mastery, and purpose. One of the examples Pink uses in his book to discuss this new motivational model is open source.
I had the chance to talk to Pink about his new book, this new model of motivation, and the role of the open source way:
One of my favorite quotes of yours is “If a picture is worth a thousand words, a metaphor is worth a thousand pictures.” So I’ll start with one of the metaphors you used in your book. You describe human motivation in terms of an operating system. The first operating system was about survival, the second was about a set of external rewards and punishments. Can you talk about the fact that we haven’t upgraded for the 21st century. You’re advocating for a third operating system to handle some of the incompatibility issues.
I use that metaphor because I thought it helped clarify what was going on. An operating system is something that people don’t always see. It’s a set of things that run underneath. It contains a lot of the instructions, suppositions, and assumptions about how things operate.
Our first operating system was really built on this assumption that human existence was about survival. And that was true for a long time. We were just trying to outrace the sabretooth tiger. If an operating system is built on our biological drives--eating when we’re hungry, drinking when we’re thirsty, having sex to satisfy our carnal urges--that makes a lot of sense.
It doesn’t work so well if you actually want to do business or interact with people outside of your tribe or your clan or when you figured out more ingenious, systematic, and scalable ways to protect yourself from the sabretooth tiger.
So we had in some sense, again metaphorically as you say, an upgrade to what you can think of as motivation 2.0, which is built on this idea that human beings respond very well to rewards and punishments in their environment, which is true. You reward behavior you typically get more of it, you punish it you typically get less of it. And that’s a very effective operating system. It helped fuel the industrial revolution. Carrots and sticks were as important a fuel for that as oil or steam or coal.
The problem is, and this is the animating idea behind this book, is that there’s 50 years of science that shows that while those carrot-and-stick motivators work very well for relatively simple, routine algorithmic tasks--whether it’s turning the same screw the same way on an assembly line, or whether it’s doing white collar work where you’re processing information, processing paper, getting the correct answer. But the science is pretty clear they don’t work very well, they are in many ways incompatible with more creative, conceptual, complex work.
The reason for that is these if-then motivators--if you do this, then you get that--they really get people to focus. They really capture people’s attention and focus their gaze. That’s a good thing if the answer is right ahead of you. It gets you to race a little bit faster, it gets you to follow the steps of the particular algorithm or the particular rule a little bit more speedily because you see that big carrot dangling at the end of it.
But for creative tasks, conceptual tasks, the big picture tasks, the murky tasks--the sorts of things that more and more of us are doing at work--those kinds of motivators don’t work very well. They narrow our focus, when with those kinds of things you want an expansive focus. These if-then motivators also have a cascade of other kinds of bad consequences.
At the same time, you have a structure of firms changing where you have more people who are working by themselves or working for themselves, with less oversight, so that requires a much greater degree of self-direction.
And then getting to open source, you have this business model that would have seemed fanciful if not insane 25 years ago, which is built not so much around these carrot-and-stick-motivators but around other sorts of drives becoming very popular.
So I think that more broadly the operating system that’s used--the kind of societal behavioral operating system that is undergirding open source--is in many ways a model for the upgraded motivational operating system that all organizations need.
One of the examples you use in your book is Wikipedia, which many people recognize as an example of open source principles at work beyond technology. You write: “Wikipedia represents the most powerful new business model of the 21st century: open source.”
I think that people who are involved in open source sometimes don’t realize how extraordinary it is. And how truly it would have seemed verging on impossible 25 years ago. It would have seemed outlandish.
If you had presented it in business school to some strategy professor saying, “I’ve got this new business model for creating software, and here is how it goes: A bunch of people around the world who don’t know each other get together and work for free. And these are highly skilled, technically able people who decide to do really tough, sophisticated work for free, and they give away their product,” it would have seemed ludicrous. And the fact that it worked and it worked so well, and the fact that it has challenged if not toppled other software products that are created in the more conventional way, ought to give us some hints about how we structure firms, how we organize workers, and I think deep down what really motivates people to do amazing things.
I love the quote you used, “In other words, companies that typically rely on external rewards to manage their employees run some of the most important systems on products created by non-employees who don’t seem to need such rewards.”
Right. So they’re all doing these short-term pay-per-performance schemes; in the meantime their websites run on Apache, which is created by people who completely flout that whole way of doing business.
You also address one of the questions that we still sometimes hear from people who might be new to open source: “Why do developers spend their time writing open source code?” And we know from our own experience they’re working on projects that they care about and that they use, but it’s also a chance to work on projects with other talented, like-minded people. And of course some of them are getting paid to do so in organizations. You reference an MIT study that surveyed open source developers on the question. Could you talk more about that?
Superficially it might seem like weird behavior, but when you peel back the layers, it actually makes a lot of sense for the reasons that you’re suggesting. What this MIT study showed is that intrinsic motivation, enjoyment, challenge, mastery were the most important drivers of that kind of participation.
So we tend to think that people need to have big financial incentives attached to everything they do, when if fact, here you have something that doesn’t have at least a direct financial incentive for people. That they’re spending their time on and doing amazing work. Why are they doing that? They’re doing it for the sense of challenge. I think that’s a big part of it. To get better at something that matters. I think you raise a very important point, one I don’t think I made enough of in the book, that they’re creating tools that they themselves want and use. I think that’s hugely important.
I also think that the collaboration side is of it is important in the sense that If you collaborate with great people, you’re more likely to learn, and so that’s going to enhance your mastery.
Last year I came across a copy of Flow by Mihaly Csikszentmihalyi. I thought the book was fascinating. It almost seemed like he had given us a blueprint for happiness and the meaning of life. Can you talk about how he influenced Drive?
His book is personally one of the most important books and set of ideas that I’ve encountered that have affected me.
What Csikszentmihalyi has said is, where do human beings really feel most alive and engaged? And there’s a sense that I think that he has dispelled somewhat--that we’re really most alive and engaged when we’re doing something in leisure. That work is something that we suffer through in order to buy those moments of leisure. That’s true in some cases.
But I think that a lot of the things that people do today at work, both blue collar and white collar as jobs become more sophisticated, are themselves kind of interesting. Not always, but often fairly interesting and challenging. And what Csikszentmihalyi has found is that when the challenge is exquisitely matched to the task--that is, it’s not too easy and not too hard--that people have what end up being some of the optimal moments of being alive. Which is this sense of flow, of being in the moment.
One of the big takeaways from Csikszentmihalyi’s research is that people are much more likely to reach that state of flow in work than in leisure.
A lot of times our leisure is very passive and inert, and that’s not when we feel alive and engaged and motivated. We feel alive and engaged and motivated when we’re doing something that is so absorbing that we lose our sense of self.
That’s what’s true for a lot of software programmers. Software programmers hit these large patches of flow where they just crank. They look up and they say, “Holy crap, how did those three hours go by.” And then when you do that, and it’s also in the service of something larger than yourself? That’s it, man. That’s why we’re here.
1 Comment