Is there a human shaped hole in your technology plans?

If you’ve been watching The Last of Us then one of the things you will have noticed (alongside the great acting and story) is the eerie feeling of a human world with no humans: an empty world except for nature, a few survivors and, of course, the infected. I sometimes get that same eerie feeling when looking at plans for technology change: where are all the humans?

This is strange, because humans have been at the heart of new movements in the ways we build and run technology for decades.

The Agile Manifesto was published in 2001. Almost all of its 73 words (including the title) concern people, behaviour and communication rather than technology and tools. (Indeed, people and behaviour over technology and tools could almost be a line from the Agile Manifesto.)

The first DevOps days conference was held in 2009. You can still go and read the program (although if you try to follow the links to other sites in the reactions section, you get a great demonstration of link rot). While a lot of the agenda was clearly quite technical, much of it was focused on people, behaviours and communication. Do user stories really help express non-functional requirements? What does automation mean for sysadmins and development teams? How can practices followed by software developers be applied to operations?

The first edition of the Site Reliability Engineering book was published in 2016, and, amongst discussion of logging, monitoring and traversing infrastructure stacks, the heart of the text is about people, behaviour and communication - not least, how to create psychological safety.

It’s puzzling, therefore, that, when we plan, architect and design technology systems, we leave humans out of the picture so frequently. (I’m about to describe some common mistakes: as ever, I have to confess that I am guilty of making all of these mistakes more than once.)

We build program plans in which the only role of humans seems to be to fulfil resourcing needs: to determine whether a task that requires 100 days of effort will need all those days, or whether it can be completed in 50 days. Humans as denominators.

We build solution designs in which humans only appear at the edge of the diagrams, as symbols for internal or external end users. These humans are, of course, very important: they’re the reasons we build the systems. But those systems don’t get built or operated without some other humans.

And we build representations of our architectures in which humans are invisible. If we believe those diagrams, then our companies are run by nothing but autonomous systems arranged neatly in layers.

We could speculate about why, despite all our talk of culture change and ways of working, we persistently make the error of leaving humans out of our plans, designs and architectures.

It might be because machines and systems are easier to count and represent than humans. It could be because the behaviour of machines is logical and predictable (when they work properly), whereas human behaviour is messy and surprising (when we let it be). It might even be because we secretly hope for a day when the machines can run themselves.

(As an aside, the current wave of speculation about AI making coding obsolete seems very familiar. For what it’s worth, let me add a pebble to the mountain of commentary written on this subject of ChatGPT and other LLMs over the last few months: do I believe that statistical models derived from content created by humans are suddenly going to remove the need for content created by humans? No.)

Whatever the cause of this omission, it creates problems. It leads to the misconception that the aim of a software project is simply to deliver software, and not to create everything, including the team that owns that software. (The Agile Manifesto favours working code in production; it is implicit that working code does not work outside a technical environment and a human environment.) It leads us to design solutions which are technically feasible, but which we don’t have the human capability to manage. And it leads us to believe that we can modify our architecture by changing our systems, without changing our organisation and behaviours.

I think that we can begin to address this problem through an exercise of imagination. Whenever we hear the word ‘system’ (or application, or micro-service, or product, or any term suits the context best), we should think of that system holistically, including software, hardware, and all of the humans that build and run it, along with their behaviours and communication styles. Whenever we see a plan which is supposed to result in a new or amended system, we should ask ourselves how this plan creates or changes the work, roles and lives of the humans that build and operate that system. And whenever we see an architecture that claims to describe an enterprise, we should ask who the people are that build, run and live in this architecture.

We should train ourselves to think of the technology environment in the same way as we think of the built environment: those cities in The Last of Us feel strange because we expect to see them full of people; our systems should feel strange if we can’t see the people. If we can pull off that feat of imagination, perhaps we can start filling the human shaped holes in our plans.