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

light Team Topologies, Matthew Skelton & Manuel Pais

Insights on the book Team Topologies, a book that brings a lot of interesting new ideas on how to approach organization / team design and its "evolution" from a "team first strategy" and "team cognitive load" perspective. The book presents clear motivation for this strategy and then proposes 4 basic team topologies and 3 types of team interaction modes to approach such org design and evolution.

"To me, Team Topologies is becoming a reference book to help on the design and evolution of organizations and their sociotechnical architecture!"

record overview | 🔗 record

[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

  • Stream Aligned Teams (SATs): the teams building a part of the product that supports a certain value stream to the customer.
  • Enabling Teams: facilitate SATs on overcoming obstacles and in that way enable them to do better. Detect missing capabilities and can help on elements that don't necessarily belong to any specific SAT.
  • Complicated Subsystem Teams: are teams that own complex parts of the landscape, which by being abstracted into such sub-systems enable to simplify the applications from SATs and with that reduce the required team cognitive load. By having a simpler product the SAT can also increase their velocity (compared with when they have to own such complex systems by themselves).
  • Platform Teams: focus on building "internal products" that accelerate and simplify how SATs build their own applications (and products). This is done by taking away complexity of SATs, which enables them to have more cognitive load available to work on the business problems.

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.)
  • Collaboration: interaction mode where two (or more) teams collaborate for a defined period of time to learn and discover how to proceed on their developments (e.g.: identify boundaries of a legacy system and with that each team can own a clear boundary and proceed to work on it on their own).
  • Facilitating: one team helps and mentors another team. This is a very common interaction mode to enable bringing new knowledge within the team or kickstart something new.
  • X-as-a-Service: one team provides another with something "as a service" (e.g.: an API with a clear contract that the other team can consume without the need of continuous collaboration).

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



light Secrets of a Strong Engineering Culture, Patrick Kua

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.

Building great engineering cultures is not trivial: they take time to build, they are not "projects" with a due date but 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.

record overview | 🔗 record

[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:

  • Impact: (good) engineers don't want to be "feature factories". They love being challenged, seeing the impact of their teams' contributions on the end customer (without having to go through long processes and handoffs). To accomplish this several we can look into several aspects, such as: enabling engineers "shadowing customer services" and see what are the problems customers are facing, this will show the real problems - don't restrict these customer interaction activities to UX people; Work on small iterations, making sure improvements are continuously being released and validated with the customer; and make sure that team OKRs are aligned with the overall company strategies (i.e.: team sees how they are impacting and contributing to the overall org strategy). These elements and metrics are also the base of high-performing organizations, as shown in research done in the Accelerate Book (and DORA project). Patrick's principle for Impact: "cultivate impact by reducing feedback loops".
  • Choice: choice has to do with the degrees of flexibility of "how to work", "how create a solutions" and "how to take decisions". Basically this is about "Autonomy". This is rather sensitive topic, as many times organizations want to have streamlined processes, consistent ways of working, tools, etc. However, following very rigid approach will go against the "degree of choice" that people find very attractive in working cultures, which also limits people from identify "better ways of doing things". Patrick shares some interesting points here: stop trying to go in such a mode of "full-control", and instead focus on providing clear principles that enable you to manage complexity. Example: observe common elements over teams, identify issues and based on that create systems that ask the right questions to validate that people don't add unnecessary complexity (e.g.: let's not introduce a new programming language or framework unless the gain outweighs the complexity of having a new element on out stack). Create culture where teams get clarity on the "What" they need to solve, and then get out of their way and enable them to find the "best How". However, the scope of being able to choose must be clear, i.e.: set they choice boundaries clear - some things can be decided within teams, but for company-wide (or multi-team) elements a designated group will most likely decide, preferably with the input from teams. Bottom line: enable autonomy (i.e.: Choice) while provide some good principles and constraints to enable alignment and risk & complexity management, so that there is clarity and we avoid creating "waste" for our teams and organization. Patrick's principle for Choice: "Cultivate choice by making the right thing easy".
  • Improvement: improvement relates with enabling people to grow, participate of improving the company's mission and make sure there is an environment that hears people's feedback and take action to address issues. "Bored people will quit": so it is very important to enable people to find exciting challenges and actually with that grow and bring growth to the company. To accomplish this it is really important to be transparent on the priorities of the company, so that people can clearly see where their work is contributing to those priorities. Finally, having a culture open to improvement, which fosters contribution from people to make things better is important. This is a culture that enables people to try things out without always going through endless processes (i.e.: "ask for forgiveness not permission"). This is a great ingredient to empower people to improve things at a faster pace. To make this work, we need to have systems in place that enable triggering improvements based on observed issues or inefficiencies (e.g.: results of retrospectives or post-mortems). Patrick's principle for Improvement: "Cultivate improvement by making small changes easier".

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

  • 1: Gather input (understand why people work in your company)
  • 2: Publish you Tech Culture (synthesize the input gathered and publish this, make it explicit)
  • 3: Prioritize key improvement areas (from the learnings, prioritize areas that need improvement)
  • 4: Decide on actions (set clear actions to improve the points prioritized)
  • 5: Repeat (this is an infinite loop... be always in the lookout on how to improve things)

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):

  • 1: How many hand-offs do you have between Software Engineers and customer?
  • 2: Are software engineers involved in the HOW they solve a business problem?
  • 3: What opportunities do Software Engineers have to grow?

InsighTweet



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

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.

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".

record overview | 🔗 record

[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