"... there's a gap between what science knows and what business does." This is the mantra that Dan Pink repeats throughout his book, describing how we unintentionally demotivate through our mistaken beliefs about how motivation works.
This gap occurs in many other areas as well, but I think Pink is correct in choosing motivation as the most important target for business, school and life in general. Nothing is more fundamental for the success or failure of a company than the motivation of the people working there. It turns out that the "natural" approach of using threats and rewards is actually counterproductive -- it makes people reduce their productivity.
If it was that simple it wouldn't be quite as puzzling. The problem is that threats and rewards do work, but only for repetitive mechanical tasks -- the very kinds of manufacturing jobs that are continuing to leave the country (even though manufacturing itself has steadily increased). But threats and rewards are only effective when what you want is compliance.
It's like Newtonian mechanics, which seems like the only truth there is, as long as you do everything within the Newtonian domain. As soon as you get very small, large, fast, heavy, etc., you realize you've only been working with a subset of the rules. In the same way, as soon as you move away from menial labor where, sure enough, if you offer people more they'll work harder, you discover that the carrot-and-stick approach no longer works. For creative work, it's demeaning; it removes the intrinsic motivation and turns creativity into drudgery. When that happens, people lose their motivation and work less.
The same thing happens in schools. When you offer students extrinsic rewards, they learn to work only for extrinsic rewards, and not to learn. "Teaching to the test" is a short-term political move that has long, deep and very destructive results.
Pink gives us the components necessary for a happy and productive workplace which he defines as "Motivation 3.0." He stops short of defining "Business 3.0" (which is what I would like to do). This is understandable, as he's trying to make an airtight case, to drive an unarguable wedge into the old business practices. Coming up with an untested structure for Business 3.0 would distract from the force of his arguments, so it was the right choice (although he does point out some working companies that embrace his principles).
The three essentials for motivation when doing non-repetitive work are autonomy, mastery and purpose.
Autonomy is essential for happiness. You need to feel like you're steering your own boat. This will probably be the hardest one for traditionally-schooled managers to absorb. In its purest form, the Results-Only Work Environment (ROWE), all the normal control that a manager exerts over an employee is relinquished. Employees come in whenever it works for them, work at home when they can, meetings are optional, and there are no time clocks. The only thing that matters is results. If you're used to top-down control, this will be very hard. And a company that is built around hierarchical command-and-control might not be able to make the change.
Of course, the ROWE approach is extreme, and perhaps more appropriate for a startup than for an existing company. An established organization can still incorporate a more autonomous environment, and new teams can experiment with ROWE as long as their manager can hide this from the company at large.
Mastery, the way Pink has presented it, is a little puzzling for me because he lumps mastery and flow together, which seem to me to be two very different things. Mastery is something that is achieved over years, a little bit at a time. It's often a difficult process with many ups and downs and small insights that can take weeks or months to achieve. Flow is the opposite; it's the daily satisfaction you get from doing something that's not too easy but not too hard. Ideally you get flow every day, and it's what carries you through the difficulties of achieving mastery.
I wonder if Pink didn't lump the two together just so that the resulting formula came out in a nice triad, which is in fact easier to remember.
To achieve flow, you need:
A challenge that is not too easy nor too difficult
Something that engages you
Games appear to be targeted towards achieving flow. Note that Test-Driven Development (TDD) might also produce flow.
Purpose. Although autonomy and mastery can keep employees happy in the short and medium term, without the feeling that you are working towards a higher purpose -- something larger than yourself -- eventually you start asking "what's it all for?" and lose motivation. So it's important that there is real underlying meaning to your work.
Although there are relatively few companies so far that have consciously made the move to incorporate Motivation 3.0 practices, Pink describes some of them in the book. Although many business books provide examples of companies that apparently support their conjectures, this one feels different to me, mostly because it focuses on what keeps employees happy and motivated. That just feels right to me, probably because what drove me away from being an employee was watching the life being sucked out of everyone around me (one of these companies went through reorganization fads every six months; I lost track after "business units"). Pink's analysis could be applied to companies themselves: if the company is motivated through extrinsic rewards, it will organize itself around those rewards and nothing else.
Some companies are ahead of the curve. Netflix, for example, pays people well (this removes any concerns about fairness) but they never give bonuses. In contrast, note the practice of excessive CEO bonuses, and the destructive outcomes that this seems to produce.
For me, the best thing about this book is that it reminds me I am not a lone voice crying in the wilderness when it comes to reinventing business. At one point he even says "Management is not the solution. It's the problem." There are lots of people attacking this problem from many different approaches and many books to read; Clay Shirky is an example (Here Comes Everybody is great).
We've been told the wrong story so many times we believe it: "the reason for a company is profit." That's like saying the reason we're alive is to eat. Management theory is convinced that it is a science, therefore any improvements must have happened because of scientific knob-twiddling by management. "Drive" shows that improvements happen despite things that management does, that our desire for fulfillment is so strong that we can achieve things in the face of the roadblocks that management places. Consider a skunkworks project, which must be hidden because normal management would not allow it to happen. Or stories of teams that are great within a failing company; team members stay because they are fulfilled by the team despite the catastrophic actions of the management surrounding the team. (Note that when I say "management" here, I am referring to the myriad management theories based on the belief that management is science, not the people who are in the role of managers.)
The challenge is not to figure out how to make money. A company filled with autonomous, motivated employees will learn how to make money, and will be able to discover and change when old markets disappear and new markets form (much faster than an unmotivated organization). The real challenge, for a company whose prime goal is profit, is how to remain inspired and motivated once the short-term extrinsic thrill of making money has passed.
The firstReinventing Businessconference will tentatively be June 22-24 or July 14-16, in Crested Butte, CO. Both dates are open at the conference hall and I need to determine which works best. This will be an open-spaces conference with a similar structure to the Java Posse Roundup, however, attendance will be limited to 25. Check your calendars; I'll be putting the conference page together over the next couple of weeks.
But is it possible to "re-define" all the responsibilities of a job role to "maximize" autonomy, mastery and purpose?
In my experience unless you are very very lucky, some degree of grind is unavoidable. E.g: even if you are a hot-shot developer who just wrote an earth-changing billion-dollar-earning facebook-killing application, you still have to document it - because the company needs other people to be able to maintain it if you leave the company!
Is it about sorting your responsibilities into repetitive and non-repetitive categories, and "supplying" extrinsic motivators for the former and intrinsic motivators for the latter?
Or is it about simply delegating the mundane stuff to "that new kid just out of college" or to India?
Teresa M. Amabile's and Steven J. Kramer wrote in an article at Harvard Business Review:
A close analysis of nearly 12,000 diary entries, together with the writers’ daily ratings of their motivation and emotions, shows that making progress in one’s work—even incremental progress—is more frequently associated with positive emotions and high motivation than any other workday event.
I have a basic theory around motivation, which revolves around two-axis: selfishness and selflessness.
Selfishness because people in the early years of their careers are more inclined to establish their reputation than save the world, and selflessness because those priorities tend to swap places towards their later years.
In the beginning, just learning something new and becoming more marketable is often enough motivation. Fast-forward a decade or two and you have already learned as many skills as can be applied in a normal job. At that point people are getting satisfaction from mastering subtleties of those skill or from achieving meaningful results in their work, the kind of results that put smiles on customer faces.
One of the closest passages to your theme in that entry is:
"The irony of human resource management is that it is premised on raising the capability of the workforce through incentives, whereas the top performers are typically the ones who can best ignore the incentive structure and focus on what they really like and know how to do. "
I hope you enjoy it if you can find the time.
Note: Big fan of the Artima blog, please keep it up.
I think this blog needs a new home. I'm trying to follow discussions on programming, not management science. Looks like Bruce has a new career now so I guess I'll have to find someone else that still wants to talk about software development. Good luck with all that.
> I think this blog needs a new home. I'm trying to follow > discussions on programming, not management science. Looks > like Bruce has a new career now so I guess I'll have to > find someone else that still wants to talk about software > development. Good luck with all that.
Bruce thinks 'management science' is the source of all the world's problems. Given that and a demonstrated lack of understanding of what 'management science' is (BTW: you seem to share his confusion) I think not.
I do agree a new home might be in order. Perhaps a blog site focused on book reviews would be more appropriate.
If you remove Pink's accretion of buzz words, how does his theory differ from McGregor's "Theory X and Theory Y" - which way developed fifty years ago (at a management school) and has been included in the basics of every "Management 101" course ever since?
After so many decades of other some sort of "Reinventing Business" books, it is amazing how so FEW businesses apply what seems so simple: Autonomy, Mastery, Purpose. From the night clean-up crew to the brainy new hires and the gray-haired architects in IT, management lusts for a Soviet top-down and shutup method of leadership application.
Let's assume that "money(investment) seeks safety".
I have never been able to figure out why money would seek safety from idiocy.
As someone who runs one of these "work how, when, where you want" companies, I am struggling with the idea of how to scale such a business. Clearly it's not hard to provide to make a profit by choosing talented developers and setting them free. The challenge in the business is how to keep them busy.
Now, the simple solution would seem to be to take the best of the best and brightest, and make them leaders in their own right. But honestly, they'd probably hate the job and realize if they have to put up with that much BS, they mind as well be the ones making the profit. This seems de-motivating to me. (Or at least de-motivating from the point of working as part of a larger group).
So, I guess my question is, how do you keep these bands of rabid developers entertained as the organization grows? At some point, one leader is not enough, and forming a hierarchy is de-motivating.
> Now, the simple solution would seem to be to take the best > of the best and brightest, and make them leaders in their > own right. But honestly, they'd probably hate the job and > realize if they have to put up with that much BS, they > mind as well be the ones making the profit.
Making the best "leaders" rarely works, as you imply.
Therein lies the key to this, and other similar, threads of late. Fact is, making software isn't scalable in the sense of making widgets in factories; spend money for physical capital (plant and equipment) and double widget production with the same staff; the gain accrues to the capitalist. If you need 1 program, you need 1 programmer (at best). If you need 10 programs, you need 10 programmers. Accruing profit to "owners" is the issue.
If the "owner" figures out a method to increase developer productivity (require a certain IDE/language/framework/database/whatever) such that a program can be produced in 1/2 the effort, then the gain accrues to the "owner", as it should. But if the method is easily learned and acquired, then it becomes part of the developer's mindset. Partitioning the gain becomes a gaming problem. I'll leave it at that. If the developers figure out the method, "owners" have no claim to the productivity increase. Sorry. But since that is not how things work out in practice, de-motivation sets in. Why be smart if "the boss" takes all the gain???????
It's much like professional sports: they don't scale either, and "owners" typically own very little physical capital; arenas more often than not, are provide by government on sweetheart deals. In both cases, return on physical capital is astronomical, for software ventures that prosper.
The answer then, is to pay the profits to the ones who make the profit (actually, that's what Adam Smith, the real one, said should happen, by the way); the developers. But "owners" of software ventures feel that *they*, by virtue of "ownership" are due 90% (or whatever) of revenue. So, most fail.
Industrializing software development has been the Holy Grail since 1950. Hasn't happened yet, and isn't likely to. I would argue that the declarative method of the RDBMS goes a long way toward that goal, for applications which can be data driven. Not all can, such as games and system software.
> Making the best "leaders" rarely works, as you imply.
What always annoys me is the assumption that moving from a developer to a manager is a natural upward career move. The realisation that your manager is being paid a lot more than you are can be very de-motivational if you take the view that you are both experienced professionals and the work you do has a profound impact on the company's future. I've always viewed the senior developer/manager pairing as more of a parallel set of responsibilities.
> I think this blog needs a new home. I'm trying to follow > discussions on programming, not management science.
In about 20 years of software development I have not seen a single project that failed , because the developers couldn't do it. It was in every case management that screwed up things. For that reason software development and management "science" is very well connected for me.
If you have ever seen how a useless banking bloke, that was not fired of uselesness but as a reward for his all-time obedience became head of some bank IT department instead, screw up an entire software development team with his attitude of mindless company obedience, beef-oriented management style, you really believe that Bruce is making a really good point here in talking about autonomy, mastery, and purpose.
Okay, I turned a little passionate, I think. It's not meant to be rough :-).
> In about 20 years of software development I have not seen > a single project that failed , because the developers > couldn't do it.
That's a strange assertion, because in the end the programmers failed, didn't they?
The assumption that customers, requirements, project management, code quality, staff fluctuations, developers and deadlines coexist in harmony and if not there is a single point of failure in the chain of mediators ( the manager ) surprises me in particular when stated from someone who is in the business for 20 yrs, which I'm not.
I always see programmers struggling with other peoples code, with historical artefacts and grown systems, with redundant APIs and wild workarounds, with duplicated libraries, with undocumented and untested code, with dependencies distributed over all modules of a system which is nicely architected - at least on paper. Is it all caused by bad project management? Is there a directive to produce tangled spaghetti code which I've luckily overlooked? Should managers take programmers at their hands like children and hugging them occasionally? Do programmers clean up their mess when they are in idle mode or do they play Tetris, surf in the web and do other useful things in their working time?
Flat View: This topic has 18 replies
on 2 pages