Daniel Pink has done a great job of explaining why paying attention to the three motivating factors of autonomy, mastery and purpose can increase the performance of workers whose tasks require conceptual, creative thinking.
A compelling product vision can help provide developers with a sense of purpose.
A growth opportunity can provide an increased sense of mastery.
In order to achieve high levels of engagement, though, more is required of leadership than mechanical provisioning of these three motivating factors: what is really required is a fundamental belief in the value of individuals and egalitarian teams.
Listen to these words from John Lennon, one of four equal members of The Beatles, talking about his early decision to allow Paul McCartney to become a member of his group:
Was it better to have a guy who was better than the people I had in? To make the group stronger, or to let me be stronger? Instead of going for an individual thing we went for the strongest format – equals.
But what, you may ask, does this have to do with the creation of technology products? Listen to what Steve Jobs had to say about the Apple management model:
My model of management is the Beatles. The reason I say that is because each of the key people in the Beatles kept the others from going off in the directions of their bad tendencies.
They sort of kept each other in check. And then when they split up, they never did anything as good. It was the chemistry of a small group of people, and that chemistry was greater than the sum of the parts.
Still not convinced that the way artists create music has anything to do with the way developers create software?
Let’s try another major branch of music from the 20th century. Listen to this description of jazz from Wynton Marsalis:
Jazz is the most flexible art form ever because it believes in the good taste of individuals. It believes in our ability to make reasonable choices. It takes a chance on our decision-making skills instead of legislating our freedom away with written restrictions and restrictive hierarchies. In jazz, the size of your heart and your ability to play determine your position in the band. The philosophy of jazz is rooted in the elevation and enrichment of people, plain ol’ folks.
Now look at these elements of the Agile Manifesto and its accompanying principles (emphasis mine):
Even though the words are different, I’m struck by the similarity of tone and intent between the two descriptions of these approaches to creation. They both incorporate Daniel Pink’s motivational components of purpose, mastery and autonomy, but they do so from a position of fundamental faith: a belief in the “elevation and enrichment of people, plain ol’ folks.”
The Graphing Calculator Story provides a great example of what developers can accomplish when they can gain access to these three motivating factors. Two highly motivated individuals created an exciting and valuable piece of software out of a sense of mission, leveraging the varying sorts of technical mastery available from a small set of team members, and with a high degree of autonomy.
And, oh, by the way, they accomplished all this not with active management support, but through benign neglect by their management: in fact, their story is particularly interesting because of the high degree of motivation and success these two developers exhibited after their management had canceled their project and terminated their contracts!
Which raises the question of the role of management in the care and feeding and motivation of software development teams.
There seem to be three possible approaches here:
Management has little faith in the ability of developers and development teams to do good work on their own, and so implements a complex system of project reviews, management oversight and organizational checks and balances in order to keep them from running off the rails.
The problem with this approach, of course, is that it does not provide developers with any sense of autonomy, it does not trust that they will be motivated by a sense of purpose, and it does not acknowledge or foster any degree of mastery, and so does not provide any of the necessary ingredients for developer engagement.
Management dispassionately distances themselves from their development teams, trusting that they will do great work when left to themselves.
At first this approach sounds like it is doing all the right things – and it is often an approach that developers themselves tend to ask for – but in truth this too is generally a recipe for failure. Management abdication of all responsibility does not often lead to developer success, because it does not treat organizational leaders with the same respect it accords to developers.
Management plays an active, engaged role in the formation of teams, in hiring and firing the right sorts of people, in choosing the right sorts of projects, in fostering suitable technical mastery for their developers, in developing and communicating a meaningful and helpful sense of purpose to their teams, in helping them connect productively to the larger organization, and in offering them the benefits of their experience through consultation and guidance.
In this third way, managers don’t take themselves out of the game and reduce their roles to cheerleaders on the sidelines, but instead act with their own sense of purpose, autonomy and mastery to help their teams succeed.
For more on the similarities between Jazz and Agile, see the Pagan Tuna post, “Take the Agile Train.”
Traditional rigorous methodologies, and software engineering in general, focus on architecture, requirements and design; coding and testing are considered low-value ‘construction’ activities. In these methodologies, the high-leverage activities are the up-front activities. Agilists reverse this emphasis.
Without work, all life goes rotten. But when work is soulless, life stifles and dies.