During a recent consulting engagement, I was working with the leadership team on the next phase of their organisational evolution. We were talking about the kind of culture they wanted to build, and the topic of autonomy was raised. The concept of autonomy has been popularised by Dan Pink in his book, Drive, in which he defines it as “the desire to direct our own lives”. In conjunction with mastery and purpose, Dan shines a light on the importance of being in control of our own destiny as a key driver in what motivates us as humans.
But what does that actually mean in practice?
I’m sure that the practical definition will vary from context to context, but I feel that it can be broken down into three key sections.
Tools and techniques – Teams choose their own tools and technology. For example, the type of machine they work on, which programming language they use, or what hosting solution they use. In addition, they are encouraged to inspect and adapt their own ways of working. For example, how they communicate, what Sprint length they use, or whether they practice pair programming.
Problem Solving – This is the what and the how. The Product Manager (or owner) should be a part of the team, working together with engineers and designers to solve problems or take advantage of opportunities. The strategic objectives are set at the top, but the solutions (i.e. the way those objectives are met) are defined from the bottom up. Teams are invested because they helped to form the solution, and they are accountable, because they helped to form the solution.
Dependency Management – And by this I mean, doing our best to remove them altogether. The beauty of cross functional, self-organising delivery teams, is that you have everyone in the team that’s needed to deliver. The team aren’t dependent on anyone else, and can therefore move much faster. We also remove the management overhead. The team themselves are responsible for liaising with anyone outside of this core, as and when they need too.
It’s important to note that giving autonomy doesn’t mean taking away alignment. Communities of practice are a great way to keep ourselves aligned on our technical goals. Equally, if the vision and objectives being set at the top of the organisation are visible and well understood, autonomous teams should be able to pull in the same direction to achieve their collective goals.
Image courtesy of Paul Downey
I’m always surprised when people working to build software can’t choose the appropriate tool or machine. Companies that cite security concerns remind me of when I worked in R&D at a pharmaceutical company, in a life pre-software delivery.
Chemists in this company could generally choose the right tool for the job, though in this case the company was concerned about self-injury from syringe needles. As a result they banned “sharp” needles, replacing them with squared-off, “blunt” needles. Inevitably, incidents went up as people struggled to use the new needles. They quickly switched back to the right tool. Similarly, software engineers struggling and working-around the wrong tools are more of a security risk.