On March 15th (2021) I was at DevOps Lisbon Meetup giving a talk on Evolving Tech-driven Orgs Using Sociotechnical Architecture and Systems Thinking. This was a great event where I had the opportunity to share and discuss some new ideas I have been exploring on my journey of learning and "consolidating" the use of systems and sociotechnical thinking as a way to support how we evolve our tech-driven organizations. This is a new talk on this topic and I am also preparing an article to articulate the ideas shared in this presentation (which will become part of my Introduction to Sociotechnical Architecture Series). However, I want to share the main aspects I touched, as this was the first time I combined all these points into a single talk.
The presentation had three main parts:
- Part I: Introducing and Motivations of Systems Thinking
- Part II: Sociotechnical Architecture as a Way to Support Org Evolution & How to Approach it
- Part III: Examples Org Evolution and how to Approach it using Sociotechnical Architecture
In the following I will elaborate on each of the parts. You can also find the video and deck of the presentation below.
Part I: Introducing & Motivations of Systems Thinking
I start the presentation by looking at the main ideas of Product Thinking, which I summarize as the activities of "maximizing the value exchange with the customer". If we want to truly achieve that goal we need to stop looking at all the systems at play in isolation, since understanding comes from looking at the parts and their interactions (core premise of systems thinking). I motivated this using my "Traits to build great Restaurant" metaphor, which I introduced in this article of my "Intro to Sociotechnical Architecture" series. On this running example I gradually show traits that motivate the core aspects of systems thinking, namely: taking a holistically perspective to truly understand the system and from there its parts; consider the relationships of the different parts of the systems; and furthermore the need to embrace change as a normal part of the system evolution and coping with its environment.
Based on this, and if we want to truly achieve the goal of product thinking, we should not purely focus on "understanding What the customer wants"; we also need to make sure the org that is building the product is setup adequately (the "Who" system, or Teams), as also the technical architecture of the product (the "How" system) is aligned with the organization. I emphasize that local optimizations approaches (being Product Thinking as a way to understand the customer and build a better product; DevOps as being a better way for "development" and "operations" to work more effectively together; or Microservices to build a technical architecture) without being positioned in the involving system they are part of, will most likely lead to partial optimizations, or even worse: may lead to degrading the overall system performance.
This is why a systems thinking approach is so important. It provides ways for us to truly understand the whole system and from that perspective its parts (and not the other way around). This is a very important realization of systems thinking.
These ideas may be somehow counter-intuitive, as we tend (and are trained in modern education systems) to focus on breaking systems into parts of focus on making those parts better in isolation, without always having clear what the other parts are doing or how the overall system is doing. However, at the end of the day if all the isolated improvements don't lead to better results for the overall systems (e.g.: our company and end product), or may even degrade the overall results, why are we doing them? This is why it is so important to understand (the "Why" behind) the improvements in our part in the context of the system (whole) that surrounds it. For example, in the running example I had: the restaurant was the system to look at if we want to look at how to improve our dishes. I refer to a great visualization and tweet from Ruth Malan [Systems-Understanding-Malan] to describe the main points elements to understand Systems. The image below shows that slide of the presentation. In a nutshell: we focus on understanding the structure and the dynamics of the system; and furthermore we also look at properties that emerge from the interactions of structure and dynamics (as in the right hand rule from physics) — and also with context.
Part II: Sociotechnical Architecture as a Way to Support Org Evolution & How to Approach it
After motivating the need for systems thinking, I share my current mental model to describe the system ("whole") of tech-driven organizations. I see it as a Sociotechnical System [Sociotech-Arch-Silva], where you have a customer/market, raising demands to the organization/teams, who then build/evolve the product that the customer will use. Figure below shows a representation of the parts and their core interactions.
This mental model motivates the need for Sociotechnical Architecture, which I define as "the holistic co-design approach to technical and organizational systems, given the inherent impact they have on each other".
Given this, and in order to evolve our system with a clear understanding and clear strategy, we must approach it from a holistic understanding, and from there zoom-in to the different systems with an aligned hypothesis for action. I had the following slide on the presentation depicting this idea (credits to Trond Hjorteland for pointing out to this great visualization - originally on [Systems-Thinking-Barton_Haslett]).
In a nutshell we see that we can approach Sociotechnical Architecture by being on a continuous loop of understanding from the holistic perspective, given the input (data) we gather from all the parts (feedback loops). This is called "synthesis", and it is done from the holistic ("emphasis on the hole") perspective. This is key to understand and from there generate "hypothesis" to drive action on the different parts of the system. The hypothesis then drives action on each part of the system. This leads to iteration and as time advances more learnings (data, via feedback loops), which may be used in other iterations of evolution. I have formulated this loop with the following "algorithm".
I have also shared another interesting visualization to depict this evolution of the sociotechnical architecture (which I also use in some use cases - shared in the next section). This can be seen in the following figure.
With this diagram I am trying to depict a way to express the evolution, and elements that trigger evolution iterations. This is still an idea being shaped, but the goal is to make it explicit on the state of the sociotechnical architecture, the triggers we observe and the sort of hypothesis we define from the synthesis of all the data we gathered. I will be sharing more on this on a coming article on my intro to sociotechnical series.
Part III: Examples Org Evolution and how to Approach it using Sociotechnical Architecture
WIP - (will be sharing some notes on the examples soon)
- [Systems-Understanding-Malan] Systems Understanding, Ruth Malan
- [Sociotech-Arch-Silva] Sociotechnical Architecture, Eduardo da Silva
- [Systems-Thinking-Barton_Haslett] Analysis, synthesis, systems thinking and the scientific method: Rediscovering the importance of open systems, John Barton, Tim Haslett