Welcome to the digest #4 of my "Technical Leadership and Architecture insights" (or TLA_insights for short).


This is a long overdue "digest"... this delay is mostly caused by quite some other activities going on. Nevertheless, here it is a "digest" of four records I added over the last few months to my TLA_insights: two on Product Thinking and two on Systems Thinking. These are entries that contain a lot of very interesting insights.

Most of these entries are direct references and preparation materials for several talks and articles I worked on over the past 2-3 months. Namely, my Domain-Driven Design Europe (DDD EU) talk on "Sociotechnical Architecture as Enabler of Product Thinking" and a talk I gave for DevOps Lisbon Meetup entitled "Evolving Tech-enabled Orgs Using Sociotechnical Architecture". I had a lot of fun on these two talks and there are a lot of interesting discussions and follow-up activities. I want to highlight one, namely an interview for InfoQ with Manuel Pais (co-author from Team Topologies), which was placed as a follow-up from the DevOps Lisbon talk. In this interview we go into the subject of why DevOps is Not Enough for Scaling and Evolving Tech-enabled Organizations, and what other things we need to consider to address that. I have published a new article on Sociotechnical Architecture and have two others being prepared on the same topic, so stay tuned for more.

I hope you enjoy these four entries! If you found this issue interesting or useful make sure to subscribe to the newsletter or follow-me on twitter so you get notified of new records in these and other topics. I hope you have fun and find some interesting insights here. Don't hesitate to contact me if you have questions or want to chat about these topics.

TLA_insights digest #4 - System Thinking & Product Thinking

light On Systems Thinking, Russell Ackoff

Review of a short talk "On Systems Thinking" by Russel Ackoff. Ackhoff is a well known figure in the systems thinking world and this talk is a great 15 minutes 101 on Systems Thinking.

Systems Thinking opens the doors to actually design "what we want", not "what we don't want" (in local parts of the system). This is key as a system is not the sum of the behaviors of its parts, but the product of its interactions. (Ackoff).

record overview | 🔗 record

light My Insights: Ackoff was (and is through his legacy) an inspiring thought leader and promoter of System Thinking. This 15 minutes talk leave no doubt of that and is as a great motivation of why systems thinking perspective is key to approach problems and the design of systems. In a nutshell, and paraphrasing Ackoff: "a system is not the sum of the behaviors of its parts, but the product of its interactions". Given this, if we are purely focusing on the parts in isolation, this will never yield to the maximizing the properties (and efficiency) of the overall system. This is why I strongly believe that when building software products we can't purely focus on the "technical system" to be built (or worse, single parts of it). We must understand the customer, but also make sure we consider (empower) the people who will actually be building the product (technical system). Only then we will be able to maximize our impact (and effectiveness). This may not be trivial, but failing to do so will lead to all sorts of challenges that will block the improvement of the overall socio-technical system, or even degrade it.

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

The insights and notes of this record are inspired and driven by a short talk from Russell Ackoff on the core ideas Systems Thinking [System-Thinking-Ackoff] (video below). Ackhoff is a well known figure in the systems thinking world and this talk is a great 15 minutes 101 on this topic.

He starts by sharing that many "project failures" come from the fact that such projects don't follow a systems thinking approach. They tend to be "anti-system applications", mostly approaching the problems from "partial/local/reductionistic" perspectives.

He then goes on defining what is a system: "a whole that consists of parts, each of which can affect its behavior or its properties". He gives the human body as an example of a system made of many different interacting parts, each of which can affect the human body behaviors or properties. Each part has inter-dependencies on other parts of the system, and as such the system cannot be divided into its sub-parts without loosing its properties. To emphasize this, he shares another rather interesting example: a car (as a whole) can move, however that property is lost if you break the car into parts (e.g: engine alone cannot move). This is why "a system is not the sum of the behaviors of its parts, but the product of its interactions".

The next point mentioned relates with "systems of improvement". He makes a blunt (but so painfully real) claim here, namely: "if we have a system that is directed at improving by approaching its parts separately, you can be absolutely sure that the performance of the system as a whole will not improve!". He showcases this with another brilliant example: bring the 200 best cars in the world; take each best car part from the whole group of cars; and then put all the best parts (from all cars) together. What do you get? For sure not the best car! Why? Because the parts don't fit with each other. This happens because the form/design of the parts depend on the system context they are being designed for.

