On platform adoption: essential mindsets and approaches
Platform Engineering Primer, Part 2. The second in a series of articles exploring how developer platforms benefit modern businesses.
Join me as we explore the intricacies of platform engineering. Let's take it apart to find the effective strategies, practical ways of working and technologies that fit your needs and circumstances. Above all, let's explore how internal developer platforms are becoming a gateway to business success.
The pursuit of 'solving the right problems for the right people' is undoubtedly crucial. It is a key element in the broad range of challenges associated with platform adoption. The overarching challenge is multifaceted and transcends a single perspective. Navigating its complex landscape requires a variety of mindsets. Achieving seamless platform adoption requires a diverse combination of approaches.
By considering adoption as an internal sales process, this article explores the complex dynamics that influence adoption, encompassing human and technological dimensions. I'll walk you through the nuances of a platform initiative in its adoption stages, highlighting the key factors essential for a successful adoption journey aligned with your organisation's objectives.
My aim is to give you a broad understanding of platform adoption. This will enable you to discuss it comfortably with your colleagues before your organisation starts to adopt a platform.
The platform promise: economies of scale
Platform engineering delivers the most value when used in larger organisations with multiple teams and hundreds of engineers. However, it also brings value in smaller organisations where a lot of people use the same patterns or share the same infrastructure. But in most cases, the potential economies of scale of a developer platform are lower without a large group of potential users. To make a developer platform initiative sustainable in the long term, you need to build a critical mass of users. Looking ahead, there are several ways to deliver on this promise, including:
Solving developer problems, those that are possible to solve at scale.
Getting buy-in and strategic alignment.
Starting internal marketing early.
Finding the right time for the change to happen.
Establishing a community to scale up.
Dealing with internal competition and politics.
These considerations arise throughout the lifecycle of a platform, as illustrated in the diagram below.
At the top of the diagram you can see a star labelled 'trailing indicator'. The star shows the point in the lifecycle where the results of 'solving the right problems for the right people' are apparent. This brings us to the next issue.
If “solving the right problem” is a trailing indicator, how do we direct our platform initiative?
It’s true that failure is inevitable if you don't address the issues that affect your users. However, the key is to prioritise the developer experience and work closely with early adopters. This interaction provides the invaluable feedback needed to effectively steer the course of the platform. In essence, the success of your platform initiative relies on continuous improvement, fuelled by the first-hand experience of these early user developers.
The initial capabilities of a platform are relatively predictable or will have been defined in your mission statement. Once the initial scope of work has been delivered, identifying new friction points and work opportunities becomes a bit more of a puzzle. The factors that make it more tricky are:
Establishing a strong connection with users (your developers) is crucial. It helps to identify current technology trends within your organisation, understand how users interact with technology and identify their specific challenges.
Using common sense and critical thinking is essential. For example, it's important to overlook the vocal minority who keep raising issues or tend to exaggerate the impact of a problem.
Carefully choose your problems: Develop solutions for 80% of your users' challenges and ignore the remaining 20%, as the last 20% can often be difficult and add unnecessary complexity.
So what's the plan, you ask? Well, let's start with an introduction to the product manager and how they can steer the direction of the platform through a streamlined process that makes collecting feedback from early adopters more structured. This includes:
Continually exploring the problem space by researching and understanding user challenges.
Building relationships with people inside and outside the organisation.
Synthesising insights into actionable work.
The growing preference for a product-led approach to platform engineering underlines the key role of the product manager in ensuring the success of platform adoption.
Here's a story from my own journey that shows how the lack of a dedicated product manager on the platform team created significant challenges that almost derailed the entire project.
Although I had expressed the need for product management skills in my team from day one, we started to consider building another platform with the stakeholders. Finding the right person with the platform engineering skills and mindset took time and effort. Due to budget and time constraints, I ended up hiring someone who quickly proved unsuitable for the role and had to let them go soon after. We delivered an initial platform concept model, with a clear gap in our team’s capabilities, while we were still looking for a suitable product manager. This was only possible due to a long-term relationship with the client and a relatively accurate understanding of the organisation's dynamics. The architecture, technology choices and platform boundaries were well-defined and, interestingly, have remained largely the same ever since.
Soon after building a prototype, another product manager joined our platform team, this time from the client's organisation. It still took us six months to get to the point where our product management capability was efficient (for a variety of reasons, which I'll cover in a later article).
To complicate matters further, the company decided to change its strategy and look at cloud repatriation as an opportunity to reduce costs in the public cloud.
Our initial target was low-tier applications with a comparatively high infrastructure overhead. Unfortunately, under the new strategy, these applications were redirected to the private cloud.
This left us with a new focus on supporting the organisation's mission-critical Tier 1 applications, which were not as easy to move out of the public cloud. These applications required additional disaster recovery and security efforts, making it more difficult to convince teams to adopt the platform at its current stage of maturity.
It became clear that attracting enough early adopters from this category was beyond the initial scope of our platform project, leading to a significant reduction in the adoption funnel. This was a notable departure from our original strategy of starting small and expanding gradually. It was a moment to adapt to the new reality, and the presence of an experienced product person on the platform team made the transition much easier. The two most significant events were:
The company attempted to repatriate workloads on-premises, but the immaturity of the underlying platform led to friction and an inability to replicate fundamental capabilities from the public cloud. Despite the dissatisfaction of the development teams, it took the intervention of the product manager for others to realise the impracticalities. At this stage, the on-prem strategy still needed a lot of work, so it was good that everyone could see it.
A major effort to address a lack of understanding of the adoption problem. The product person played a critical role in managing stakeholders, raising awareness and defining a meaningful approach. This effort led to the construction of a comprehensive funnel for all applications, taking into account factors such as running costs, architectural complexity and dependencies.
Fortunately, we made it through this rollercoaster... Beyond the standard things like roadmapping, handling user requests and measuring user satisfaction, having a dedicated product person to actively manage stakeholders, ensure strategic alignment and advocate the platform to decision makers proved essential. It brought more harmony to the platform team, and balanced responsibilities so that engineers didn't have to switch between technical work and product advocacy, which they were not experts in.
How the product-led approach became popular
Traditionally, IT infrastructure departments have been a bit slow to catch up with application developers when it comes to modern techniques like API-first approaches or product management. And you know, the infrastructure team and the end users, the developers, aren't always the best of friends. Without that direct connection, infrastructure teams can sometimes end up creating more roadblocks than improvements.
What if we thought of developers as customers who pay to use our product, which happens to be an internal developer platform? In order to move towards this way of thinking, organisations are increasingly hiring dedicated product managers to work within their infrastructure group. These relatively new additions to the team often take on responsibilities such as:
Assessing how well engineering teams comprehend the existing technology landscape in the organisation.
Defining the desired level of support and the existing infrastructure maintenance burden.
Understand technologies and patterns that are currently used by developers.
Identifying essential challenges and pain points in day-to-day work.
Finally, exploring what products and abstractions should be built to optimise developer experience.
Understanding and applying the above responsibilities is a major step towards building a platform that solves the problems that have the biggest effect on your organisation.
In addition, product managers play a critical role in the platform adoption itself. This includes:
Advocating the platform product to other managers and decision makers within the organisation. At the same time, building confidence that the platform is well managed and that additional requirements will be addressed in a timely manner.
Establishing partnerships with other departments and bringing new capabilities to the platform that directly contribute to the adoption rate.
Prioritise adoption activities by providing additional insight into team onboarding timelines, expectations and key objectives found elsewhere in the organisation.
Engineers may not be well versed in stakeholder management, navigating political dimensions, or effectively communicating the value of the platform. The presence of a dedicated individual with these skills greatly enhances the potential of platforms as enterprise-wide solutions. When it comes to adoption, engineers and product managers work synergistically, like the right and left legs of a person. Together, they guide the entire organisation through the complex problem space towards the common goal. Product management addresses top-level issues such as stakeholder management, politics, and awareness, while platform engineers focus on supporting their colleagues, providing guidance on technology choices, overcoming obstacles, and more.
When is the right time to involve stakeholders and how much?
This question is particularly relevant in the context of an evolutionary approach, where the platform has evolved from an existing solution and now needs to scale. In this scenario, gaining buy-in from decision makers is critical to driving adoption. It's equally important to give non-technical decision-makers a sense of ownership, so that they feel invested and are more likely to offer their support.
If you are strategically launching your developer platform, you have likely secured stakeholder buy-in from day one, or perhaps you are a decision maker yourself. Either way, you will probably find this section informative.
Rather than waiting for the perfect moment to get buy-in from stakeholders, involve them and give them a connection to the early work. This helps to avoid the platform being treated as a pet project, or the technical work being done in isolation for a few months without any meaningful feedback. If we don't focus on stakeholder involvement early on, we run the risk of misalignment with business needs and limiting the platform's adoption potential in the long run.
Platform engineering efforts are typically enterprise-wide initiatives. These initiatives benefit from strategic management to maximise the value of the investment. It requires strong executive sponsorship from the outset and buy-in from other stakeholders in the organisation. The reason for this is:
Alignment with business strategy
We need alignment with the business strategy in areas such as technology choice, investment size or operating model to build something sustainable in the long term and meet the business objectives.The impact of late executive sponsorship
Late executive sponsorship hurts adoption, especially in a top-down organisation. Application teams do not have enough freedom to act, no real incentive and no dedicated time to adopt your product. They are often preoccupied with business-as-usual activities and not interested in another migration gig.Platform engineering challenges
Platform engineering spans multiple technology departments, glueing together other systems while inheriting failures and inefficiencies from outside. When the approach to the platform is strategic, you have more authority to remove infrastructure toil and friction. And the more seamless the experience, the higher the adoption rate.Navigate multiple platforms
There are likely other emerging platforms within the same organisation. If there is a lack of clarity around which applications to host on which platform, it leads to decision paralysis, where teams struggle to make choices. As a result, platform teams end up competing for the same user base, which is an unhealthy situation.
When is the best time to start adoption?
The timing of adoption frequently needs to be considered from two different perspectives: management and technical. These frequently divergent viewpoints must also find a way to agree.
Let’s go through how it works in three steps.
The fundamental aspect is to maintain the right balance between stakeholders expectations vs readiness of the platform. You need to bring awareness about platform maturity stages and how it relates to the adoption process. Sometimes a point of disagreement can be determining the value of such a platform numerically, for example how many people use it, while not assessing the actual impact on developer efficiency.
Gain a clear understanding of the current organisational strategy, identify the priorities that individuals are optimising for, and be aware of budget constraints. Approach these issues thoughtfully and, most importantly, be willing to accept trade-offs to avoid undue disruption.
Make sure that stakeholders are closely involved in the actual work, so that they experience the real challenges. The more decision makers are actively involved, the better. This is usually the responsibility of the product manager, who acts as the interface to keep everyone on the same page.
A comparison of the differences between these two points of view can also help us to understand how they might have a common purpose. Here's a table summarising the two perspectives:
Think of platform adoption in phases
Let's take another look at the developer platform lifecycle diagram. You'll notice that this time labels have been added to indicate key points in the life cycle.
On the other hand, the next diagram (below) shows the standard technology adoption lifecycle. It shares a similar understanding to the platform engineering lifecycle diagram. In particular, it shows a breakdown of specific target users and the need to adapt to different adoption strategies at each stage.
Phase 1: Early adoption occurs when the platform is functional but has limited capabilities. A good parallel might be a Thinnest Viable Platform (TVP), where platforms don't need to provide large feature sets and full automation. A careful balance between functionality and stability, with a semi-manual approach, is sufficient to assess the experience of using the platform in its early form.
This phase focuses on innovators and early adopters, and typically starts as an invite-only period with a limited number of teams supported (depending on the platform's team size and capacity). This has a positive impact on adoption, as invite-only creates immediate demand from innovators within your organisation.
Our main goal at this stage is to understand the problem and solution space before we start to scale the adoption. I suggest you conduct interviews with interested teams to assess whether they can truly work with you as a partner. Here are some tips on factors to consider as you and your early adopters enter this phase together:
It's important to find teams that are proactive and willing to take risks. Otherwise, collaboration and feedback will be limited.
Executive sponsorship plays an important role and should be considered from the outset. Such teams should have dedicated time to experiment and contribute.
Establish clear ownership within each team, with onboarding timelines and clear top-down communication from their manager, ideally before kick-off. Bear in mind that some teams may have distant deadlines and you should definitely avoid such teams at this early stage.
Once you have the first team on board, organise regular check-ins to monitor progress and identify common issues. Listening to people and giving them enough context about limitations and your struggles is far more effective than solely growing the user base at this stage.
From my observations, especially in a top-down organisation, it's a challenge to get development teams to opt-in because it's not in their remit to make the decision. The solution may be to provide a low-commitment sandbox environment to allow the team to evaluate the platform, help them get approval to opt-in, and then move quickly to the permanent environment.
In essence, the right time to start the adoption process is when you have found the right development team to partner with to pave the way together. Remember that all successful platform engineering efforts require a developer community as a foundation.
Phase 2 focuses on bridging the adoption chasm. This requires significant effort and solid traction for your platform, so don't chase it from the start. Advocating with an early adopter team to showcase success is key to reaching the mainstream market. This includes:
Start serious marketing efforts. You need to increase the visibility of your platform initiative and clearly communicate the value proposition.
Investing in reliability issues is important because it builds trust in your solution.
Establishing processes around onboarding, support and self-service to help platform teams scale and handle a larger number of teams.
Provide out-of-the-box integrations to help application teams save time and reduce duplication of effort.
Phase 3 is where the sceptics or laggards come onboard. These people tend to adopt the solution when all the other options are no longer available. Getting laggards to adopt typically requires some support from executives later on in the lifecycle. Work with your executives to drive adoption as a strategic goal.
Set up a process to get the community involved
Once you've established a connection with early adopter teams, it's important to keep them informed and excited about the platform. Stay in touch with your organisation's technology landscape, trends and how developers are using the platform. Immerse yourself in their challenges to truly understand their pain points.
Consider sending out monthly newsletters, hosting show-and-tell sessions, and giving demos of upcoming features. Make sure your communication is two-way, live, honest and open. Instead of relying on forms, set up 15-minute one-on-ones with user champions to get valuable feedback. Engage directly with your app team's engineers to understand and address their day-to-day challenges with your platform.
Other notable things worth doing in the community space:
Build a contribution model for the platform, starting simply with how to improve the documentation, request new features and what needs to be optimised.
Consider adopting a lightweight Request For Comments (RFC) process as an essential part of architecture and technology decision making. This helps to keep track of complex decision points, manage (and make visible) external dependencies, and provide specific discussion points. The RFC process enables the platform team to effectively gather feedback from users and other stakeholders, leads to better designs and promotes communication of the architecture. Asynchronous communication over long, unproductive meetings.
Establish the initial customer engagement process to understand their requirements, timing, external integrations and application context. Ensure that both the product manager and lead platform engineer participate in these meetings.
Track the adoption status with Kanban, when teams go live, key contact points and dependencies. Review this weekly.
Define a support model for the platform to tell users how to get help. Eventually extend this to full operations and incident management.
Relationship to other platforms within your organisation
In larger organisations, teams often build their own platforms. But most of these self-built platforms aren't ready for prime time - they lack proper standards, seamless infrastructure lifecycle management and robust security. They often lack essential components such as disaster recovery and a formal support model. Unfortunately, relying on such platforms increases the risk of accidental downtime across your organisation.
A strategic investment in platform engineering, on the other hand, gives you three options:
Consolidate multiple platforms.
Deprecate less strategic platforms.
A single governance model for all platforms.
Duplication and competition in this area can be detrimental to the overall health of the organisation. Encouraging collaboration, rather than competition, seems to be a beneficial approach that's worth exploring. Here are some key considerations and steps you can take to improve interaction and increase overall effectiveness:
Consider integrating existing platforms or just the services they provide. This requires careful analysis of each platform to identify different value propositions and how they could potentially fit together. Sometimes it may be better to split platform offerings into individual capabilities, such as compute and data storage.
Organise the platform into sub-teams. Depending on the expertise in your organisation, this could be site reliability engineering, CI/CD, database or network teams. This is to unify engineering under a single umbrella and solution to scale platform engineering efforts.
Migrate workloads to the more strategic platform. Your choice will depend on platform maturity, cost, security, etc. Make users aware of the differences, but also the points of friction. Support the decommissioning process of the old platform, ensuring that no dependencies remain.
Make consistent technology choices and create consistent operating models. Otherwise, engineering teams will do the same things in slightly different ways, which creates many problems with software licensing, security and engineering standards.
The challenge of having multiple platforms within a single organisation is therefore part of a wider discussion. I plan to write more about this in a future article.
Other factors that increase platform user adoption
Building trust through good reviews, case studies, and community engagement is essential to the successful adoption of any technology. Depending on the current landscape in your organisation, paying attention to these factors can help your platform gain widespread adoption.
Technology integrations are often the most time-consuming activities. Without the out-of-the-box support (where your platform provides the integrations on the go), every team will face this challenge for the first time, and collectively, those teams would have to solve the same issues multiple times. You save other people's time when you offer commonly used integrations by default.
Ease of adoption or, in other words, a lower mean time to "hello world". Organise a "lowering entry barriers initiative" in your project. It can be just one person who assesses the current state and proposes a solution to make using the platform a more seamless experience. It's good to bring an external person to the team for fixed-time consulting engagement – the fresh perspective can spark an interesting discussion and shift the direction.
Allow observability and autonomy for issue troubleshooting. Empower your end users to operate their workloads, control access within their team, and get enough insights about the platform's health without substantial help from the platform team.
Self-service. As suggested above, make sure day-one activities are automated and available through the API or web portal for users to self-serve most platform capabilities. Avoid a ticket-driven approach with a single person who may slow everything down.
Good quality guidance, examples and a community of users provide context for everyday decisions required by the user. This helps them navigate through the different stages of the adoption, understand interaction points and see the big picture.
High availability and disaster recovery are essential in building trust in adopting the platform. Typically, platforms belong in the Tier-0 systems category with strict availability requirements.
Having security and compliance managed centrally means that all applications hosted on it automatically comply on a non-functional level if you have an audited platform. This reduces effort from a security point of view and provides consistency in implementation.
Enabling teams with support and incident management is crucial. Responding promptly and jumping on a call when needed builds your reputation. Teams can only spare a small amount of engineering time collaborating with other teams when their focus is on delivering business value.
Furthermore, by fostering partnerships across teams and technology areas, we always increase our chances of success. You may already have special interest groups within your organisation. By working closely with them, you can become more integrated into the larger ecosystem of services and enhance the platform's service offerings. Another important consideration is to start hosting internally managed services, which are a key element of the company's toolchain.
Think of platform adoption as an ongoing journey - constantly evolving with different mindsets and a flexible strategy that adapts to the stage of the project, the pace of technological change and your organisation's goals. It's a deliberate process where the product management expertise of the platform team works with engineers to effectively onboard users and instil confidence in the quality of support.
Now that you've read this article, I hope you have a more complete view of the platform engineering landscape, its pitfalls and advantages. Everything in the above article is based on my own experience and from my individual point of view, which is why I want to ask you:
What's your perspective on platform engineering?
Do you have any interesting real-life stories to share?
What new dimensions did you discover while reading?
Feel free to write to me directly or leave a comment here. I will make sure all your comments and questions receive a thorough response.