The technology hierarchy of needs
Photo by Edvard Alexander Rølvaag on Unsplash
Why do anything?
Abraham Maslow attempted to answer this question in his 1943 paper, ‘A Theory of Human Motivation’, in which he introduced his famous hierarchy of needs. The idea is that we have some needs which are urgent and pressing (physiological needs such as hunger and thirst, the need for safety from danger), we have others which are more elevated (the need for aesthetic pleasure or self-actualisation), and that we cannot address the higher needs unless we have satisfied the more basic ones. Although Maslow never drew it this way himself, the hierarchy of needs is almost always represented as a pyramid which looks something like this:
Simplified version of Maslow's hierarchy of needs
The theory has been criticised and challenged, but has a continuing intuitive appeal, and is often taught on management courses. If you’ve done any management or leadership training in your career, you have likely seen that pyramid many times.
I believe that we can borrow the concept of the hierarchy of needs to help us understand the answer to a related question: why do anything with enterprise technology? And, more importantly, which things matter most?
Enterprise technology is a field of continuous, strenuous activity. The digital service that you consume as an end user may look simple and elegant, but behind the scenes there will be people writing code, testing systems, managing deployments, building infrastructure, probing security, negotiating contracts, defining architecture, making decisions and so on. And there will be more people managing and leading the first set of people, gathering data, reading reports, assessing risk, allocating funding, finding resources and so on. Over time, some of this work will become automated or delegated to service providers, but the total amount of work never seems to reduce: there is always something else to do, and there is never quite enough budget or resource to go around.
This means that questions such as which things matter most? are constant and important. And we do not always have good answers. Sometimes the true answer to the question, ‘Why are we doing this thing today?’ is ‘Out of habit - we did it yesterday and the day before that.’ Or the answer to, ‘Why are we doing this project?’ is ‘Out of fear - the sponsor shouted louder than anyone else.’ Or the answer to, ‘Why are we fixing problem A rather than fixing problem B?’ is ‘ Out of comfort - we know problem A better.’
This is where I think that a technology hierarchy of needs might be helpful. It won’t settle these questions, but it will at least help us to understand the type of need that we are addressing. It might look something like this:
Technology hierarchy of needs
Once again, this sort of taxonomy can’t make our decisions for us, but it can help us understand the different reasons that we have for action. For example, it could help us appreciate that, while innovation project A seems exciting and attractive, it neglects the fundamental needs that remediation project B would address. Or, it could help us understand that, while we have not eliminated risk, our needs for remediation are sufficiently satisfied that project B is not a priority right now.
I think, though, that we should accept some of the criticisms made of Maslow’s hierarchy of needs. Maslow suggested that more fundamental needs must be addressed before higher needs can be addressed: critics have responded by saying that humans don’t work this way. I think that enterprise technology doesn’t work this way either, and that a balanced investment portfolio and deployment of resources will be distributed across different layers of the hierarchy.
Indeed, I think that we can sometimes find ways of addressing multiple layers at the same time. I’ve long been an advocate of public cloud, and the technology hierarchy of needs helps show why cloud is more than just infrastructure:
Cloud and the hierarchy: one intervention can address multiple layers
If we use cloud well, then it helps us address immediate risk by migrating away from out of date infrastructure, to improve hygiene by getting off the patching treadmill, to optimise resources by matching consumption to demand, to increase agility by giving developers a software defined platform, and enable innovation by giving access to new capabilities.
This doesn’t mean, of course, that migrating to public cloud is always the right thing to do. Indeed, it's possible to go badly wrong when adopting cloud: to favour the higher layers in the hierarchy (innovation and agility) while neglecting the more fundamental layers (remediation and hygiene), and to perpetuate or exacerbate an existing mess.
Rather, it means that, if we map our actions and outcomes to the hierarchy we can get a good understanding of the needs we will fulfil and answer the question, for this and other possible actions: what matters most?