Notes: This is so intuitive, however we still live in a world where "reductionism" (i.e.: break everything into parts and optimize parts in isolation) is the most prevalent approach. This is true on how we build Software (our teams, architecture, etc.); but also on how we work and collaborate as societies. The COVID-19 pandemic is a great example of this: each country takes its own local approach and forgets that this virus is not going to stop at the borders ("boundaries"). Such challenges require joint efforts (of the parts, i.e.: countries) and solving the problem from an holistic manner (in the overall system, i.e.: world). Similar challenges are coming with global warming...

On the next point Ackhoff shares some great insights on the challenges and approach for the "architect of systems". On his words this is a person that should be able to understand the system as a whole and how its parts interact to create the whole. An architect cannot properly design without that perspective (at least understand the "surrounding scope system", where the design should fit and relates with). He shares the example of a house Architect. She starts with the overall design of the house (that is the system she is looking at), and only then the rooms that fit the design of the house. In this process she may discover ways to improve the quality of the rooms, and that may improve the overall quality of the house. However, she (should) never focuses on improving the quality of the rooms if that does not simultaneously improve the overall quality of the house. In a nutshell: parts of the whole should improve the quality of the whole. If this is not happening, you should take a step back (and again look at the whole - "synthesis" exercise).

Notes: this is why I strongly believe we should stop designing our products and technical software systems in isolation (as in the old classical "business" and "IT" silos). Even a step further, I argue that we must consider the whole sociotechnical system involved into understanding and building our software products. Failing to take that perspective means that we will also fail to understand how we can improve the overall system, e.g.: have a clear understanding of the customer, the teams that will be building and owning the systems and make sure the technical systems are aligned with that. This is what I call Sociotechnical Architecture and Systems [Sociotechnical-Silva] .

He finishes the talk with several amazing remarks, namely:

  • getting rid of deficiencies on parts does not improve the quality of the system as a whole. Improvements should be focused on "what you want", not on what you don't want. We will not improve the house by stopping a fire... we improve it by adding quality to its parts that make the house better.
  • "continuous improvement" is as nearly as important as "discontinuous improvement". Creativity is a discontinuity, it breaks the continuous improvement flow, which leads to leaps of improvement that are not possible in "normal paths".
  • qualities of systems should focus on effectiveness not efficiency. Efficiency is knowledge, however effectiveness is wisdom! He shares an amazing example: Toyota found greatly efficient ways to mass produce cars; however, if we look at our transportation systems this is not effective - having each person driving alone on a car.



light Good Fences Make Good Neighbours, Trond Hjorteland

Review of article by Trond Hjorteland on the importance of defining the appropriate teams and technical systems boundaries. This can only be achieved by having an holistic approach to what we want to accomplish on the system that "contains" the parts (i.e.: systems thinking approach). Failing to do so will lead to local optimizations and not having "good neighbors" (and as such not optimizing the effectiveness of the systems).

An harmonious sociotechnical system where the whole is greater than the sum of its parts cannot be reached without some holistic design. Random and uncontrolled emergence will not necessarily give that desired result on its own because the old machine model where the system is deterministically defined by its part does not suffice. (Trond Hjorteland)

record overview | 🔗 record

light My Insights: inspiring article by Trond Hjorteland on the importance of well crafted "boundaries" between the different parts of our organizations sociotechnical systems. This is something that we all know and do: breaking down our organizations into "parts": can be teams, tribes, etc. However, those exercises are not always driven by elements that enable the overall performance and "harmony" of the system to be maximized. Common reasons for this are: "legacy" ("we always had these departments"); local optimizations (break this team in two to solve the problem, but keep technical systems that should never be owned by these teams); etc. Trond shares several interesting insights on the need to have a more holistic approach on setting up the good boundaries for the parts of our system, given that "a systems depends more on how its parts interact than on how they act separately".

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

The insights and notes of this record are inspired and driven by an article by Trond Hjorteland [Good-Fences-Hjorteland] on the importance of creating the right boundaries for the social and technical parts of our organizations. Trond has been a great source of references and insights over the past year on my sociotechnical & systems thinking exploration journey [Sociotechnical-Silva], so am really happy to finally write a TLA_insights entry on one of his articles. This article belongs to a great series of articles [Articles-Hjorteland] - mostly covering the sociotechnical and systems thinking ideas and how to use those to improve how level setting up the (sociotechnical) systems to build software products.

He starts the article by mentioning "why we need boundaries" in our software designs and teams. He rightly points that in many organizations we "break the domains" into technical parts for many different reasons without paying too much attention how these contribute to the properties of the overall (sociotechnical) system. A common issue of such naive boundary definition is the creation of strong technical coupling between teams. This leads to teams "dragging" each other, creating a rather dysfunctional situation. To avoid such situations we must embrace that we are dealing with highly complex sociotechnical systems and as such we must design our teams and architecture from an holistic perspective. Namely: understand what we want from the overall system and from there understand what are boundaries (and contributions) that enable to achieve the whole (this is where synthetic thinking comes into place).

