Enabling Thinking & Teams Articles Series

This is the first article of a series on Enabling Thinking & Teams. In it, I briefly frame this series and my motivations for writing it. Furthermore, I share my initial list of articles for the series (based on what I have been observing and learning on these topics). At the end of the article, I also have a link to a feedback form to gather insights on the topics I plan to cover and any other missing aspects.

Discuss the fundamental ideas of Enabling Thinking & Teams and why they are essential for organizations to move towards continuous and effective learning and improvement. That ability gives the organization a foundation to continuously achieve better design and decision-making to address its different challenges and opportunities—or achieve what I like to call a “sustainable fast flow of change.”

Explore why it is fundamental for organizations to develop and embrace thinking models and practices that support and incentivize people close to challenges to leverage their rich context and knowledge to improve effectively. This entails different aspects but codifies the core ideas and elements of what I am calling Enabling Thinking. In my experience, Enabling Thinking provides the foundational thinking to create the conditions for practicing Enabling Behaviors and eventually having effective Enabling Teams.

In this article, I reflect on the topic of return on investment of Enabling Teams. This is probably the most recurrent question I get around Enabling Teams: ” Why should we have these great people working on helping improve around the challenge ABC instead of having them deliver product features”? This article will highlight the direct and multiplying effect of enabling teams’ work in an organization. I will show several examples and discuss several anti-patterns around “ineffective improvement” (probably the main reason why many get suspicious about improvement initiatives and efforts). Hopefully, this will help “bust” some myths and clarify that strategic investment in improving existing challenges/constraints pays off big time in the short and long term.

In this article, I want to discuss a topic many organizations struggle with: when to use Enabling Teams and when not to. Although the idea of continuous improvement is interesting, it is crucial to recognize that the improvements should be based on specific needs. I will touch on different topics, particularly the ability to sense and notice challenges that can benefit from Enabling Teams and others that should not be tackled or addressed otherwise.

In this article, I explore ideas and practices for starting and effectively running Enabling Teams. As I will discuss, this is not a “one-time thing” but a journey. Organizations typically need some “learning & practicing” (and specific incentives) to leverage Enabling Teams. I will elaborate on aspects of that journey and share some practical resources. For example, the Enabling Teams API Canvas is a simple canvas I have been using with different organizations to help consider some of the most fundamental questions and things to remember when starting Enabling Teams.

In this article, I explore a topic I have been observing for several years around the “lifespan” of Enabling Teams. Typically, we assume Enabling Teams are short-lived - and that is probably the most common situation. However, it is essential to recognize that Enabling Teams can also be long-lived and structural teams (such as Architects, Engineering Managers, Product Managers, and others working around product teams). What is important is to consider that Enabling Teams’ facilitating interactions should always be temporary and have a clear purpose - even for long-lived structural Enabling Teams (they too should strive to have facilitating interactions, which means they - together with teams being facilitated, have a clear understanding on what is the focus of their interaction, so it does not become an unclear and open-ended interaction).

In this article, I will discuss how Enabling Teams can be strategic in identifying and helping (co-)evolve platforms in the organization. This comes from the fact that Enabling Teams typically work on topics that teams are struggling with. That places them in a strategic sensing/noticing position, which allows them to notice and frame improvements, which, in many cases, should be consolidated into platforms that can support teams facing those challenges. There are also other interesting patterns around the inter-play of Platforms and Enabling Teams, so this will be a good article to bring these ideas together.

In this article, I will discuss different ideas around positioning Leadership and Management teams (typically working around and across multiple product teams) as Structural Enabling Teams. I have been experimenting with this idea for several years in different organizations, and I also see other people discussing it. It seems like an essential ingredient to shift from the classic “command-and-control” leadership and management towards enabling teams and people close to problems to have more conditions to design and decide, which leads to better conditions for them to achieve a more sustainable fast flow of change.

In this article, I will revisit an article I wrote in 2021 on this topic: Architecture as an Enabling Team. I will be exploring several new ideas, including the idea of Architecture Topologies, in which I have been working with multiple clients to discuss how they can improve their approach to architecture. Particularly, I see many organizations shifting towards this architecture topology, where architects move from controlling the design and decision-making to enabling teams to effectively own and drive that in their scope of work. I will also discuss a particular variation of this architecture topology, in particular, the “Architecture Modernization Enabling Teams” (AMET) - a pattern that Nick Tune and I have been writing about, where an enabling team is facilitating complex architecture modernization initiatives.