4 People ↑

No. 25 — Increase Developer Engagement

Daniel H. 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.

• And a high level of autonomy can often be achieved through the implementation of right-sized, Self-Organizing Teams formed so as to implement tight Cohesion and Loose Coupling.

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:

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:

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:

Now look at these elements of the Agile Manifesto and its accompanying principles (emphasis mine):

• We have come to value… individuals and interactions over processes and tools.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• Continuous attention to technical excellence and good design enhances agility.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

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:

1. 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.

2. 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.

3. 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.”

Words from Others on this Topic

Next: Developers are Always Growing