Freedom is not free: managing your cognitive and operational economies
Freedom is not free.
Let’s unpack that apparently paradoxical phrase into something a bit more unwieldy, but a little clearer.
In the context of enterprise technology, freedom of choice comes with a cognitive and operational price which we must be sure we want to pay.
The question of freedom versus control in enterprise technology has been debated with varying degrees of heat and passion for as long as the field has existed. Centralised corporate IT functions usually like control. They like to be able to manage costs and risks, to limit the complexity of their architecture and their supply chain, to strive for confidence and predictability. By contrast, development teams and product teams typically like freedom. They like to be able to pick the technologies, frameworks and ways of working which suit them best, to innovate freely, to use their skills and express their professional expertise.
I have written previously about how this tension can be addressed by dividing our architectures into platforms and products (and people, performance and practices). In this model, platforms provide reliable, homogenised, commodity services, and products are built with a high degree of freedom on top of these services. However this doesn’t fully resolve the problem: we still have to figure out what is a product and what is a platform, and decide just how opinionated and mandatory we want our platforms to be.
I believe that one way to approach this problem is to remember that in enterprise technology, our scarcest and most precious resources are time and talent, and that we must therefore make the most of our cognitive and operational economies. Our cognitive economy is the distribution of our limited attention span, decision making capability, and ability to hold concepts in our head, and our operational economy is the distribution of our limited capacity to perform operational tasks, such as configuring infrastructure, managing reliability and responding to incidents.
We manage these economies all the time, even when we seem to enjoy complete freedom. If I am coding on a personal project, I feel as if I have infinite freedom at the point when I first sit at my keyboard. In practice, I have already constrained my freedom: I have chosen to start my project using a particular machine running a particular operating system. As soon as I save my file with a particular extension, .py or .java or .rs or something else, I have chosen to work within the functional and syntactical limitations of a particular language. Once I import a framework or a set of libraries, I have chosen to stay within their conventions and conform to their APIs.?
领英推荐
These choices may not feel like constraints, because it is obvious that the price of not accepting those constraints would be extremely high. The only way to avoid the boundaries of a framework would be to extend the framework or write one myself. And I don’t have the time for that. If I don’t want to stick to the syntax of a particular language, then I had better develop a new one. And I don’t have the time, skill or inclination for that. I’m certainly not going to build an operating system or construct my own physical machine. In all of these cases, the trade-off is so obvious as to not be worth mentioning.
Furthermore, as I start coding, I immediately make choices which further constrain my freedom. Choosing to abstract a function in a particular way will determine how I interact with that function for the lifetime of my code (unless I refactor it). Choosing how my first variable name will set the style for the rest of my project (unless I want my code to be hard to read). All my future work is determined by the choices I made in the past and, if they are good choices, they reduce the cognitive and operational load of my future self.
Things get more tricky as we move to different layers of the architecture where the answers are less clear. Which cloud provider should I host my product on? Which services should I use? How should I configure my network? How do I secure it? Fans of central control will assume that the answers to these questions should be predetermined. Fans of freedom will want to reserve these choices for themselves.
I do not pretend that there is a perfect answer which will fit every choice at every layer of the stack, but I do believe that it is helpful to ask the question: what cognitive and operational work results from this choice, what is the value realised by that work? A useful principle to adopt might be that we exert freedom at the layer of the stack where it delivers the most value.
There is an implicit deal here between fans of freedom and fans of control. Fans of control should not merely optimise for supply chain efficiency, architectural simplicity and predictability: they should optimise for maximum cognitive and operational payback. Fans of freedom should not merely seek it for its own sake: they should figure out where freedom is valuable, and accept where constraints are valuable.
Freedom is not free: it is a precious resource that has a price. In enterprise technology, we should deploy it where it matters most.
(Views in this article and my own.)
Chief Tech Recruiter | Helping Tech Leaders hire the top 1% of software engineers from the Philippines.
6 个月Great point! Thanks for sharing.
Chief Technology Officer at Llywodraeth Cymru / Welsh Government. Do not cold call, please.
7 个月Very well put.
Data Architect at Australian Red Cross Lifeblood
7 个月It is interesting that our modern western society is constructed as a needs based system, whereby the needs of: - National Security is greater than that of Capitalism, which in turn is greater than that of Democracy. In the modern organisation we appear to faithfully reproduce this same construct as: - Security > Control > Freedom. There is comfort and uncertainty in equal measure across each and any of these dimensions. The trick would seem to be as leaders how to collectively connect / disconnect our stakeholders to each of these dimensions as the situation arises. Notions of competing resources, talent and time are secondary to how quickly our leaders reach consensus on the significance of a situation. The organisation which "wins" in the long run typically reaches consensus faster and more consistently than its competitors, connecting and disconnecting as cleanly and efficiently as possible. As most of you seem to be architects the task seems: design and oversee the building of these networks.
Head of Strategy and Architecture
7 个月Great point. The trick is in knowing if that decision we are making is the right one. And that is where the problem lies. The internet and social media sites are full of differing points of view and added to that the changing pace of technology makes that decision harder. Especially if that first decision limits future choices.
Using data and insights to deliver results, reduce risk in Finance, Regulatory and Technology transformation and change
7 个月I do like your articles David. I always think there is a balance, a deal to be struck - teams who demonstrate maturity and commit to mitigating risk in line with the organisation's requirements and can demonstrate this through data and working practices, should be given more freedom. Teams who are not able to do this, should be operating within a more platform based environment where the platform embeds the required controls.