Trond uses a great example to showcase the need for rightly defined boundaries: "stone fences". These are low height stone constructions that can be found in many rural areas in Norway (btw: also where I grew up in the rural north of Portugal - and funny enough for the same purposes). These serve many purposes, example: defining the limits of the different neighboring farms, keeping the livestock in place, etc. They are carefully crafted to resits the elements, however they are meant to still allow people and wildlife to move around and go on with their lives (e.g.: be able to jump the fence to help or talk with the neighbor if necessary). "They were not designed to be walls" (as in barriers that impede interactions).

This centuries old philosophy of designing stone fences can be a great source of inspiration to identify and design the boundaries of our software (socio-technical) systems: we should build them with care and intention to serve the overall system around them, e.g.: enable the people & activities around them to be efficient.

"Well designed modularity should make good neighbors". This is so true: if rightly modularized we can better cope with complexity (e.g.: reduce cognitive load required to work on a certain part - instead of having to understand the whole all the time). This also enables a more decoupled evolution of the system parts. As Trond rightfully mentions: such a modularization happens whether we design it or not. Any complex system will evolve into fragmenting itself into parts. So, the important point here is to be explicit and aware of this and take that into consideration when designing on our sociotechnical system: "We must place the borders so that we not only get an efficient and effective system, but also a harmonious one; where the interaction and collaboration enhance the system, not harms it." We can only do this if we approach our design by considering the sociotechnical system as a whole and, as Trond mentioned, "jointly optimize it".

Notes: I find very interesting parallels between "defining the fences" and Team Topologies [Team-Topologies] "collaboration" interaction mode. In a nutshell "collaboration" can be used as a way to discover and shape where exactly we should set the "fences" (or boundaries). In general we have some ideas where, but having the "neighbors" working together and observing what makes the best location for the fence can be a very effective way to get the right modularization in place. This is like having two neighboring farmers with a challenging terrain together finding ways to set the fences so their lifestock can safely stay in their farms. They collaborate while doing that, but once they set the fences, they will go on with their own activities on their own farms. This is in general the evolution of the interaction, which in Team Topologies would be to have a clear API between the parts.

Every architect dreams of systems with fully decoupled parts. However, this is rarely possible: systems are made of parts and in fact the interactions between those parts is what forms (and defines the core properties of) the system. As Ackoff so beautifully said: "a system depends more on how its parts interact than on how they act when taken separately". What does this mean? We must embrace the interdependencies and create the most appropriate "fences" we can, so a team can own its own part and minimize coordination with other teams, etc. If we purely focus on "completely independent" parts, we will never achieve maximum effectiveness of our overall system (in general organization and its products). Last but not the least, we should not forget that these parts of the system should be set up in order to improve the properties of the system as a whole (as in systems thinking).

Notes: the embracing of systems thinking on setting up team boundaries is key on modern organizations, especially product-led organizations. The language we use to describe and define sociotechnical architectures on product-led organizations is still "fuzzy" (Nick Tune has started a great discussion to start addressing this here - [Arch-Building-Blocks-Tune]). My current mental model of this is: a team belongs to a product - being customer facing or internal facing product. That product is the "system" we want to understand and then optimize for at the perspective of a team (i.e.: this is the involving system, where the part - "team & its tech systems" - belongs to). In general this product has multiple teams, and as such this is where Trond's "defining good fences" comes in: this means well defined fences, but I think other elements will also help - I have been looking at how can we have proper co-leadership (product + people + technical) among the different teams in a product, how to evolve these, etc.. This (and how to scale this to the full product-led org) is a WIP topic on my thinking and writings, so more entries are coming on this topic.

"...well-functioning and harmonious sociotechnical system where the whole is greater than the sum of its parts cannot be reached without some holistic design. Random and uncontrolled emergence will not necessarily give that desired result on its own because the old machine model where the system is deterministically defined by its part does not suffice." This is why a systems approach is so relevant when approaching setting up our teams and technical architecture (i.e.: sociotechnical architecture). This emphasizes the design from an holistic view, which provides direction to all the teams (to align and have a common north star). However, at the same time having a continuous bottom-up learning and teams being as independent as possible and enabling this combination to drive the evolution of the organization. This is very important as the organization is always changing, i.e.: we must forget about fixed org structures, as those will never allow us to keep and improve the overall properties we want for our system (organization).



light Product Thinking 101, Naren Katakam

