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

light

Although this is just iteration #2, I am already pivoting the format a lot 😄 (learn fast and make it better). The following changes were made:

I hope you appreciate these changes, I am really excited about them as it allows more regular and interesting insights to be published and also create a clearer knowledge base of insights. I have a few other ideas in mind that I will be working on moving forward, so stay tuned!

On a personal note: September and October were very eventful in terms of developments on topics relevant to TLA_insights:

I hope you have fun and find some interesting insights here. Don't hesitate to contact me via email or on Twitter me if you have questions or want to chat about these topics.

TLA_insights digest #2:

Sociotechnical Architecture & Systems Design

Team Topologies, Matthew Skelton & Manuel Pais

[Book]

light My Insights: Team Topologies is a great contribution to develop and mature many of the elements required to set up sociotechnical systems & architectures. It brings many insights and raises awareness on the issues organizations may get into if they ignore to have an holistic co-design approach of their of technical and organizational systems. Furthermore, the book gives a clear, small and simple language to discuss, design and evolve team setups and interactions. As I said on my review of the book: "To me, Team Topologies is becoming a reference book to help on the design and evolution of organizations and their sociotechnical architecture!"

Analysis & Summary

The book Team Topologies is one of those books that brings a lot of interesting ideas to the table, but also provide clear and actionable principles and constructs that one can immediately start using. In a nutshell, the book focuses on how to set up teams (business and technology) and organization for "fast flow". What does it mean? Means to explicitly consider Conway's Law; means considering the teams size and "cognitive load" (when interacting with other teams and owning their applications) when setting up strategies for our products, i.e.: stop to purely focus on the design of the technical system and also consider the actual organizational system in the problem & solution design space. Their proposal to approach this is to have a "team-first strategy", in which the team "cognitive load" is a major variable on assessing whether the team can successfully own a new product (or be part of a given activity). In order to design these teams and also mitigate on how to empower them they present 4 different "Team Topologies" (see Figure bellow).

Team Topologies

The goal is to have Stream-Aligned Teams (SATs) working at high-velocity on improving their value stream of the product (to their customer). For that, we have the other three team topologies supporting different aspects to empower SATs.

However, teams don't live in isolation, nor are static in time (a classical mistake of "org design" - the authors propose instead to think about "org dynamics", as organizations change and evolve, and so having ways to address that explicitly helps). For this the authors propose three interaction modes for teams (see Figure bellow).

Team Topologies Interactions
(Image Credits: Team Topologies, Matthew Skelton and Manuel Pais.)

The book has a lot of amazing complementary resources, you can find them here. Furthermore, they also have multiple open source resources on GitHub (such as different templates for assessing cognitive load, setting up Team APIs, among others).

(Find my in-depth review of the book here)

InsighTweet


Technical Leadership

Secrets of a Strong Engineering Culture, Patrick Kua

[Presentation]

light My Insights: building great engineering cultures is not trivial. They take time to build, they are not "projects" with a due date, they are a continuum, an infinite cycle of improvements. Make this explicit and make the core elements of your culture visible so people can see it and know how to contribute to it and improvement it. Another important aspect is the creation of systems that support the culture and its continuous improvement, e.g.: make sure decision making is clear and people understand scopes of decision making - team can decide things within their team, but if it crosses to multiple teams this is decided by people working on that multi-team scope. This openness and systems will enable autonomy and participation of every engineer while managing complexity (i.e.: balance autonomy and alignment), and with that bring in the ingredients needed to make a great engineering culture.

Analysis & Summary

This is a great presentation by Patrick Kua on "secrets" of Strong Engineering cultures, i.e.: things to cater for in order to have an organization that moves at high-velocity, but also is a great place to work, where people feel motivated and can thrive in their activities. By having such traits, organizations also have higher changes of attracting and retaining great talent - a big challenge in our current market. Apart from the secrets (and challenges to cater for on each secret), Patrick also shares some interesting and useful recipes on how to start developing such culture and make it "more explicit".

The three big secrets presented are:

After introducing the secrets Patrick shares a 5 step recipe to create and continuously improve their culture:

