Thursday, August 27, 2009

What Motivates Creative Thinking?



A friend and former co-worker of mine pointed me in the direction of this video of Dan Pink speaking at this year's TED (Technology, Entertainment, Design) Talks, in which Mr Pink (not to be confused with the character from Reservoir Dogs!) provides some evidence-based thoughts on motivating creative thinking. I encourage everyone to go check it out.

After watching it, I started thinking about my own experiences in the software industry. Pink's Autonomy-Mastery-Purpose summation certainly matches what I've seen in the best of scenarios. And, of course, those three characteristics mesh perfectly with the principles of self-organization, continuous learning and prioritized backlog that Agile are built upon.

From what I've seen, it's definitely no easy feat to create and sustain a culture in which all three of them are:
  • valued in word,
  • valued in deed,
  • committed to at all levels of the organization, and
  • not sacrificed in the name of "expedience" or "meeting a schedule".
Some simple examples of where I've seen them compromised would be in management clawing back control from teams whenever they're unhappy with the outcomes, pressure being applied to produce substandard work rather than allowing a maintainable design to be implemented, and failures to provide a consistent vision or message for a project or product. Those are all leadership shortcomings, but you can also see it at the developer and tester level when individuals on teams refuse to take responsibility for their mistakes (the "downside" of autonomy), become lazy about following through with Retrospectives, communities of practice or just general inspection-and-adaptation, or give up on their principles at the first sign of resistance. Like I say: it's much easier to fail at autonomy, mastery and purpose than it is to succeed.

I don't believe that those who fall down in the attempt, however, realize just how much they're losing by not trying harder. For one thing, you only get so many chances to introduce that kind of culture, after which you lose your credibility for a long time to come. Even when we were introducing Agile to our company in 2006, I met considerable resistance from folks who'd been there long enough to remember previous attempts at reorganization and empowerment, and were thus doubly skeptical of the results. There's also the flawed "we can't afford the schedule hit" aspect to failure in this area. One executive I came into contact with was always saying, "We'd love to build that kind of culture but there just isn't the time." Ironically, of course, whatever deadline was being worked feverishly toward would be missed (and missed and missed) anyway because of all the problems being ignored, meaning that the much-needed improvements were put off for no reason in the end. It becomes a vicious circle that's awfully hard to break out of.

The most creative work I've seen has always come from those who are given the latitude to wander down many paths, the tools and training that they themselves believe they need, and a general - rather than specific - direction to follow (so, "what", but not "how"). In some companies, I suppose, that sort of revolutionary work may not even be necessary or desired. But for the rest of the IT world, leaders do themselves and their organization a terrible disservice whenever they believe, as Dan Pink illustrates so capably, that they can simply dangle a reward in front of their heavily-supervised employees' eyes at random points in time and achieve greatness. When you do that, you end up with the most unimaginative of solutions, like a candle stuck to a wall with pushpins, dripping wax down onto your table.

No comments: