On the 20th of July, 2023, I had the pleasure of being on Jabe Bloom’s (and Ergonautic) Platform Thinking podcast.

Jabe is someone I genuinely admire: he has a lot of firsthand practical experience helping organizations improve their sociotechnical systems, but he also has deep knowledge of theories and concepts crucial to achieving more foundational change and improvement. He is one of those people that can bring these practical and theoretical ideas together into highly pragmatic and usable thinking models and practices. I often refer to his work in my consulting activities, for example, Ideal Present, Three Economies, etc.

I feel thankful for having the opportunity to have this conversation with him on a particular angle of platform thinking that connects with a lot of topics I have been working on over the last few years (and now am actively helping organizations with my consulting activities), namely: the emergence of platforms from business grounded problems and opportunities, and the product teams exploring those (and many aspects related to this).

(We did not go into other possible genesis of platforms, such as internal products in organizations that are natural platforms supporting specific domains in the organization that provide essential capabilities to customer-facing product teams… but a lot of the ideas and dynamics discussed could be equally applied to those teams).

In this article, I list some of the highlights from our conversation and share some “raw thoughts” on those as a way to “write down” those (while they are fresh on my mind - it ended up longer than I thought initially, so feel free to use the navigation below to zoom into what is more interesting for you).

Thank you for having me, Jabe! It was fun!




Topics discussed:

What is a Platform

“Something that exists in an organization that curates products and capabilities that benefit multiple product teams, and where those teams can stand, rely on and build differentiating offerings.”

This was my starting working definition of platform. It highlights what I consider essential traits of platforms: something that helps abstract shared and supporting capabilities, which help alleviate the cognitive load of product teams (as they don’t need to maintain those capabilities themselves), but also build and provide qualities that are essential to allow many teams to reliably “stand on it” over time.

Valuable and usable Platforms tend to emerge and evolve from the business challenges, opportunities, and environment

This was the point Jabe and I spent the most time.

Jabe highlighted that platforms tend to evolve into consolidating “commons” or shared capabilities. But where is that coming from?

My remark was: valuable and usable Platforms tend to be driven by demands/forces around the business and its environment. This can be new customer needs, new competitors offerings, technological changes, etc. In organizations that position and allows their customer-facing product teams to “listen to their environment,” they will sense and notice those “forces” and take action. The action can be to start building a new product feature requiring a new capability. For example, this may be a new technology or method that the organization does not yet know but seems highly effective to help build this new functionality to solve the challenge or address a specific opportunity. As that “pioneering product team” starts learning about that topic and using those technologies/methods effectively in its scope of work, other teams may also start seeing the value of that capability. This can happen in many ways; for example, the team demoed that to the whole org, and other teams saw an opportunity to leverage those ideas. In time, that capability and the knowledge around is increasing and being further developed in the organization. With all of that, the tendency is that more teams may be more equipped to see opportunities to leverage it. And this is when the question of abstracting this to a platform-supported capability arises and may happen.

So, we came to discuss this journey of learning and validation by the product teams - which I have seen multiple times (and shared some examples with Jabe). This highlights the importance of letting the organization (and its teams close to the problems or opportunities) help to “curate” what that platform capability should be. In many cases, no Platform team is yet “facilitating the journey.” This may be something completely new in the organization.

This situation also highlights the importance of Enabling Teams and allowing people on Product Teams to apply Enabling Teams’ behaviors (I discuss this extensively in my video course about Effective Enabling Teams). Enabling Teams and allowing people to pioneer the shaping of new capabilities (and skills) in the organization is a means to learn more (up-skill, increase learning and knowledge) about that topic. This allows us to validate whether that is useful, and from there, and from the teams experimenting with those things on their products, decide if this is something we should invest in and consolidate as a platform capability.

Jabe highlighted an essential aspect here: the ability to apply different levels of quality as we are doing this - in particular, as we are experimenting with new things, we want to validate if this would be helpful. If that is the case, and as more teams are seeing the value, when we bring that into a platform capability, we want to make sure this is high quality and can be used by all of those teams without problems (e.g., breaking down all the time, or continuously changing APIs that require significant changes for all teams using it, etc.).

In my view, this topic of discussion is crucial and one that organizations should consider to avoid the significant challenges of “buying platforms” that are not valuable and usable for teams trying to solve business problems.

Other interesting ideas and topics we touched

We have touched on several closely related topics, which I list and give some insights on. Check the full podcast for all the details - and feel free to contact me for more details or discussions.

How to incentivize product teams to share their ideas, developments and, when applicable, help to consolidate platform components

This is a fascinating and challenging topic I have seen multiple times manifesting in different organizations: when can teams understand it is better to consolidate a particular capability into a platform?

Jabe and I went into discussing how can “modern Architects” (and cultures and structures in the organization), focusing on enabling teams to improve “learning, designing and decision-making”, help on creating conditions and opportunities to allow teams to share their insights, learn and share their learnings with other teams, and also facilitate the sensing and noticing that a certain capability should be “promoted” into a platform capability.

