When we talk about tech, we usually talk about the software (or infrastructure) itself. Do we need Kubernetes? Is Vue better than React? At conferences, speakers show us how to design microservices or Kafka topics. Case studies tell us how an event-driven, cloud-native architecture helped an organization meet its goals.
What we forget, or perhaps never really knew, is that we build technology by developing the people who can design, deliver and maintain that technology. We build technology for other people to use. People deliver technology by thinking and acting together.
Without people evolving their expertise, most technology would quickly become obsolete. If people stopped using software, we wouldn’t need software.
Technology is the fruit of human thinking and acting, plus some raw materials we’ve fashioned to help us. Everything in production is what people thought, discussed and did. Nothing in production grew there on its own.
If people disappeared from the Earth, there would still be trees and trout and mushrooms and probably more species of animals than there are now. But there would be no technology.
People are not machines (“resources”) that produce code. They are part of the system that produces code. People working together is the garden, the ecosystem, that enables the production of software. When we talk about technology systems … we are always, also, talking about people systems. There isn’t a (matterful) difference.
Nothing in technology isn’t sociotechnical. Delivering something different to production depends on first changing the way people think and act. The structure of our thinking and communication is what we build:
Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.— Conway’s Law
Unfortunately, the sociotechnical reality doesn’t fit our business-as-usual approaches. Most organizations view people as mechanisms, cogs in the machine. They don’t approach, for example, digital transformation by structuring human-centric systems of support that enable people to thrive as complexity increases. They design microservices.
People who teach us about sociotechnical systems thinking are working to change that.
Open systems theory (OST) is an academic subject that has been studied for decades. It helps us understand why Conway’s law is experientially accurate. Looking at technology from a sociotechnical perspective helps us break down the artificial barrier between “hard” and “soft” science. We see the organization as a system that designs and delivers technology systems. We recommend changes to the structure of the organization as a precursor to changing technology.
As knowledge workers, there is no avoiding our ever-increasing integration with technology. This means that there’s no avoiding the need for more intelligent sociotechnical systems. What do humans need, and how will they flourish, as they adapt to ever-increasing complexity?
Thriving in the Complexity of Software Development Using Open Sociotechnical Systems Design
by Trond Hjorteland
This article is a great place to start. You can also read other articles in Trond’s blog.
Why the Sociotechnical Architecture is Important
by João Rosa, Kenny Baas-Schwegler
Here are two talks from authors who are writing the book on architecture from a sociotechnical systems perspective. The other is Sociotechnical systems design for the “digital coal mines” by Trond Hjorteland.
Why Socio-Technical Practice Is So Important For Engineers
hosted by Jessica Kerr
Dave Farley’s Continuous Delivery Youtube channel isn’t really a podcast — but close enough to recommend for this edition.
taught by João Rosa
A 2-day workshop on open sociotechnical systems design, which prioritizes people and practices in the design process.
“There is no ‘disembodied’ technical system; it is inevitably joined to a social system because software is written by people for people and the ICT industry needs to be educated to handle that dimension as well as the technical one.“— Trond Hjorteland