The final point of the presentation is a check we can do to measure if we are improving our engineering culture (i.e.: sort of metrics to measure health of an engineering culture):

InsighTweet


Software {Architecture, Engineering & Tech}

Software Architecture, Team Topologies and Platforms, Matthew Skelton & Manuel Pais

[Podcast]

light My Insights: Modern Software Architects cannot anymore purely focus on the Technical systems anymore. They must be "Sociotechnical Architects": be able to consider the organizational and technical systems in the problem & solution spaces. Ignoring this is recipe for partial optimizations and in most cases a lot of "synchronization overhead and waste". Why? Because if you ignore the influence that organizational and technical systems have on each other, you will not get teams with clear boundaries, owning decoupled parts of the product (value streams), and as such you will spend huge efforts on synchronizing all the teams developments. This is what many "Scaled Agile" frameworks focus on ("synchronization ceremonies"), however these are a temporary/poor remedy if the underlying sociotechnical architecture is not properly set up. Team Topologies provides a lot of interesting elements that Modern Architects can use on to address these sociotechnical challenges.

Analysis & Summary

In this podcast Manuel Pais and Matthew Skelton talk about several elements of Software Architecture and traits of modern Software Architects - many well positioned on their book Team Topologies. I couldn't agree more with the core remark of the conversation, which I summarize as: the Modern Software Architect is a Sociotechnical Architect. Like Manuel says: "the focus purely on technology is not relevant anymore... the shape of the organization is a constraint on the solution search space. If your organization is set up in a particular way, we may never find a particular solution...", i.e.: purely focusing on "technical architecture" will lead to to sub-optimal results - or even more bluntly put will lead to "working against forces in place" (the organization and its communication structures - as Conway's Law states).

Given this, and also the fact that many of the things that traditionally a software architect would focus on are now provided "out of the box" by cloud providers, a modern architect needs to widen her focus and bring together, facilitate many of the relevant conversations around the sociotechnical architecture and how it enablers the organization and teams to move at high velocity. This may mean having to zoom-in and out in different perspectives of different systems, and work with different people in the organization, i.e.: being able to understand and speak the different languages and bring them together. But this position as a facilitator, enabling teams and organization to define the direction to move forward more strategically makes clear we need these socio-technical leaders in our organizations.

Team Topologies brings a lot of language, principles and guidelines to help architects on this job. Using these will help Architects a lot on having conversations about teams organization and their evolution. This is a great insight from team topologies: organizations are dynamic and as such, we need to accept that and continuously adapt as we see fit. This is also an important aspect for modern architects, and anyone that is in any way related with driving how the organization is setup. For example: if a product team grows too much in complexity and the team cannot work "well" anymore (i.e.: team has no "cognitive load" available to operate at its best), something needs to happen. For example: Team gets support from Platform to simplify complex elements that take a lot of effort from them, when building and deploying their product - releasing that cognitive load. Or we may need to create another team to take part of the elements of the team (with a clear scoping needed for that). All of this sort of discussions are not purely technical, they are sociotechnical and this is why modern architects should know about these different elements.

I really loved and resonate with a point made at a given point of the podcast, namely: If you ignore Conway's Law and continue trying to keep an architecture that is not loosely coupled and with clear ownership boundaries, and you focus on "adopting scaled agile methodologies and frameworks" you will be drowning your teams into continuous and tedious "synchronizations" - they are all inter-tangled and need to sync with each other at each small step they take! I have shared this view many times in many places: adopting some agile practice and ignoring your sociotechnical architecture setup is not going to solve your problems... it will be just a light-pain-killer for a few days and a huge waste of time and efforts from many people.

They cover several other elements very relevant to Modern Software Architects, namely helping on scoping the Platform. Example, strive for the "thinnest platform" (i.e.: don't follow the classical Platform patterns of building whatever seems interesting and then development teams can use that). Switch things around instead, i.e.: focus on the minimum platform needed and build it based on its customers (i.e.: the needs of the product teams building the product for the end customer of the organization, a.k.a.: "Stream Aligned Teams" in Team Topologies). This means Platform teams become also product-oriented too.

InsighTweet