I stressed that this is more than just the job of architects or teams that suddenly start doing that. It is a journey that requires creating incentives and a culture where people in the organization feel comfortable applying these “enabling behaviors”: learning and helping others learn and improve. Also, avoid penalizing people (pioneering new ideas) from doing those things, which may not always be directly building a product feature - it may require extra work, helping others, etc. However, these behaviors and ways of working should help implement these ideas of discovering valuable and usable platform capabilities from the business problems that product teams are facing.

Swarming of pioneers can be highly effective in accelerating the shaping of valuable and usable platforms

Jabe raised this vital topic, which is: although we know that long-loved teams around specific scopes of work make sense when trying to understand what are valuable and usable platforms, it may make sense to allow the pioneers of those ideas to swarm, figure out, and validate what would be the most interesting manifestation of that platform capability.

I shared a very interesting example I experienced - where pioneers from product teams came together, and some people from platform teams were working on related topics. The platform’s involvement here was strategic, as we had validated we needed to do this, and we knew this would end up in the platform. So, leveraging all that knowledge was a strategic move to maximize our ability to have a better design and decision.

Enabling Teams is strategic to co-evolve platforms and even avoid unnecessary platforms

This is a topic I am passionate about. It is a strategic pattern for organizations to leverage: not all the ideas and challenges product teams have should be platform components (just because multiple teams are facing that challenge). At least, not without further exploring that with those teams - and involving people who are more knowledgeable on those topics. This is where Enabling Teams make sense (and in general, the behaviors around Enabling Teams - i.e., we may not always need an official Enabling Team - check my video course on Effective Enabling Teams for more guidance and ideas on that). These can be leveraged to address that missing skill or capability and explore it firsthand with the people/teams facing that problem. Those explorations are critical to learn further and validate what the problem is and what possible solutions could be.

In some cases, the solution may be that this is indeed a platform capability that an existing platform team needs to consolidate. But even in those situations, the learnings and some work that happened while the Enabling Team worked with those teams facing the challenge. So, the knowledge and artifacts produced can be leveraged to accelerate Platform shaping of the new platform capability.

In other cases, no platform team is yet catering to that capability. When that happens, it may even be an excellent strategy to get some of the people that were exploring the possible solutions to become that platform team (this depends on multiple factors, including people wanting to do that sort of work, having the openness to work on a platform team, etc.).

Unlike customer-facing features, Platforms should not be around bets

We had a good discussion on this: platform capabilities tend to be used by many teams, who expect high levels of reliability, etc. The dynamics there are different from what product teams may be doing, experimenting with new ideas with customers. This is important and should be considered when building platforms: they are more about consolidating validated learnings. Platform teams still need to understand what they should be doing. However, some of those learnings and experiments are happening outside the platform (see next point for more details).

A lot of the Platform experimentation tends to happen in the Product Teams exploring new features - this helps Platform Teams’ cognitive load

Following the main point of discussion of our conversation: the idea that a lot of the platform capabilities come from business challenges and opportunities that product teams are working on, we can argue that a lot of the experimentation on what should and not be part of platforms is happening outside of the platform. This is why Platforms should continuously listen to the product teams’ challenges, opportunities, and explorations. They don’t need to be highly involved in everything, but creating ways to “sense what is happening” can provide excellent learning opportunities and accelerate their discovery of the essential things to consolidate in platforms.

Approaches to Architecture need to embrace continuous change and require embracing and enabling more learning and evolution

Although Architecture was not the podcast’s main topic, we naturally gravitated to the importance of how organizations approach Architecture to enable many of the ideas we were discussing - especially this emergence and consolidation of valuable and usable platforms.

We discussed how important it is to modernize how we approach architecture, moving from “controlling” to more “enabling” approaches to architecture. This is a topic I have been thinking about and doing work on over the past few years - and I call it “Architecture Topologies”.

What we ended up discussing is that it is essential to help organizations grow into these thinking models and ways where teams and people close to problems can leverage their knowledge (and knowledge around them related to those challenges) to better design and decide on how to address the challenges they are facing. That becomes a natural key enabler to identify organizations’ most valuable and usable platforms eventually.

Organizations need to create space, opportunities, and conditions to help break silos - make that explicit in the organization’s strategy (it is a journey)

Connected with the previous point (modernizing approaches to architecture), another essential aspect of modernizing is the “breaking of silos” between different departments and disciplines in the organization (e.g., classic Product and Tech debarments, Business and Architects).

Jabe and I had a great discussion on this, and as Jabe said: “We can get the best car - an F1 - for you, but if you can’t drive it, it is of no use”. This is precisely what happens when each department or discipline thinks only from their perspective: you get something that does not reach the best outcome when inter-connected with the other perspectives.

This is why it is crucial to invest in breaking these silos. This is happening increasingly, but I still see much of this when working with different clients. This hinders the whole point we discussed in this podcast: enabling learning and maximizing the knowledge to figure out the best options we have to explore now - and where we should be moving towards.

ℹ️ 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.