USE THE BEST AND USE THE REST
As the CTO of a deep technology organisation specialising in human computer interaction I sometimes get asked, quite often really, asked about what methods we use for software development. And these questions, well often not really questions but statement questions and imperatives like you must be using Agile or Scrum or Kanban or Kanscrum or Scrumban or Waterfall or Scrumfall or lots of other method portmanteaus. It is very rarely that someone will ask questions like, ‘What are you actually trying to create, what is the outcome you desire, or what is the purpose of your work?’
And in response to these questions and declarations masquerading as questions, my response is always ‘we use the best and we use the rest', and that’s what we do we leave it up to the developers to choose a method that they think is most appropriate to arrive at our desired outcome‘, which naturally generates the next question which is 'doesn’t that just lead to anarchy'? The conventional view of anarchy is a situation that is a complete loss of control, usually involving large-scale rioting and widespread destruction. Or in some cases, ripping your T-shirt and sticking safety pins through your nose.
But anarchy is such an interesting word. It emerged from the Medieval Latin anarchia, which itself emerged from the Greek anarkhia, literally meaning ‘lack of a ruler’. And that’s where the confusion can begin because the conventional view of anarchy is that it means lack of a leader rather than lack of a ruler. There is a big difference between a ruler and a leader. The clue is in the name. Rulers are all about rules, about regulations, about rigid straight methods. That’s why we also use the term ruler for a measurement straight edge. Rulers provide something that all humans tend to crave and that is certainty, a straightforward outcome, a Euclidean perspective.
But when you are developing software, developing technology, deep technology, you need to move beyond certainty and to step into uncertainty where the outcomes may not be so straightforward. And that’s where you need a leader, not a ruler, because from a psychological perspective, a leader is a person who steps into uncertainty, makes it more certain, and by doing so, invites others into opportunity. And if you’re up for a wee bit more etymology, our word ‘leader’ originates from the Old Norse ‘leitir’, meaning a person who inspires you to go on a journey of discovery.
Even though developing software in a leading technology company is often all about stepping into uncertainty, many organisations are always trying to make it more certain, more predictable, more dare I say it, more SAFe. Perhaps not safer, but certainly more SAFe. The uncertainty that we step into when developing software is largely the uncertainty that we all experience when engaging with other human beings. And not just engaging with our human beings but also engaging with our own uncertainties, the aspects of ourselves that we are uncertain about.
And that’s why we have all these rule-based software development methods and frameworks. To make software development more certain by trying to make engaging with other human beings more certain. To reduce uncertainty by trying to make human behaviour more predictable. This rigid rule-based approach, however, tends to have the opposite effect to that intention of producing predictable human behaviours.
What happens instead is that these rule-based methods, focused on reducing uncertainty in human relationships and minimising the risk of anarchy, actually result in the opposite of anarchy, which is hierarchy. And like most simplistic approaches to complex human psychologies, the outcome is usually very different from the intention.
And for even more etymology, the ‘hier’ in hierarchy originates from the Late Greek ‘hier’, meaning holy or sacred, with ‘hierarchy’ meaning ruled by a high priest. And throughout history, high priests inevitably promise idealised outcomes that never actually materialise. The same happens with software development methods based on the premise, or the promise, of an idealised outcome with the mistaken assumption that the people involved in producing that idealised outcome will have perfect and predictable behaviours as human beings.
That mistaken assumption often leads to a poor outcome, which in turn is blamed on poor human performance. After all, an idealised method or framework cannot be wrong; it's always the humans implementing it in the real world who must be wrong, not worthy enough, not following the sacred texts and rituals. The rules in the rule-based approaches are often viewed as sacred commandments bestowed from on high by some method Messiah. Anyone who questions these Messianic approaches to software development Is usually viewed as some sort of anti-Messiah.
As a technology developer, how do you move beyond these rituals and why do we even have rituals anyway? The fundamental psychological function of ritual is to provide meaning. Rituals provide a comfort zone of certainty by providing a sense of meaning. But when rituals become disconnected from the actual reality, where people no longer identify with any meaning they might have held, those rituals become meaningless. You just end up meaninglessly going through the motions, on a death march to the promised land, perhaps satisfying a hierarchical ruler but on a journey that is leading nowhere.
Meaningful moments and actions often end up becoming ritualised but the meaning that they hold is usually dependent on the psychological space where the initial meaning emerged. Actual meaning tends to become habitual meaning and then protocol meaning and then ritual meaning. Habitual ways of working often form in the psychological space of mutuality in a team. At a wider social level in an organisation, meaningful actions tend to be based on protocol rather than actual meaning and at a cultural level, once meaningful actions become ritualised with no sense of context. What may have held meaning for seventeen white men in a room in a ski resort may not have universally applicable meaning to the technology that you are specifically trying to develop.
The key to building meaningful technology is exploring and understanding the actual reality of the connections of the people developing that technology. Not the ritual reality, not the protocol reality, not the habitual reality but the actual reality. Engaging with the actual reality of human relationships in a dev team is not about daily stand-ups or velocities or estimates, it’s about creating the space for fundamental human qualities to emerge. Qualities like being courageous, being resourceful, being generous, being helpful, being compassionate.
Building great technology is far more about being able to connect all these great human qualities in a dev team rather than trying to force them to go through the motions of some hierarchical ritual. Engaging with the actual reality of human relationships means that you have to step into uncertainty and move beyond the rule-based rituals intended to provide certainty. That person who steps into uncertainty and invites others into the opportunity of the uncertainty is an actual leader. They may not have the title of leader in their job description or in the hierarchical position in an org chart but their willingness to step into uncertainty is what identifies them as a leader. They may only be a leader for a few minutes if the uncertainty space is small, they may be a leader in a very specific space because that space seems uncertain to the rest of the dev team.
And as you step into uncertainty and become a leader, even very briefly, the qualities that will serve you best are those qualities that make powerful human connections, like courage, empathy, ingenuity. One of the scariest things about stepping into that leadership space, into that uncertainty space Is that you’re not just stepping into uncertainty in the outer world, you're stepping into uncertain space in your inner world. That means you don’t just have to embrace the human qualities in the connections you make, you also have to embrace those human qualities for yourself.
You need to be compassionate to yourself, generous to yourself, helpful to yourself. It’s a lot easier to give yourself a hard time, to be critical of yourself, to feel all that impostor syndrome stuff, the feeling that you are just not worthy. If you are going to connect at a human level with other humans, you need to be open to connecting with yourself at a human level too. The more connected you feel with yourself, the more likely it is that you will become more comfortable stepping into uncertainty.
Connecting with yourself at a human level and with others at a human level naturally creates psychologically safe spaces. Hiding behind ritualised hierarchical methods has the opposite effect and creates spaces where people do not feel safe to connect at a human level because they are being held to account against some seemingly sacred method rather than as their human qualities as a human being. It’s hard to feel psychologically safe when you are being overseen by a ruler, or sometimes a variety of rulers, whose rules conflict with each other.
There are seemingly endless articles, books and courses describing the dichotomies and differences between managers and leaders but that is a very lazy perspective. The real dichotomies and differences are between rulers and leaders. It may be that managers and rulers are often confused because managers manage by the rules but managers are usually quite far down in a hierarchy and so are just following the rules of their hierarchical ruler far above them.
You can see why rule-based methods have a certain appeal though. They create a sense of certainty, usually a false sense of certainty. But moving beyond hierarchies doesn’t mean that you will end up in some chaotic free-for-all. Instead, dynamic structures will emerge as a dev team self-organises around producing an actual meaningful outcome. These dynamic structures form as humans connect across their edges.
And as we know from history, and from the present day, some people like to be rulers, to have other people serving them, to be able to run a straight edge across the servants because it gives the rulers a sense of psychological certainty. Even though they can’t control themselves, they can still control others. It’s a choice you have the opportunity to make. You can devote your efforts to building a hierarchical empire where workers are treated like servants.
But rather than doing that, we should leave all the serving to the servers, to the machines in the server farms, and instead use our human qualities to step into uncertainty and invite others to opportunity, like true leaders do. And that first step into uncertainty is never just one step, it becomes a series of steps, a journey of discovery, a purpose, that leads you to the meaningful outcome that you truly desire.
So from a deep tech CTO’s perspective the best method for developing technology, for developing software is to create the space for humans to connect at a human level, to let them enact, embrace and express their very human qualities. And if you need to use other methods for a specific piece of work, then use the rest of those methods. Use the best and use the rest.