Paul Hammant's Blog: Alignment and Autonomy and Quorums
TL;DR: From the “Command Intent” field of science: We align staff through training, set constraints, THEN grant autonomy towards goals. Quorums of developers gaining autonomy from day one of employment without any prior alignment/constraints from higher ups is a recipe for disaster. #APaulHammantSummary based on a push by my boss Kevin Behr in 2014. Note too, that Google never made this mistake.
Also (update after written):
Spotify has a great narrated animation from a few years ago on their engineering culture. Two in fact. Both of these are quick primers to how things happen in high functioning modern dev teams. Lots of companies broadly do what Spotify outlined.
One two-axis chart stands out on “alignment and autonomy”:
I’ve added some text in red which is from the narrative.
The top right is where Spotify strived to get to. It is also what Stephen Bungay talks a lot about in The Art of Action written in 2012 and a fantastic read.
Mavericks and Loose Cannons
I wrote previously on Mavericks and Loose Canons. Where do those two types of people fit in?
The true Maverick is maybe going to do something more important (by their determination) than cross the river - as soon as your back is turned after giving the order, and they care little for your authority and reaction when you find out.
The Loose Cannon is going to convince themselves part way into the objective you’d set that something is more important. They expect your praise when you get back though. They’re also confused and hurt when they get admonished instead.
Perhaps the mistake was giving the order and walking away. Getting people to reflect back what the instruction is should be part of the solution to this problem. As is making sure you have the right people to start with. Hopefully, you have hired people who are experienced and trained before they arrived in your organization, and maybe staff should receive further training after joining. The Agile leanings of Spotify’s Pods mean that the group is more flat in terms of how they determine solutions. You’re still going to find that people are wrong for the role, though. In software development, there is always a chance to reconfigure for the next iteration/milestone.
Ends justify the means
A large chunk of the history Bungay’s in book concerns war, where it is the outcome that is ultimately more important than the how you got to that moment. That “winning” the battle/war moment versus “losing” . The leaders who put their armies to war, were focused on the outcome, and to various degrees believed that the end justified the means - damage and losses on the way to victory were acceptable.
In software development, the ends do not justify the means (unless you’re a sociopath). So the process of building aligned and autonomous teams is the ongoing process, and the goal is fewer mistakes (at various levels) during software development and a greater throughput. Shorter and shorter cycles times too. Damage and losses on the way to “victory” are acceptable too, but only if something was learned from each experience and the recognition of mistake was made early, and undone (fail fast). Oh and that the whole team was improved for the mistake (no ‘bad blood’ or actual deaths).
Mavericks are autonomous but not always aligned (and they know it). Loose Cannons think they are aligned but are not always. That is tragic for Loose Cannons is that they mean well.
New quorums (arriving on the battlefield / in the dev team)
Bungay talked of Napoleon’s Army in 1806, that beat the Prussians:
Bob “Uncle Bob “Martin said that the size of the workforce engaged in software development doubles every three years.
There is risk that a quorum of people may arrive in the organization who have been trained in a different way, to they way you’re going ahead with. There is a possibility that alignment is lost. If the rate of acquisition of new talent is gradual enough then you can keep the alignment, though it may end up consuming a lot of time to do so. One thing that troubles me personally is the cyclical resurgence of crazy branching models (me being Mr Trunk-Based Development and all), and that every year I have to start again with education programmes for colleagues and clients. That’s just one topic I have to battle on cyclically. Fast builds is another. Small story sizes are one more. These things not being taught before programmers reach the workplace, if true, is troubling. At least people arrive with SCM skills now, which was not always true ten years ago, and very rare 20 years ago.
To close out this article, Jez found himself in a similar conversation on Twitter yesterday on bringing new entrants into the field of software development:
