Summary

This article is a deep dive into several foundational organizational dynamics patterns that are essential to help organizations achieve more sustainable continuous improvement. In particular, I explore how Enabling Activities (as in Team Topologies) are essential to accelerate effective learning and framing of new capabilities in an organization. Then, I explore how Platforms are key to eventually scale emerging capabilities that many teams in the organization need, in an effective way. I explore the typical flows for these patterns and highlight their interrelationships. I share several examples to illustrate how important and impactful these patterns are (additional examples are presented in the appendix, demonstrating how these org dynamics patterns can be leveraged across a wide range of situations). This article and its insights are the result of practical work and experimentation across several software-enabled organizations in different industries, over the past decade. Still, I am convinced that these same patterns can be applied to any modern organization seeking to create conditions for faster learning and improvement, as a means to sustainably respond to the needs of its customers and market.

Key ideas & thinking models:

đź’ˇNeeds => Skills & Capability => Response thinking model as a way to represent the dynamics of organizations and its teams listening to the environment needs and respond to them
đź’ˇEssentials of Enabling Activities as means to support new needs in the organization, and leveraging that to shape emerging platform capabilities
💡Effective Enabling Activities can be for organizations to achieve a higher “Return on Investment and Quality” (RoI&Q), which should help people making the “business case” for Enabling Activities
đź’ˇTypical phases of development of capabilities in organizations, from validating and framing, to assessing the need for scaling and actual scaling leveraging Platforms
đź’ˇPrinciples and heuristics to build emergent platforms, based on the specific needs for scaling that are identified by working with the stream-aligned teams that are exploring the problems
đź’ˇStrategic importance of leveraging Enabling Activities and Platforms as a means to support continuous and sustainable improvement in organizations so that teams working on customer and market facing activities can respond to the needs emerging from the environment


Enabling+Platform Patterns



Deep Dive Article (DDA): This deep dive article is part of my “Effective Organizational Dynamics” and “Facilitating Modernization” article series. These are long-form articles that provide an in-depth exploration of practical challenges and lessons from the field, consolidating insights and actionable patterns to help leaders and practitioners navigate similar situations. Feel free to reach out to me if you have questions or need help on these topics.

Table of Contents

ℹ️ I offer consulting services and products on this topic

If you are looking for help on these topics feel free to contacting me, and/or check my consulting and products pages for more details on how I may be of help.

Modern Organizations MUST learn and improve fast(er)

Over the past few decades, we have seen an incredible transformation in our ability and speed to build and bring to market software and tech-enabled products. In essence, the rate of change in how such innovations are delivered, the market, and customer expectations has been staggering. I was born at the very beginning of the 80s and practically grew up without any technology around me. I am one of the last generations born without a computer at home. However, over these four decades or so, we have seen an explosion of technological innovations, from personal computers becoming a commodity to the Internet becoming widely available, to Cloud and, nowadays, AI, to name a few big step-changes.

We have been innovating increasingly faster by leveraging the compound effect of many of these foundational innovations, which naturally become commodities. This commoditization of foundational capabilities enables many more organizations to build new products, allowing them to use smaller teams and make a smaller initial investment. In essence, this “democratizes” innovation.


Rate-of-change
Figure 1: Innovation & Market Expectation Rate of Change VS Organization Operating Models Rate of Change



Even though starting something is easier, it is also a fact that for any company to succeed in this fast-paced change environment, it must thrive on learning and improving fast(er), so it can continuously understand and respond to market needs. Such trend and dynamics have only been accelerated with the recent explosion of AI tools and platforms.

Most organizations are not innovating sustainably

Even though we are seeing this need for improvement in organizations, many still struggle to learn and improve at a higher pace. From my experience, this is highly correlated with the fact that most organizations still employ rather bureaucratic and controlling operating models. These slow their ability to learn and respond effectively to their environment. So, as depicted in the figure above, the rate of change in most organizations’ operating models is still slow compared to the tech innovations we are seeing.

Still, you may say: “Well, but we are still building those innovations, so why is this a problem?” The point is, many organizations do that in a “non-sustainable and ineffective fashion”, typically pushing/straining people to deliver the needed things. In a sense, they do that by “throwing money at the problems”. This can be a strategy, but I argue that it creates environments that are neither humane nor conducive to sustainable and effective value creation. This manifests in many ways; for example, recent studies [Engagement-Gallup] show that people working in such organizations are increasingly less engaged and unhappy with their work.

Sustainable continuous improvement as a competitive advantage

In this article, I will argue that modern organizations need to create conditions and environments that foster sustainable continuous improvement. This is not just a “good thing to have “, as it helps people be happier while working. This also gives them a competitive advantage, enabling them to continuously maximize value exchange with their customers and adapt to the many changes around them. Furthermore, and given the types of “unpredictable problems” most organizations face (compared with the very predictable and plannable work of the past century), organizations need to strive to support faster ways of learning and experimenting to be able to respond to the customer and market needs and changes.

In the following, I will share practical and applied organizational dynamic patterns that can help with that. In particular, leveraging Enabling Activities to address gaps in the new skills and capabilities the organization needs to deliver value effectively, and Platforms to scale those emerging capabilities so most of its teams can leverage them to respond sustainably to the needs of their environment. From my experience and learnings over the past ten years or so, these patterns are highly effective, as they help create sustainable ways to grow and scale organizations. They are also fundamental to shifting operating models from controlling structures to ones that allow the people doing the work to drive the improvements needed to work on the important business problems effectively.

And no, AI is not going to solve this by itself… If anything, AI will accelerate the need for the sorts of changes I am highlighting here: enable people close to problems to explore, learn and leverage AI without requiring management validation.

Needs => Skills & Capabilities => Response thinking model

To explore the core organizational dynamics patterns in this article, I will introduce a simple thinking model I have been refining over the past few years.

The basic idea behind this thinking model is that organizations and their teams operate in a highly dynamic, unpredictable, and constantly changing open environment (see the figure below). If you want to explore this topic further, you can check the work on “Open Systems Thinking” [OST], as many of these ideas and principles build on that multi-decade work.

As depicted in the figure below, the fundamental idea is that, as organizations, we must continuously observe our environment to understand the important “needs and demands” we must respond to. These needs and demands can be different things, such as new products from competitors, new market demands, technological advancements relevant to our products, legal changes we need to comply with, etc. Needs and demands may also come from within the organization, requiring organizational change, such as new product lines resulting from a merger, a new business strategy, new organization operating model principles, etc.


Environment-Organization Dynamics
Figure 2 - Organizations as Open Systems, listening and responding to the environment's needs and demands



To respond to such needs and demands, we must have the skills and capabilities needed to “learn, design, and decide”. This basically means that, as shown in the following diagram, for us to effectively and sustainably respond to the important needs and demands around us, our organization and its teams must have the necessary skills and capabilities. Skills and capabilities can be different things, such as software engineering skills, methods, tooling, but also ways of working, architecture capability, etc.


Rate-of-change
Figure 3 - Needs => Skills & Capabilities => Response organization dynamics thinking model



Although this may seem obvious, my experience is that most organizations do not yet pay enough attention to nurturing and developing the skills and capabilities needed to effectively and continuously respond to the needs and demands in their environments. You can see this in multiple ways, such as the old-fashioned operating models focused on controlling structures and ways of working, where teams are told what to do and need to validate their developments with certain people. These dynamics hinder organizations’ ability to effectively learn and respond quickly and effectively to the needs in their environment.

Team Topologies framing with Needs => Skills & Capabilities => Response

To introduce the core organizational dynamics patterns of this article, I will first provide a quick recap of the fundamentals of Team Topologies [Team-Topologies], in particular the fundamental team types and interactions. The reason is that Team Topologies provides a comprehensive yet straightforward base language for discussing organizational dynamics. It enables discussions on how those dynamics help organizations continuously evolve their skills and capabilities to respond to the important needs in their environment effectively.

Fundamental team types

Stream-aligned team

Team Topologies focuses on patterns for organizations to achieve (sustainable) “Fast Flow of Value”. The fundamental pattern to accomplish “Fast Flow of Value” is the “Stream-aligned team”. The following diagram shows the Stream-aligned team and its position within the organization. Typically, an organization has one or more Stream-aligned teams that build and evolve the business’s essential streams of value. These Stream-aligned teams are customer-facing, i.e., they are in direct contact with the environment, enabling them to listen to and sense the needs and demands emerging from it. By having a direct connection to their environment (and customers), they can respond faster and better, as they have the “best signals” available to them. They can also experiment and learn more effectively.

💡Note: Stream-aligned teams may also be “internal facing” teams. I will elaborate on that when I introduce other Team Topologies’ patterns. Still, the same sort of principles and traits should be applied to those teams.


Stream Aligned Team
Figure 4 - The Stream-aligned team fundamental type



If we connect the essential ideas of Team Topologies Stream-aligned teams to my Needs => Skills & Capabilities => Response model, we can observe that, in a nutshell (check the figure below), as organizations, we should strive for our Stream-aligned teams to have the necessary conditions to “listen” to the Needs emerging in the environment. Those conditions encompass fundamental principles described in Team Topologies, including having the required Skills and Capabilities to effectively listen and understand the Needs, and then accomplish the necessary activities/work to Respond to the environment.


Needs => Skills & Capabilities => Response
Figure 5 - Stream-aligned team is core to support Needs => Skills & Capability => Response of organizations



Supporting Teams

To support the Stream-aligned team in developing effective skills and capabilities to achieve “fast flow of value”, Team Topologies introduces three supporting team types, as shown in the figure below. Those team types exist solely to continuously enable Stream-aligned teams to be effective in addressing the needs arising in their environment. They do that by minimizing the “cognitive load” they need to spend on non-essential activities to accomplish that goal. Essentially, they are a means to accelerate Stream-aligned teams in having the necessary skills and capabilities to respond to their environment.

If these teams are not doing that, they should not exist. There are obviously nuances here, as most organizations need specific, basic backend or back-office activities. However, even then, if one digs into the details, we should still ensure that any backend or back-office team is working on a capability that powers a business-facing activity. When such teams are not aligned with that, they tend to exist to control and slow down the teams building value for the business.


Team Topologies supporting team types
Figure 6 - Team Topologies supporting team types



Fundamental team types in a nutshell:

  • Enabling Team - exists to help Stream-aligned teams upskill or address missing capabilities. They are typically formed by experts on the topic at hand, who may be from other teams or external consultants, when the organization does not yet have sufficient in-house skills and capabilities on that capability. Example: a data engineer helps several teams learn about a new data processing tool that will help them build their services more effectively.
  • Complicated Subsystem Team - a team that owns a highly specialized capability, which requires rather unique knowledge and skills, not easily found in the company and in the market. Example: a sales forecasting team, with several people with PhD in mathematics, creating advanced forecasting models that the whole organization uses.
  • Platforms - a group of teams, who are internal-facing, providing self-service tools and services that help Stream-aligned teams work more effectively. Example: cloud provisioning platform, with different teams providing easy-to-use abstractions to create and provision cloud resources.

Fundamental team interaction modes

The following diagrams detail the three fundamental “team interaction modes” from Team Topologies. Team interaction modes provide a clear language for describing and discussing how teams interact and evolve. Interactions are particularly important for describing how teams can cope with specific “needs” (blockers or opportunities). They help clarify how the multiple teams involved should interact to respond to such needs.


Team Topologies Interaction Modes
Figure 7 - Team Topologies fundamental interaction modes



Team interaction modes in a nutshell:

  • Collaboration - when two or more teams work together for a defined period of time to discover and align on how to best solve a problem or opportunity they share, or both need to be involved. Example: teams on a cloud platform collaborating with “customer”- stream-aligned teams to understand how they can improve challenges teams have been having with the cloud provisioning API and the developer portal.
  • Facilitating - when an enabling team (or someone practicing Enabling Activities) temporarily helps one or more stream-aligned teams upskill on a particular topic or improve a specific capability that those teams need. Example: a data engineer supporting multiple teams that need to learn and start using the new data processing tool.
  • XaaS (X-as-a-Service) - when a team provides a self-service capability to one or multiple stream-aligned teams. This is a non-blocking dependency because the consumer teams can use it without requiring specific work from the team that provides it. Example: cloud provisioning platform team, providing a “provisioning API” that all stream-aligned teams can use to self-provision their own cloud resources without requiring the cloud platform teams to do specific “manual” work for them.

Enabling/Facilitating + Platforms/XaaS

The fundamental Team Topology patterns provide a clear language to support the necessary activities of the Needs => Skills & Capabilities => Response thinking model. They focus on helping organizations respond to specific needs in their environment.

In the remainder of the article, we will explore two more advanced organizational dynamics patterns that help support sustainable continuous improvement in organizations, namely:

  • Enabling Activities - “Enabling Activities/Teams” and “Facilitating interactions” as a means to address new and uncharted skills and capabilities in most teams of the organization;
  • Platforms - “Platforms” and “XaaS” (or self-servicing) for scaling capabilities that most teams in the organization can leverage to effectively respond to the needs arising in the environment

While introducing and exploring these two patterns in more detail, I will explain how they are highly interrelated and, when leveraged together, support more effective adoption and scaling of new capabilities in organizations. I will highlight that by using the graph below, which shows how the level of development/maturity of a given capability within an organization tends to correlate with the number of teams using it over time. Based on my experience, we should strategically leverage Enabling Activities and “Platforms” to develop and scale these capabilities within the organization. This is the core idea introduced in this article.


Capability Maturity and Number of Teams using it over time
Figure 8 - Capability Maturity and Number of Teams using it over time



“Enabling” new skills and capabilities in the organization

The following diagram shows a reasonably sized organization, where there may be many Stream-aligned teams, working on different “Value Streams” (in this context, let’s assume these represent various streams of value for the customer, or various “products”, which, given their different scopes, require multiple value streams to build and evolve them effectively). There are also Platforms (or “Platform Group”), which exist to support customer-facing value streams and enable them to work more effectively.


Organization and its teams
Figure 9 - Organization and its teams



The need for new skills and capabilities

Building on the Needs => Skills & Capabilities => Response thinking model introduced in previous sections, teams sometimes face new Needs from the environment that require Skills & Capabilities that are still low in those teams (and maybe the organization), as shown in the figure below. Think, for example, about how many teams in organizations nowadays still lack the proper skills and capabilities in Data and AI. Still, they do have the “pressure” from the market, competitors, and customers to build products with those features.


Organization with low skills/capability
Figure - Organization with low skills/capability level to address a particular new need



Now, how can teams and the organization address the situation of insufficient skills and capabilities to meet a need in the environment? In the following, we explore two possible options.

Option A: allow each team to figure things out in isolation without any support

One option to address upskilling and improving on a given capability is to let teams figure things out on their own when they face a new challenge or need. I would argue that allowing teams to do that is natural and essential for them to truly understand the problems they are facing and, with that, learn the important things in their context. Striving for this team autonomy and agency to explore their problems is crucial. However, particularly in larger organizations, as shown in the Figure below, if teams take this to the extreme and always perform this learning and improvement in “isolation”, that can be a problem. In such situations, when each team is trying to solve the same type of challenge within its scope and never connects with the broader organization’s context, they miss the opportunity to leverage each other’s learnings to accelerate their overall improvement in those new capabilities.


Each team addressing the need in isolation
Figure 10 - Each team addressing the need in isolation



The outcome of that “learning in isolation” tends to be “slow response times” due to low skill/capability. However, that is not the only problem. In such situations, when teams are creating their solutions, they will very likely produce lower-quality solutions, since their skill and capability levels in the topics are still low (remember, they are just starting to learn and shape those new capabilities). Still, given the urgency of things, teams will naturally be pressured to move fast and respond to those needs. Bottom line: they will build those solutions anyway with lower quality.

The outcome is that by building solutions with low skill/capability, they will create “debt”, meaning they will eventually need to come back and rework those solutions, which will take them away from more important activities.

Bottom-line: Lower Return & Quality of Investment (R&QoI). When many teams work in isolation, without expert support, to learn and address a new or immature capability within the organization, we will likely observe slower, lower-quality responses that will eventually require rework.

⚠️ teams need to “struggle” to learn - I want to reiterate that I am not saying teams should not spend time “figuring things out on their own” (i.e., “struggle”). That should ALWAYS happen. However, as organizations, we also want to leverage dynamics that accelerate the learning and consolidation of new skills and capabilities. With that, we allow those very same teams to be more effective and independent when working on the important (business) needs within their scopes of work.

Option B: Enabling Activities to accelerate learning and addressing of missing capabilities

In this section, I share an alternative way to help teams and organizations improve R&QoI (Return & Quality of Investment) and achieve faster, higher-quality responses, while accelerating upskilling and the development of new capabilities within teams and the organization.

This approach still builds on the principle that teams have the autonomy and independence to figure things out in their context. However, in this approach, we introduce the principle that teams facing those challenges (lacking a specific skill/capability) should be able to share/raise that they need support. That signal should enable support from “experts” to accelerate upskilling and address those capability gaps.

The figure below illustrates this approach. As we can see, when multiple teams have challenges with a specific capability (initially at a “low” level on that capability), which is vital to address a particular need, they should be able to get support. That support can take the form of an expert (or a team of experts) performing Enabling Activities through a “facilitating interaction” to help those teams with low skill and capability on a challenging topic. Ideally, these experts come from another team within the organization that already has experience and higher skill/capability on that topic. However, in some situations, there may not yet be any experts or expertise within the organization; as such, it may be beneficial to temporarily leverage external experts/consultants to accelerate upskilling and capability building.


Leveraging Enabling Activities to accelerate improvement
Figure 11 - Leveraging Enabling Activities to accelerate improvement on new capabilities



Fostering Enabling Activities and Enabling Behaviors

You probably noticed that I have used the term “Enabling Activities” to refer to the work of experts helping teams to up-skill and address missing capabilities. Over the past few years, I have been using this term (“Enabling Activities”) to generalize the essential behaviors of Enabling Teams from Team Topologies. From my experience exploring this topic, I have noticed that the most crucial aspect of “enabling work” is the behaviors and incentives that underpin it. We shouldn’t always need “official Enabling Teams” to do enabling work. When organizations try to “control the enabling work” and only permit it when an official enabling team is created, they will be strangling many natural/informal opportunities for effective continuous improvement in the organization.

Instead, I propose that organizations focus on fostering Enabling Activities and “enabling behaviors” to happen. Those Enabling Activities manifest in “facilitating interactions” that even single individuals (“experts” or simply someone who knows more about a topic than other people or team(s)) can have at any given moment. If, as organizations, we allow and incentivize those dynamics, we should see an overall increase in our ability to sustain continuous improvement.

Example: Improving Data Orchestration Capability

Let me share a real-world example to illustrate how Enabling Activities can play a pivotal role in accelerating the addressing of an immature capability in an organization.

This is an example from a scale-up e-commerce organization I worked with, with approximately 150 (product) teams (mostly stream-aligned teams, but also several platforms). By the end of the 2010s, the organization had a pressing need to strengthen its “data and data science” capabilities to cope with an ever-increasing number of customers and products sold on its platform. That need and demand from the environment led to increased urgency in up-skilling the organization and its teams across many data-related topics. In the following, I will zoom in on one particular example, namely, data engineering and the need for better ways to prepare and process data (“data orchestration”).

💡 If you are interested in more details and other examples from this company’s journey of up-skilling and scaling data and data science, you can check my video course on Effective Enabling Teams

At the start of that journey, multiple teams explored various approaches to building their data processing pipelines. This was new for many people, and naturally, each team spent time addressing that challenge and building a working solution so they could start experimenting, learning, and also generating value. At the time, this meant creating convoluted shell scripts (the skill teams had for the job), which would run overnight via cron jobs. This was fine for some situations and helped teams start moving and exploring the problem. However, as things evolved, jobs became more complex, and failures increased, it became evident that those approaches were not suitable in the long run. Failed data processing led to missing insights into dependent activities, which, in turn, affected the actual business (e.g., product sales or logistics processes). Furthermore, teams were spending a lot of time handling these issues and were unable to work on other essential activities.

At this time, we had a few Data Engineers and were hiring more to up-skill our capability in “data engineering”. Some of those, together with enthusiastic software engineers and data scientists, began exploring alternative ways to set up their data pipelines. I was fortunate to observe this, and more than that, as part of my work as a lead for the Data and Data Science discipline in the organization, I was also helping to create a community of practice around data and data science. Through those activities, we were fostering conditions and means for people to find and help each other more easily. In this example, we managed to support those few people who began experimenting with more robust ways to set up their data pipelines, forming a “Data Orchestration Enabling Team”. They started exploring some better tools for the job and helping teams improve their pipelines. This was happening in a rather organic way, via workshops, questions on the community of practice chat channels, “datathons” (yes, that’s what we called hackathons focused on data topics), etc.


Data Orchestration Enabling Activities Example
Figure 12 - Data Orchestration Enabling Activities example



The outcomes of those Enabling Activities (and the conditions for them to occur naturally) served as a strong accelerator for teams to set up better data pipelines, which, in turn, led to better business outcomes.

The business case for Enabling Activities

As I highlighted in the previous section, Enabling Activities can be a great accelerator for better business outcomes. These activities help teams accelerate their effectiveness and performance, which, in turn, should improve overall business outcomes.

Organizations must zoom out and observe these “macro advantages”. When we allow people performing Enabling Activities on a given topic (the “experts”) to help many teams, they become a strong multiplier and a strong return on investment. In the following figure, I contrast the two options I detailed to help teams learning and be effective on a new capability.


Business case for Enabling Activities
Figure 13 - The business case for Enabling Activities



Bottom line, if we create the conditions for Enabling Activities to occur in the organization, we will not only accelerate the development of the necessary capabilities but also, in most cases, achieve a better Return & Quality of Investment (R&QoI). This happens because, ultimately, we help accelerate learning across the organization, allowing teams to build higher-quality solutions faster.

Principles & heuristics for Enabling Activities

Here are some principles and heuristics to foster conditions for allowing activities to occur in organizations.

Focus on enabling “enabling behaviors”; you don’t always need official enabling teams. This is a fundamental principle, and one that should help organizations to improve faster and more organically as needs for improvement are addressed without the need for “official validations”. Obviously, we still want to support “official enabling teams” when the required effort is high. Still, it is fundamental that organizations allow more informal Enabling Activities to accelerate learning and improvement.

Provide space for people who know about a topic (“experts”) to help others with challenges related to it. This is directly correlated with the point of the previous paragraph - around allowing Enabling Activities and behaviors” to happen without the need for official enabling teams. Basically, the key idea is to allow the “experts” on topics where teams in the organization are still lacking to help upskill and improve that capability. This is how we help accelerate improvement in that capability within the organization.

Create sensing mechanisms to identify capability gaps and trigger Enabling Activities. Organizations benefit from creating sensing mechanisms that help detect and expose capability gaps. For example, this can be done through communities of practice, where people share the challenges they face and connect with others who know how to address them. Another way is to leverage the organization’s leaders and managers, who work across multiple teams. Typically, they can start seeing certain challenges (e.g., many teams struggling with testing in the new cloud environment) and raise them with peers, which may trigger dedicated Enabling Activities or teams to help with those challenges. When organizations are open, and in particular when teams are confident to ask for help and share what they are doing to address challenges, we have much better mechanisms to identify gaps and who may be able to help address them.

⚠️ The limits of Enabling Activities

As we have seen in previous sections, Enabling Activities are powerful accelerators for learning, validation, and capability improvement in the organization. Enabling Activities are particularly helpful when uncharted challenges arise, and the organization lacks sufficient capability to address them effectively. In such situations, it is essential to ensure that people with enough expertise in the topics can facilitate improvement activities for teams in need of support. This helps improve and accelerate the journey to address those capability gaps.

However, it is crucial to recognize that Enabling Activities are only one of the strategic patterns for improving and scaling capabilities in organizations. As teams and the organization increase the skills and capabilities in a given topic, the reliance on Enabling Activities — particularly on experts in that topic, discipline, etc. — to support the continuous scaling of that capability across the whole organization can become a problem and bottleneck.

🟠 Why is relying on Enabling Activities problematic when capabilities start to mature? As maturity levels for capabilities increase, we also tend to see greater adoption (e.g., number of teams) of the “emerging artifacts” created to support them. For example, during these initial phases, people engaged in Enabling Activities, and pioneering teams may start creating programming libraries, tools, processes, and documentation that support teams in addressing challenges in those topics. In a sense, as depicted in the figure below, at this stage, the people driving Enabling Activities (“experts”) often also become the curators of (emerging) “components” that support those capabilities. These basically start allowing many teams in the organization to “self-service” (XaaS interactions from Team Topologies) to accelerate their work and improve the quality of delivery that requires those capabilities. At this stage, however, the adoption of these components and the leveraging of these capabilities typically increase within the organization beyond the initial pioneer teams.


Limits of Enabling Activities
Figure 14 - Reaching the limits of Enabling Activities



At this stage, if the level of work to support those emerging capability self-service components is too high, this can become a problem. The reason is that the people driving these developments on those capability components are typically also doing many other things. Ideally, they are also working on stream-aligned teams (product teams), creating customer value.

This is a pivotal moment for these people (who are performing Enabling Activities) and for the emerging components being created to support that capability within the organization. As depicted in the following graph, in this phase, the emerging capability maturity is reaching higher levels of maturity, and so are usage levels, as it is useful to more teams. This is why this is a pivotal phase: the quality of the artifacts developed and maintained by people performing Enabling Activities may become a liability for the organization. For example, if these artifacts fail or require swift improvements but the people maintaining them are too busy with other activities, it will block many teams. If that happens, this can become a problem for the organization.

I am naming this pivotal phase “scaling assessment” (or “scaling readiness”), and the key idea is to take the signals highlighted in the previous paragraphs into account and determine whether to explore suitable scaling strategies for the emerging capability as we move forward.


Scaling assessment phase
Figure 15 - Scaling assessment phase



💡 Stretching Enabling Activities helps us assess the need for scaling: I want to reiterate that this phase, where we are reaching these limits or Enabling Activities, is not a bad thing. Sometimes I use the wording “do it until it starts to hurt”. The ida is to not optimize things before it actually is needed, i.e., understand we are probably reaching the limits, and we do not optimize prematurely. Organizations should not try to avoid this phase at all costs. I would even argue that these phases are very important as they allow us to shape emerging capabilities in organizations. We do that by working on the problems teams have and the expertise of the people driving and pioneering the necessary Enabling Activities to start curating these capabilities and the emerging components to support effective work on them. Making it a highly effective and strategic organization improvement pattern. In a nutshell, we are validating these emerging capabilities by addressing the problems faced by stream-aligned teams working on real business problems.

With this understanding of the emerging nature of capabilities, it is crucial to recognize that in this pivotal phase, we need to continuously monitor whether we are approaching the scaling limits of Enabling Activities and explore suitable scaling strategies. In the following, I share some signals and heuristics to help navigate and understand this pivotal phase:

  • Quality of components: When many teams rely on these components, they should be of sufficient quality.
    • 🔎 Heuristic: Are the Enabling Activities sufficient to ensure the quality of the self-service components teams need?
  • Timeliness of component evolution: When emerging components become critical to many teams and require significant ongoing support and time, the people doing Enabling Activities may not have.
    • 🔎 Heuristic: Are the people doing Enabling Activities able to respond promptly to changes needed in the self-service components that teams are relying on?
  • The cost of failure is high: Many teams in the organization become reliant on emerging self-service capability components. If they are not working well, they become a major blocker to the important flow of value creation for teams.
    • 🔎 Heuristic: Is the criticality and cost of failure of these emerging components so high that we can’t afford any failure, nor a slow response to improvements?

By observing these signals and using these heuristics, we can adopt a more rigorous approach to decide whether we need to, or not, change our reliance on Enabling Activities to support those emerging capabilities components. When we validate that the current approach is not suitable anymore, i.e., when “it starts to hurt”, and the need for more scalable, stable support is clear, we can consider the next strategic move: explore ways to scale the support (and further growth) for those capabilities and the emerging artifacts that support them. A way to achieve that is to explore introducing dedicated support platforms that consolidate those emerging capabilities and provide the time and skills needed to scale them to more teams in the organization with the necessary levels of support.

💡Sometimes we may decide NOT to introduce scaling mechanisms, and continue relying on Enabling Activities.* In some situations, we may conclude that we don’t need to introduce any changes, e.g., dedicated supporting platforms. That may be a valid scenario, particularly if those emerging artifacts are (still) fully supported by the people in stream-aligned teams and people doing enabling work, and there are no signals of challenges with that. In a sense, this move to improved scaling mechanisms (e.g., platform-based scaling) should be motivated by a genuine need. Bottom line: organizations should continue listening for those signals and recognize the need for this transition.

Scaling emerging capabilities and value creation with Platforms

The following diagram provides an overview of the typical phases that tend to lead to the scaling of emerging capabilities through dedicated platforms and supporting platform teams.

In the previous sections, we have elaborated on the first two phases, which revolve around the learning and validation of capabilities with Enabling Activities, namely:

  • Phase 1) initial Enabling Activities to support (pioneering) teams on starting to address a missing capability (which is essential to respond to a need of customers or market);
  • Phase 2) framing of the emerging capability components to help start supporting more teams in leveraging that capability.

After these two initial phases, and in case we validate the need for more robust, dedicated scaling mechanisms from the teams building the business value offerings.

The scaling of these emerging capability components tends to follow these two phases. This pattern is very interesting because it allows the emergence of platforms from the very contextual needs of teams that are starting to leverage a particular capability. In a sense, this allows for a much higher degree of understanding and “business-driven motivation” for a platform that can provide a more scalable “self-service” offering of this capability to a broader range of teams in the organization.


Phases of Enabling and Platform org dynamics patterns
Figure 16 - Phases of learning, validating, and scaling new capabilities in organizations using Enabling Activities and Platforms, org dynamics patterns



By following this pattern, we avoid the “anti-pattern” of “build a big platform upfront, and hope people will just use it”. We turn things around and basically start framing and validating the actual platform from the specific needs and work teams are doing.

The following graph is an iteration on the capability maturity graph introduced in previous sections, which adds the “platform scaling” phase. In this phase, the level of capability development tends to be higher and directly correlated with the organization’s usage of the capability. This is yet another important heuristic and validation of the “business case” for platforms: they enable many teams to effectively leverage a strategic capability to build value for the organization.


Platform scaling phase
Figure 17 - Platform scaling phase



Example: Data Orchestration Platform Capability

To better understand these phases of upskilling and addressing a particular new capability, let’s return to the example I introduced in a previous section about leveraging Enabling Activities to improve the capability of building better data pipelines and orchestration.

As discussed, we had a group of people pioneering improvements in data pipelines and orchestration capability. Initially, that group focused on creating better, more robust bash scripts and cron jobs, but over time, that approach reached its limits. Eventually, some of them started exploring other tooling. One such tool was Apache Airflow [Apache-Airflow], which at the time was becoming the most popular tool for data orchestration jobs.

At this phase, those pioneers started successfully experimenting with Airflow in their own teams. They had many discussions and validated that this could be a more robust solution for most teams. As they were doing that, they began consolidating several customizations and elements to improve integration with the organization’s platform systems (such as monitoring and security). By doing this, and as discussed in the previous section, these people were literally shaping and maintaining this emerging artifact and capability. This worked well and, in fact, became a huge success, as it was adopted by more and more teams seeking better, more robust data pipelines.

As we progressed on this journey, we continued running experiments and validations with teams, including organizing several “datathons” and workshops to help them learn and leverage this tool. The positive outcomes even led us to start having regular Airflow training sessions led by external experts, so we could accelerate upskilling more people on it.

All of these different learnings lead us to conclude that Airflow was definitely valuable and helped teams set up more robust data pipelines.

However, as time went on, the small group of engineers responsible for Enabling Activities to support the Airflow custom solution (optimized for our company’s infrastructure) began to face challenges maintaining and evolving it. At that stage, 20+ teams were leveraging Airflow to manage their data pipelines better. Given the demand and increasing importance of this tool, the signals were clear that we needed to pursue a more scalable approach.

The interesting thing is that during this journey (of several months), some people from the organization’s Data Platform had become increasingly involved with the people doing Enabling Activities. They started helping with various activities, including contributing to essential integrations with company platforms (such as monitoring, alerting, security, etc.). This gradual involvement led to a simpler, more natural move to consolidate this emerging capability artifact into one of the organization’s platforms. I still consider the behaviors of the people on the Data platform a prime example of how to behave as a platform team. They recognized the potential of this emerging capability and deliberately began working closely with the people leading those efforts to learn and support them as best they could. Such behaviors made the eventual transition of Airflow to the Data platform much simpler.

That transition effectively happened as a “collaboration” between the people performing Enabling Activities (and effectively leading the development of the Airflow custom solution) and people within the Data Platform who would become the new owners of that emerging capability component. The goal of the collaboration was simple: define how to better consolidate Airflow within the Data Platform, with high-quality support from a platform team that would continue to evolve and improve it. We can see this gradual evolution in the following diagram.


Example of capability evolution in organization
Figure 18 - Example of the evolution of capability in an organization



Striving for emerging platforms

The example I shared in the previous section is a great illustration of how platforms emerge from teams’ actual needs, while leveraging stream-aligned teams and Enabling Activities along that journey.

I have seen this pattern manifest multiple times across different contexts. I discuss it at length in this podcast episode with Jabe Bloom [EnablingPlatforms-Podcast]. The latest version of the Team Topologies book also explains how ING Bank uses this pattern in its platform discovery approach, leveraging stream-aligned teams’ challenges to drive the first “validation” activities and to provide specific context that allows potential platform components to emerge. This natural, problem-driven emergence is powerful, and with the right Enabling Activities to support it, it can be a highly effective way to shape the platforms the organization needs to create the value it aims to create.

Bottom line: when platform capabilities emerge from the needs of the teams that have the problems the platform aims to support, there will be a clear understanding of the platform’s actual needs. This emergent approach to platforms also has the advantage of naturally providing a clear “business case” for investing in platforms.

In this article, I emphasize how this journey can be even more effective when organizations leverage Enabling Activities. The combination of these two patterns enables a faster, more effective, and sustainable way to build platforms, particularly compared with building big platforms and then applying the “they will come” approach. The “big upfront platform” approach is risky, as it often creates the wrong thing, which is then not used because it does not meet its users’ needs.

Principles & heuristics for emerging Platform capabilities

Here are some principles and heuristics to foster the emergence of platform capabilities in organizations.

Platforms should be emergent, driven by specific teams’ demands; often, by specific teams’ problem/solution explorations. As organizations, we want to create business value, which is the leading reason teams exist. Platforms should emerge as a means to support that. This is why teams building the customer-facing value must explore the problems they face and potential solutions to address them. Platforms should emerge from those activities - typically as a means to scale a non-differentiating, but important capability for teams to build value.

Always strive for a minimal platform (or “Thinnest Viable Platform”). We want to build “just enough” of the platform capabilities needed to support teams. As noted earlier, we want demand for extending those capabilities to be driven by specific challenges teams face.

Platform investment is a strategic multiplying investment. When platforms emerge from teams’ specific demands and are solving a real problem for them, they become strategic, multiplying investments. This happens because investing in a single team helps many other teams in the organization increase their effectiveness, leading to a high “Return & Quality of Investment” (R&QoI).

Experts who drive early-Enabling Activities can become strategic founders of new teams that own those capabilities. The experts who help teams explore a new capability gather a lot of context and understanding of the needs that the scalable platform capability must encode. That makes them strategic people to actually build those platforms. Obviously, this is not always possible; still, those people should at least be highly involved (“collaboration” interaction mode) with the people who would be driving the consolidation of the emerging capability in a platform, so their knowledge and understanding can be taken into consideration.

Summary: Enabling + Platforms organizational dynamics patterns

In this section, I provide a summary and consolidation of the “Enabling + Platform organizational dynamics patterns” introduced in this article.

The figure below describes the essential elements and typical phases of this pattern, which are typically three:

  • 1: Accelerate learning of new skills and capabilities with Enabling Activities
  • 2: Validation and consolidation of emerging capabilities with Enabling Activities
  • 3: Scaling of emerging capabilities in platforms


Typical phases of the Enabling + Platform pattern
Figure 19 - Typical phase of the Enabling + Platforms org dynamics pattern



It is important to acknowledge that these three phases may manifest differently across organizations. This is not a clear and predictable journey. That is why I like to position this as a pattern: something that tends to happen when certain contextual elements occur, in this case, when the need for a certain new skill and capability appears and increases over time, we most likely benefit from Enabling Activities as a way to accelerate upskilling and shaping of a new capability in the organization.

Over time, as demand for and reliance on those emerging capabilities increase and become more critical, we can explore dedicated platforms and teams to support and further evolve them.

Enabling + Platforms at the same time

At this point, I have shown the typical timeline and the importance of leveraging Enabling Activities to frame and help build effective, robust platforms. However, I want to highlight a crucial element (and something I still see as a common mistake in many organizations). As we begin consolidating emerging platform capabilities, we may still benefit from continuing to enable activities. Enabling Activities may still occur even when we have platforms consolidating the capabilities related to such Enabling Activities.

This may look like a nuanced detail, but the fact is: teams in an organization will continue exploring and evolving those capabilities (which are being consolidated into platforms), and oftentimes they will face challenges that can benefit from the support of experts in those capabilities (via Enabling Activities). This is why it is strategic to not “strangle” the Enabling Activities when platforms start emerging to support a given activity. This is, in my view, a strategic organizational dynamic that, when leveraged appropriately, can lead to faster learning and improvement of capabilities. Namely, we can use experts (who may be people from the new platform or experts on teams) to accelerate addressing a new need that requires improving an existing capability, and at the same time, leverage those learnings to improve the platform.

