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.

The Relationship Between Trust And Leadership

An article I was reading this morning got me thinking about how the quality of leadership within an organization relates to the level of trust that you'll find there. I'm not sure that it's a perfect model that I've come up with, but it seems to fit most of the scenarios that I've observed in my travels.

Basically, the relationship seems to be quite simple: the better the leadership, the more trust exists. This is one of those situations where you can perceive the effect (trusting and trustworthy players vs distrust between parties) in direct proportion to the causal factor (effective vs dysfunctional leadership), but it also can work in the opposite direction at times. I dedicated an entire chapter to this in my second AgileMan book (Issue # 46: Who Do You Trust?) but I think that I was still too close to the proceedings at that point to really see just how tightly tied together the two things were.

For example, a leader may start off willing to extend a great deal of trust out to his or her employees, only to feel "betrayed" by them if the same good faith isn't extended back. Imagine a team promising to complete some vital feature, giving "thumbs up" reports on it throughout the Iteration, and then falling well short of the goal in the end. That kind of result can cause a well-intentioned leader to change gears and begin compromising principles: becoming more of a micromanager, reducing the amount of freedom allowed to the team, or just generally dictating more of "how" on future work. In one way, I suppose, we could still characterize that unhappy outcome as being the result of poor leadership. After all, in an Agile environment at least, we expect leadership to emerge within teams, as well. So in my sample scenario, the team that "green-shifted" their situation right up until the end failed to demonstrate the type of maturity, honesty and transparency that we'd expect from a well-performing Agile group.

Just as likely, though, it's the manager or executive who failed to fulfill his or her responsibilities that leads to the breakdown. I certainly saw numerous instances of that in my role as Agile Manager, and in each case the result was a weakening of the bonds of trust between the organizational layers of the corporate pyramid. If a Product Manager promises to be available but isn't; if an executive fails to provide a vision of where the company is going; if team members are blamed for dropped balls that were actually someone else's responsibility... each of these qualities of poor leadership eat away at the foundation of trust within the organization. And that's not just a bad thing on paper, either.

Among the many ways in which a lack of trust hurts an organization, I saw:

• time wasted as people (in both groups) sat around and bitched about how they couldn't trust the other group any longer
• wasteful defensive measures planned out and enacted as ways to guard against the possibility of being let down or thrown under the bus by the other group
• the baggage of past betrayals brought up, again and again, in almost every new interaction, making it nearly impossible to ever achieve a fresh start
• a complete reversal of the empowerment model that Agile depends on, as more and more of the conversations would devolve into "contract negotiation" as each side would want detailed recordings of exactly what was discussed in order to fend off future allegations of failure
• a very unhealthy "us vs them" attitude that benefited no one and drove morale to continually lower levels everywhere

I suspect that superior leadership can overcome many of these threats, but it's definitely not easy. Each time I was a Feature Lead, for example, I felt the unmistakable pull of distrust exerted between me and my new team. They weren't sure that I wasn't there to take over and remove their decision-making powers, and I was never quite confident (at first, anyway) that they would do what it takes to get the job done. I'm pretty sure that's a typical place to start, and it's no wonder that so many people in leadership roles find it impossible to resist that gravitational force that's urging them back to familiar, top-down approaches.

What that tells us, of course, is that choosing your leaders in an Agile environment is all the more important, and not something that should necessarily be done by the same old rules of the past. If you make that mistake, chances are you'll be dealing with trust issues for years to come.