Article from Naren Katakam that provides a quick, clear and pragmatic introduction the the main aspects behind "Product Thinking", namely: What is it, Why it is important; and How to cultivate it. This is a great article for people that want to quickly grasp the main elements at play in product thinking and furthermore get some useful pointers on how to start on it (i.e.: it makes justice to its name and truly is a nice 101 to product thinking).

Product thinking is about starting from the customer (problem space), understand it and from that create strong "testable hypothesis" to drive (and validate) the building of the product in the "solution space".

record overview | 🔗 record

light My Insights: product thinking is an approach and philosophy to build products that makes customer the center and the starting point for all the product development activities. The primary goal is to be able to build the product from the understanding of the problem(s) the customer faces. We can still take other elements in consideration (e.g.: business vision & strategy, technology options, etc.), but customer should be the main driver. This means we start the product development from the "problem space" (which is the space of problems the customer faces) and from there we discover and identify "hypothesis" (with certain "assumptions") that can be tested/validated while driving the building of a solution delivered as a product (i.e.: specify the "solution space"). Product thinking is in growing adoption, however many organizations still take a "shy" approach to its adoption, namely it still has to compete with the rather prevalent classical "inside-out business-driven" strategies (which tend to be more "sales driven") or "technology driven" strategies (which are equally "inside-out" design with focus on technical aspects). We still have some ground to cover, but as this articles shows product thinking is a powerful way to build products and is not so difficult to adopt. However, organizations need to embrace and change to maximize its potential. Failing to do so (and rely on sales and technical-driven strategies) leads to building products that are mismatch with customer expectations and with that loosing opportunities or simply fail as a product. An important remark is: product thinking is just one variable in the whole system of systems that need to build and continuously improve our products - more on that in https://esilva.net/sociotechnical

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

The insights and notes of this record are inspired and driven by an article from Naren Katakam [Product-Thinking-101]. This article provides a quick, clear and pragmatic introduction the the main aspects behind "Product Thinking", namely: What is it, Why it is important; and How to cultivate it. This is a great article for people that want to quickly grasp the main elements at play in product thinking and furthermore get some useful pointers on how to start on it (i.e.: it makes justice to its name and truly is a nice 101 to product thinking).

What is product thinking?

Naren shows a very interesting visualization to describe the entities at play on the equation of a creating a Product: Users (who define the "need" → the problem space) **, Business (who define the "vision/strategies" to drive product development → solution space) and Technology (the medium that connects Users and Business and delivers the product).

Product Thinking elements (Image Credits: Naren Katakam, narenkatakam.com)

In a nutshell: "Product thinking is the journey from the problem space of the users to the solution space of the business. The goal of this journey is to reduce the gap between users and the business."

Why is product thinking important?

Because it enables to maximize the "product-market fit" equation by start developing the product from the "problem space" (from the customer) instead of pushing things "the business" thinks the customer should have (i.e.: be "solution space driven"). By taking this approach the product will be solving/addressing/alleviating customer problem(s), which should maximizes the odds of success of the product. The author provides some interesting heuristics for implementing real product thinking, namely:

Love the problem, not your solution: "always start with the problem", ask simple questions such as: "what is the problem?", "who is facing the problem?", etc. This helps discover what characterizes the problem space and the "persona" that is in it and for whom we are building/optimizing our product (and its "value exchange"). With this we can start shaping the "ideas" that can define the product (i.e.: the "solution space"). The author presents a nice visualization of this process:

Product Thinking flow (Image Credits: Naren Katakam, narenkatakam.com)

Notes: this is a great visualization, however it may be misinterpreted on the fact that it is a one way activity, i.e.: ends with delivery. However, product development is a continuous cycle and the Build-Measure-Learn is a cycle that does not stay purely on the Solution Space. The product evolution cycle should cross back to the problem space on each iteration, where customer is again central on identifying next steps of evolution of the product (maybe even complete "pivots" - as Lean Startup [Lean-Startup] defines). Nevertheless, this visualization provides a robust strategy to approach each iteration from Problem to Product.

Think in products, not in features: enables to keep the big picture of the problem space as the focus, instead of getting lost into specific detailed solution elements. Features tend to take a micro-view on the world, which leads to "local optimizations" that don't take the whole context in consideration (i.e.: may even hurt in the overall product context).

Notes: this remarkable heuristic is rather misunderstood, not only in product but also engineering communities (especially people that blindly adopt "agile" as a way to do small things / features and not "think and design" upfront). Enough product discovery is not waste, it is a way to avoid waste! By creating enough understanding of the problem (space) we can set clearer directions for solution (space), which (should) lead to better results (i.e.: increase of value exchange with customer and also less waste in terms of "work done by team" - which is exactly what "blind agile" people end up doing while trying to avoid it badly).