In the example I shared earlier, I saw this happening in the first place. Platform consolidated Airflow as a platform component in the Data Platform. However, over time, some teams began performing more advanced activities, which required features not yet available on the organization’s Airflow platform component. The people who were initially doing the Enabling Activities, together with the platform team that owned the Airflow component, sat down with those teams, explored the problem they faced, and began exploring how they could leverage more advanced Airflow features to solve it. Those learnings were quickly embedded in the platform component, which became available for all teams in the organization.

Bottom line, as depicted in the following diagrams, Enabling Activities should be continuously leveraged to address missing skills and capabilities for new needs in the organization (even when we already have platforms for those capabilities). All of those explorations are the best signals to continue evolving the existing platforms supporting those capabilities, as we are improving faster to respond to the needs we have and, at the same time, consolidating those learnings on a scalable platform that can serve the whole organization.


Enabling + Platform org dynamics pattern overview
Figure 20 - Overview of Enabling + Platform organization dynamics pattern



Supporting Continuous Sustainable Improvement

The primary outcome of leveraging these patterns is creating conditions that support continuous, sustainable improvement.

By leveraging these patterns, we can respond to the environment’s needs and demands by gradually and sustainably building the necessary capability.

Coming back to my Needs => Skills/Capabilities => Response thinking model: we are basically maximizing our ability to equip the organization to learn, design, and decide more effectively. This is crucial, as these cycles will never end; it is an infinite loop of improvement. Like everything, the first “cycles” may be more difficult. However, when organizations begin practicing these principles and behaviors, they increase their resilience and their ability to do so better and faster.


Infinite cycle of improvement
Figure 21 - The infinite cycle of improvement



Goal: Support Stream-aligned Teams to respond faster to needs

As a final point, and to reiterate, our goal in investing in these dynamics that support continuous, sustainable improvement is to ensure that the stream-aligned teams responding to the needs of the environment always have the necessary capabilities to do so effectively.

As shown in the diagram below, they will do that by:

  • Platform: “self-service” from platforms capabilities, so they can effectively build the things they need without having to wait on support from anyone else outside of the team.
  • Enabling Activities: by getting support from experts to address a “skill/capability gap” in the team that is new, and not provided by a platform, which is needed to effectively respond to the environment (i.e., teams should be able to “pull” experts to help them when needed).
    • Learnings from these new explorations can be potentially consolidated in the relevant platforms.


Three layers
Figure 22 - Stream-aligned with Platforms and Enabling Activities



When we foster conditions for these dynamics to occur, we ensure that our customer-facing teams, who create value for our organization, are better equipped to respond to the continually emerging needs in the environment. This ability is crucial for organizations to thrive in the “fast-moving” times we live in, where, as we saw in the introduction to this article, uncertainty and rapid change are unavoidable. These dynamics also make sure we are building the right platforms, the ones that support the organization respond more effectively to the needs in the environment. This is why the Enabling + Platform organizational dynamics patterns are strategic to support continuous sustainable improvement.

Appendix - Extra Examples

The patterns shared in this deep-dive article occur across many different situations. It is not exclusively for technology and tools used by engineers on teams building the organization’s products. In the following, I highlight some other examples I have observed and worked on over the years.

Scaling data science discipline, capability, and platforms

I have in the past leveraged Enabling Activities as a means to help frame and improve the Data Science discipline and capability at bol.com (the largest online retailer in the Netherlands and Belgium). We used Enabling Activities to help teams upskill and shape necessary capabilities to do that at scale. That meant also a gradual introduction of supporting platforms. This happened around 2018-2021, but this sort of work on shaping data, data science or today AI capabilities in organizations is a highly relevant to many organizations. If you want to learn more about those details, check the case study of my video course on Effective Enabling Teams.

Towards sustainable architecture capability with Enabling + Platform patterns

Over the past few years, I have applied the very same patterns (Enabling + Platform) to position Architecture capability (and, in some cases, Architects) in organizations striving to improve their approach to architecture. I have discussed the idea of “Architecture as Enabling Team” since 2021 (https://esilva.net/tla_insights/architecture-topologies). Still, over time, I also explored the idea of “Architecture Topologies” (https://esilva.net/architecture-topologies), and what I started noticing is that, for organizations to improve, they need to explore mechanisms that allow “anyone” (read: “not only a few architects”) to drive architecture in the organization. In a nutshell, to achieve fast flow of value more people should be able to learn, design and decide, not just a few people (architects). To achieve that, leveraging platforms as a means to consolidate essential architecture elements for the organization is key (think principles, ways to align - ADRs, RFCs, Advice Process, etc.). I have seen this work really well in several organizations at this level of architecture capability maturity.

References

[Apache Airflow] Apache Airflow, https://airflow.apache.org
[EmergentPlatforms-Podcast] Emergent Platforms, Platform Thinking podcast, https://esilva.net/articles/emergent-platforms
[Engagement-Gallup] “U.S. Employee Engagement Sinks to 10-Year Low”, https://www.gallup.com/workplace/654911/employee-engagement-sinks-year-low.aspx
[OST] Open Systems Theory, https://opensystemstheory.org
[Team Topologies] Team Topologies, https://teamtopologies.com

ℹ️ I offer consulting services and products on this topic

If you are looking for help on these topics feel free to contacting me, and/or check my consulting and products pages for more details on how I may be of help.