What makes a software project a good one to work on? Surely, it’s those where we feel motivated. As professionals, we can — although not always — feel some shame to admit a lack of motivation about our current work. To blame ourselves for a lack of motivation would imply that motivation comes intrinsically from within, no matter what the environment is we’re working in.

It would be great — for highly motivated individuals — if we could leverage the same amount of motivation in all situations, but it turns out the human condition is more complicated, and the context we’re working in matters.

Daniel Pink in his book Drive, makes the case for Autonomy, Purpose and Mastery, forming the basis of what he calls Motivation 3.0. In this post I’m going to delve into this, coming at it from my perspective of working in a software consultancy, that is expected to place individuals that are highly motivated.

Purpose

I recently saw the Michael Jordan documentary The Last Dance on Netflix, where you can see the astounding level of motivation that Michael Jordan and the players around him had, for their final NBA basketball season together, before the team was to be disbanded.

The Chicago Bulls head coach gave each season a named theme to instill an underlying sense of purpose that would foster a togetherness and joint focus. The final season was called The Last Dance; an impassioned plea for getting the team back out on the stage one last time to deliver together. This message clearly resonated with the team as they won the NBA finals for a third time in a row.

A sense of purpose is what keeps humans engaged and invested. On software projects the team’s mission will sometimes match the broad mission statement the company has as a whole. At other times it can be more discrete and tailored to the situation at hand, like the The Last Dance. It can also be set at the level of the individual joining a project, i.e. to disentangle the codebase, help with project planning, to provide mentorship.

For software consultancies working on a client project, the mission can’t be to simply augment staff with more staff, a mission statement that no one will find compelling. We need to ask, what is the X that the consultancy is going to help the client achieve? Once the mission is then set, it needs to be made real, giving the consultants what they need in order to meet the brief. This could involve having the principal consultants help set the terms of the engagement before it starts, by way of running discovery workshops and then to assemble a well matched team. There can’t be a disconnect between those framing the project and those executing it.

Above all, what is needed to help a team fufill a purpose is autonomy.

Autonomy

The Agile manifesto promotes People over Process, with process being there to support and to help, never to impose. Yet this is so often what software projects get wrong, where the project management of Scrum or XP is really manifested as miniaturised Waterfall, reminiscent of the days of nineteenth century scientific management, squashing the dignity and humanity out of the individual.

Developers are now increasingly seeking to work for companies with a developer led culture, where developers are entrusted to lead software development projects, as Chief Programmers, as discussed in the Mythical Man Month book. In this model, proposed by Harlan Mills, other roles such as project managers, analysts and testers are there to support developers, with developers given more responsibility and leadership roles.

This model appeals, where developers are highly valued and selected accordingly, rather than being seen as an exchangeable commodity. Software engineers crave the autonomy this gives as it allows them to exercise creative control and to optimize their path through the work, bringing efficiencies to a project.

As with anything however, we can take this too far. Programmer Anarchy is about empowering complete freedom and autonomy to all developers. The downside here is Conway’s Law coming back to bite, where the software architecture starts to resemble a more chaotic and splintered software development organization, leading to a Cambrian explosion of polyglot microservices.

Autonomy means entrusting developers with greater responsibility — but it doesn’t imply a lack of hierarchy. Strong cohesive leadership by the chief programmer is still required. Software is not a democracy.

Mastery

A true vocation calls us out beyond ourselves; breaks our heart in the process and then humbles, simplifies and enlightens us about the hidden, core nature of the work that enticed us in the first place.

— poet David Whyte

Mastery needs space. As Rich Hickey espouses in his Hammock Driven Development talk, we need to be able to step away from the computer and dedicate more time to undisturbed thinking. This allows us to go deeper into our mastery of the domain and the technical solution space, which will benefit the project in the way of a simpler design with fewer bugs. This is because we can spend more time in analysis, reducing our misconceptions and considering various different approaches, and rooting out the unknown unknowns.

That said, not every conversation into understanding will yield a benefit for the project at hand, and this needs to be accepted. A true vocation is a calling into the unknown and we draw motivation from descending deeper into it, which transcends any singular assignment. Over the course of our careers, practice will take us to the levels we are capable of attaining.

This is true also of software consultancies, where the present-day clients will be the ancestors of success for future clients. On the face of it, this is a tough message for the clients, but it cuts both ways: the clients of today will be richly rewarded by the learnt experiences - both successes and failures - of previous clients.

Conclusion

There are projects that suffer from a deep lack of motivation, commonly known as bodyshop projects or, in polite corporate speak, staff augmentation. These terms convey a message of the intrinsic humanity being bypassed, where a skilled developer is consigned to being a +1 in a spreadsheet, quickly finding themselves performing pre-defined tasks, without autonomy, without a strong sense of purpose, and without the opportunity for mastery. It is at this stage that the Mythical Man Month anti-pattern of adding more +1s to the spreadsheet is reached for, and more bodies are cycled in.

We can do so much better. We want our projects to be successful, and for that to happen we need a project with a clear mission and a highly motivated team. In order to achieve that we must give people the opportunity to master their skills, the autonomy to make their own decisions, and a sense of purpose to keep the team and individuals engaged.