Have your product heuristics in place before writing your first line of code: these heuristics characterize elements and goals for the "end product". This provides principles for the product development (and end result). Important: this is not about defining step-by-step where we are going - as (most of the times) we don't yet know everything of what we are building (there are always unknowns to be discovered along the way). The author states that an effective set of heuristics should be a mix of two types of heuristics: 1) physical attributes of the final product (e.g.: "the product should have confidence and common sense"); 2) desired reactions expected from the end-user of the product (e.g.: "the product should always be available when the user needs it").

Notes: one remark on starting without having a clear plan for the whole solution space. Trying to do so (define the complete end solution) may be a trap, especially on many of today's products, which tend to fall into the "Complex" and "Chaotic" quadrants of Cynefin [Cynefin]. To understand the problem space of products in those categories (and start shaping the solution space) we must act (build) and discover/learn what are the most interesting next steps. This means we are sort of inter-leaving between problem and solution space. This is very much still in line with the product thinking ideas shared in this article: i.e.: discover before you commit.

How can we cultivate product thinking?

The author argues that in order to cultivate product thinking we must develop systems of tools and frameworks that help shape it and strengthen it in our teams and organizations. He share three tools for problem space and three for solution space.

Problem Space:

  • 5W1H (What, Who, Why, Where, When & How): these are intuitive questions that can help the discussions and understanding. Important element to consider: use "Why" and "What" if you want to "further develop / expand" the understanding of the problem; and "How", "Who", "When" and "Where" to converge/focus/narrow-down solution options.
  • Mom's Test (foolproof your questions): focus on defining simple rules for crafting good questions. The idea is to review questions used to interact with users to make them clear, simple, understandable and non-biased (i.e.: avoid leading users into a specific answer).
  • Jobs-To-Be-Done (JTBD): when trying to understand the problem space, start with the simple question: "what job(s) arise(s) in people's lives that your product could solve?". This is a triggering question for the exercise of understanding the user journey, problem, etc.

Solution Space:

  • Get better at constructing hypothesis statements: in the words of the author "a good hypothesis statement is the ultimate testimony of your problem space understanding" (I love this sentence!). So, basically one of the first steps when leaving problem space is to have a clear, crisp and testable hypothesis formulation, which allows us to go into the solution space with a clear direction and munition to validate our developments. The author provides great formulation on the differences between "ideas", "hypothesis" and "assumptions". "Ideas" are abundant, but not all can be formulated as a clear hypothesis (i.e.: not tested). Every "hypothesis" comes with a series of "assumptions" and they form the "things to validate" during the product development process.
  • Get creative with problem solving: finding the right starting point is challenging. The author proposes building upon proven models and systems, as for example: "Transform" (transfer solution from one area to another); "Minimize" (reduce an existing solution); "Maximize" (expand an existing solution); "Modify or Rearrange" (modify an existing solution); "Substitute" (substitute a part of an existing solution); "Combine" (combine several existing solutions into one). He gives very nice examples of products that apply such models - this is definitely a great way to set a clear solution focus our product.
  • Start focusing on the outcome and not the output: "As a product thinker or product manager, you should start focusing on the outcome rather than output, the value you are generating versus estimation of development effort, and the accuracy of the product to do a job versus simplicity."



light Escaping the Build Trap, Melissa Perri

Review of the Book "Escaping the Build Trap" by Melissa Perri. This is one of my to-go resources to position Product Thinking and Product Management and all the core elements we must consider to set up product-led organizations for success.

From output to outcome; from shipping (large amounts of) features to discover ("Why") the ways ("What") maximizes the value exchange with the customer, by enabling product teams to continuously do that.

record overview | 🔗 record

light My Insights: Escaping the Build Trap by Melissa Perri has become my go-to for the basics of Product Thinkings and Management. However, it does not stop there, it also shades light on the aspects required to setup the organizational systems and how to approach them (e.g.: consider setting up your teams and technical systems around value streams). To me this is a very interesting step towards having an holistic view of the systems required to achieve the end goals of Product Thinking: "maximizing the value exchange with customer". Failing to cater for this, and focusing purely on "understanding the customer", is recipe for issues down the road (i.e.: have great ideas but ill setup for the teams and technical artifacts they work with). This is why I find this book refreshing and a step forward on help setting up product-led organizations.

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

(In the following you can read my book review, originally published here: Review & Reflect: Escaping the Build Trap )

{% for post in site.posts %} {% if post.post_id contains 'escaping_build_trap' %} {{ post.content }} {% endif %} {% endfor %}