Spreadsheets are familiar and give a quick sense of control with predictable license costs. For many people (mostly in the business department), they’re the perfect tool; they know how to use Excel and can make decisions quickly. The catch? That same spreadsheet also holds business logic that no one else in the company can verify. It’s rarely aligned with organisational standards, doesn’t come with metadata, and often, only one person has the “real” version with the best numbers (and nobody knows why). Welcome to spreadsheet-driven analytics.

Moreover, due to the rising importance of AI in multiple industries, the stuff we skipped over for years (governance, data quality, and technology platforms) suddenly matters a lot and is at the forefront of change. These areas need to be addressed in order to enable businesses to move forward with building more data-driven and automated decision-making capabilities. It’s a process that requires a careful balance between investment in the Data Foundation and the adoption of AI/ML. Shortcutting your foundation is no longer optional.

This article is based on several occasions where I had a chance to present the topic of data maturity, recently for leadership in the insurance industry and discuss intricacies internally with my colleagues at VirtusLab. This Notes on article will shed some light on how I structured the overall narrative. If you are interested in hearing the full story, feel free to reach out.

Guiding organisations through different stages of maturity is among my favourite problems

Due to the fact that I navigate in the software engineering services business, I mostly interact with companies who are in the “messy middle” technology transformation stage and want to get out of it. It’s rarely the case that things are nicely organised, the project is fully scoped, people know what to do, and all we need is to bring the team to implement the solution. These days, the sheer scale of technology, multiple vendors and evolving business aspects require something more than software/data engineering expertise alone.

Finding an optimal solution for organizations facing technology and organizational challenges due to the early data maturity reminds me of Richard Feynman’s approach of seeing the world through the lens of open-ended questions, which he called his “favorite problems”.

In the data world, my favorite problems today look as follows:

• How do we help organizations move from spreadsheets through data platforms to ML/AI-enabled insights?

• How do we fast-track AI today without skipping the hard work of data maturity?

Solving these isn’t about a big upfront investment but starting the change where the company culture is today.

Let me explain.

High-value use cases still come from classic AI

If we look holistically at the landscape of Machine Learning (ML) vs GenAI (Large Language Models), it’s useful to clarify terminology. From an academic perspective, Generative AI (GenAI) is technically a subset of ML. The GenAI sits as a small slice within the broader Machine Learning field. However, in practical, business-oriented discussions, the distinction is often more functional than technical.

For the purposes of this article, here’s the diffentiation:

• Classic ML/AI refers to data modeling, classification, regression, recommendation engines, and other approaches where models are trained from scratch using traditional pipelines on structured data.

• GenAI refers to the use of large, pre-trained foundation models (LLMs and other generators) that can be used out-of-the-box or lightly fine-tuned for specific tasks.

This distinction matters, especially when it comes to data requirements and value generation.

High-value use cases, such as prediction or automated decision-making, mainly make use of developing Machine Learning models.

Moreover, having access to quality, structured data is a prerequisite to performing data science and machine learning engineering with the exception of simple integrations with pre-trained models, including GenAI.

If we look holistically, classic AI (ML) and GenAI (LLM) they offer almost two distinct capabilities:

GenAI will not solve most of the domain-specific problems around risk evaluation or price prediction, but it’s useful for data prep, analysis and finding correlations within data to the extend that wasn’t possible before. But there is still a need for a conventional approach to data, from data gathering and data transformation to building underlying data platforms that enable further AI initiatives.

GenAI is easy. Data maturity is hard. In this regard, what will actually distinguish the company from the competition is whether the company is able to advance its data maturity. For example, to the level to start building ML/AI-driven solutions.

Analytics maturity, from basic reporting to decision-making

Analytics Maturity represents how well an organization uses data and insights to inform decision-making. “Analytics” in this context can mean “Statistics”, “Machine Learning”, and “AI”. Higher levels of analytics maturity will likely generate more value but with significantly increased development and operations costs. They will also require more high-quality data from various different sources, that is structured and accessible.

Analytics Maturity expresses the level of integration of analytics and ML solutions with business, explaining how deeply those concepts are ingrained with the business flow.

Three stages of data maturity

The missing link between data maturity and analytics maturity lies in the ability to operationalize data for decision-making and convert raw data into actionable insights.

Many organizations might have extensive data assets but still fail to translate them into meaningful analytics.

The simplified process breaks down into three stages:

1. Starting with data: The quality of your data and systems never stops you from running a new project.

2. Scaling with data: You can reproduce an outcome significantly easier than when starting from scratch.

3. Leading with data: By default, every new capability is Data & AI/ML enabled from the start.

Plotting where you are on the data maturity curve

There are several data maturity assessment frameworks, such as Atlan, IBM, Snowplow and many more, which provide a comprehensive overview of the multiple dimensions and how to measure them. If you are deeply invested in assesing your data maturity that’s probably the best way to go.

What I find useful is to start with the simple view first:

Answering these questions should give you a good indication of where you actually are on the data maturity curve. What happens next is a part of a bigger discussion exceeding the scope of this article.

Essential challenges in advancing data maturity

In my day-to-day work as Head of, I have constant exposure to all kinds of client’s challenges and opportunities which they create. My role is to reason through these problems and help other people succeed.

For example, this involves understanding their perspective, showing them where they currently stand, and helping them realise why their approach might be misaligned with today’s best practices or the current state of the art.

When it comes to the challenges related to data maturity, I’d say there are three common things that we see at VirtusLab. They usually emerge at each of the data maturity stages accordingly to the slide below:

• Data mindset (Starting with Data): When you start your data maturity journey, adopting a data mindset becomes the first issue. People usually don’t know how to navigate from upstream to downstream systems, where to find the data and who owns it.

• Scaling with coherence (Scaling with Data): As you grow, you need to start establishing some guidelines and reusable patterns/software in order to keep consistency. Some companies invest in centralized platforms to bring more standardization from the start, while others maintain a more distributed “you built, you run it” model, leveraging internal knowledge base and community.

• Integrating AI (Leading with Data): On the data and data-driven solutions are being implemented, the big challenge of integrating this vertically across the business typically emerges. There is a big question on how to implement a culture of rapid experimentation with new, constantly changing ML models vs standard release management approaches.

Further reading

If exploring a data maturity subject is interesting for you, it might be worth reading through the following books below.

Drop a comment. I’m curious to hear how others are navigating this. I’m also happy to present the full data foundation subject at a local meetup / internal workshop.

What is the value of an internal developer platform? It's hard to grasp something so theoretical, especially if this is your first attempt to define the value. Most of us can describe what a platform is, what problems it solves, and maybe even how we could build it. But let's face it, quantifying the monetary value of a platform to our business is a daunting task.

This article provides concise, digestible information to help you build an economic case for platform engineering in your organization. Once built, the case clarifies when the platform's value will be realized and how much time will be freed up for software developers to focus on higher-level problems and deliver greater value. Finally, it allows us, the platform builders, to articulate the value of our work.

Platform economics is a powerful, positive argument

Both product and engineering leaders take great care to justify and prioritize the money they spend. This process can raise doubts about the value or timeliness of platform engineering. Doubts that often prevent organizations from moving forward with platform engineering include:

• In our case, building a platform will take too much time and effort.

• It is too costly to build and operate such a platform.

• Our in-house engineering is not capable of building a platform. And finding the right engineering talent will be hard and expensive.

• It’s challenging to quantify the value of technical platform products. We struggle to sell this idea to our executives.

A clear demonstration of the economics of an internal developer platform is probably the most effective way to resolve common concerns in this area. 

To understand platform engineering's value beyond economics, I recommend reading my previous article: Unveiling success through platform engineering.

In a moment, we'll look at how to build a business case for a platform. But first, let's take a quick look at whether investing in a platform makes sense for your business (it doesn’t always).

When is investment in platform engineering justified?

The economics of building an internal developer platform are directly related to economies of scale. The larger the organization, the more it makes sense to build a platform. From this perspective, the benefit comes from increasing the capacity of a platform to handle more developers and more workloads.

It’s worth noting that the value of the investment is largely determined by the goals of the platform. These goals typically arise from intentions such as:

• Consolidating resources to optimize costs of ownership

• Improving level of standardization among the engineering teams

• Satisfying regulatory compliance requirements in a rapidly evolving market

• Improving developer productivity and satisfaction

• And so on.

Justifying an investment in platform engineering boils down to two things:

1. Increased leverage so you get better results while spending less money.

2. Creating a ripple effect so you improve the world around you.

In order to use either of these arguments effectively, and especially the first one, you need to provide the specific monetary information that makes the return on investment tangible. You should consider building IDP if the following equation is true:

In the next section, I'll break it down into a clear financial justification.

How to calculate the ROI of platform engineering

The image below is a screenshot of a return on investment calculation which demonstrates the financial benefits of adopting a platform strategy.

$3 741 360,00 Nett effect with 156,50% ROI for a platform onboarding ten teams a year for a lifetime of three years.

Under these assumptions, the simplified calculation shows a break-even point is achieved at 17 developers. This means hosting roughly three development teams on the platform is enough to justify the costs.

Inputs required to calculate ROI

Please note that these are averages that I've seen used in the industry and by our customers at VirtusLab. They may be far from your reality, which means you need to do your homework before they are right for you. Consider conducting an internal survey to get a better understanding of your version of the numbers here.

• Average developer rate: This represents how much a developer earns in your organization. The average developer rate in Europe is $45/hour, $1800/week, $7560/month (from CEE salary guide, Hays report, Talent.io report).

• Number of development teams to onboard per year: This represents how many teams will be onboarded to the platform. Depending on the size of the organization, this can range from a handful to hundreds of development teams. In general, the larger the number of teams using the platform, the greater the economies of scale.

• Average number of people on the development team: Based on personal experience, a team of six people is a sweet spot for a team with cross-functional expertise.

• Average platform engineer rate: for the sake of this calculation, let's assume platform engineers earn $45/hour, $1800/week, $7560/month (from CEE salary guide, Hays report, Talent.io report). In reality, these people earn slightly more than developers because their skills range from software engineering to cloud engineering, which are in high demand. However, reports are not accurate and you have to do your math here.

• Platform team size: It depends on the size of the investment. I have seen many examples of platform teams ranging from relatively small - around 3-5 people - to large teams of 20 people responsible for multiple areas of the business. Let's say a team of 6-10 people is sufficient to build the platform and support multiple development teams. For ease of calculation, roles such as engineering manager or product manager are included in this number.

• Average infrastructure overhead costs per development team: Costs typically include the infrastructure control plane, automation workflows, observability stack, security tools, and other essentials for operating the platform. These shared resources are best calculated by dividing the total overhead by the number of development teams using the platform. For example, in my last platform engineering project, the overhead was about $100 per month per development team. As the number of teams on the platform increases, the infrastructure overhead becomes a smaller part of the total operating costs.

• Costs of on-call: This amount depends on the incident management structure and the incentives for the 24/7 support team. The exact amount may vary due to extra pay for bank holidays. Let’s say the on-call rate is $1000/week (source Oncall Compensation for Software Engineers).

The value of internal developer platforms

In monetary terms, the benefits of internal developer platforms are described below.

1. Faster onboarding

From my observations, a typical average for onboarding is two weeks before the developer is able to be fully productive. It's rare that the onboarding process is completely streamlined, and as a result, there are usually multiple service tickets that need to be resolved by different people. The cognitive load and time required to search for resources and guidelines are also notable. The waste of resources during the onboarding process can be significant. An internal developer platform reduces this by an order of magnitude (one day is usually enough).

The average onboarding time is 2 weeks or 80 hours. 

At least half of it (40 hours) results in being completely blocked from doing actual work. 

Saving 40 hours per new developer equals $1800. 

Inefficient onboarding at a company with 30 new developers per year results in a loss of $54,000. An IDP that streamlines the process saves the same amount.

2. Increase developer efficiency

In large organizations, the overhead for getting things done is high. This sometimes makes developers feel like they have to fight to make things happen. This can include requesting access to new tools, creating an additional service account, revoking access when someone leaves the team, waiting while people are on vacation, or when tickets bounce between departments. All of these things can create bottlenecks. Streamlining and optimizing these bottlenecks is a primary goal for platform engineering teams.

Research by companies like Dynatrace indicates that only 40% of a typical engineer’s time is spent on productive tasks. Instead of using this dramatic number, let’s assume something more optimistic (based on my personal observations) for the sake of these calculations:

• Assuming a poor developer experience causes developers to waste 20 hours a month (average) that could be spent on productive tasks. This is 240 hours a year, which costs $10,800 per developer.

• Efficiency gained by 20% per developer with platform engineering equals 30 hours/month saved, resulting in $16,200/year savings per developer.

3. Shorter infrastructure spin up times

Building production-grade infrastructure involves a thousand little details. The vast majority of developers don’t know what those details are, so when you’re estimating a project, you usually forget about a number of these critical and time-consuming details. 

For a production-grade infrastructure based on the Kubernetes ecosystem in a public cloud, it’s at least two months of effort for two experienced engineers. It typically takes:

• Setting up cloud landing zones (access control, networking).

• Implementing infrastructure as code.

• Implementing CI/CD or GitOps workflows.

• Setting up observability.

• Testing performance, disaster recovery, scalability.

• Performing security and compliance audits.

In total, 168 hours/month x 2 months x 2 engineers = 672 hours of engineering time (one-off cost of $30,240 per team). An IDP giving developers fully up-and-running infrastructure transforms this into a saving of the same amount.

However, I have seen many examples of teams taking as long as six months before serving production traffic. This is especially true in less mature organizations without infrastructure blueprints or reference architectures.

4. Reduced infrastructure maintenance costs

It's increasingly common for teams to spend more time managing infrastructure than building new features. In our customer engagements, development teams reported spending between 10% and 40% of their total time managing infrastructure and tooling for their team.

Typical maintenance activities and associated costs:

• Ongoing cost optimization efforts (8 hours/month)

• Monitoring and troubleshooting the infrastructure, setting up alerting and observability dashboards (24 hours/month).

• Keeping up with upstream technology and component changes (32 hours/month). 

• Performing regular infrastructure release management (24 hours/month).

• Troubleshooting, addressing technical debt, refactoring (16 hours/month).

Total monthly cost: 104 hours/month, $4680/month per team, $56,160/year per team. That amount is saved using an IDP to streamline those processes.

5. Reduced integration costs

Integrations tend to be one of the most time-consuming activities, requiring coordination among multiple groups of people. Each team will face this challenge for the first time, and collectively these teams will have to solve the same issues multiple times, compounding the overall cost. Based on How much do integrations cost (and is it worth it)? A standard workflow's estimated cost is between $5,000 and $15,000. For custom integrations, the estimated cost ranges from $20,000 to $100,000+. On average, an IDP creates a one-time saving of $10,000 per team for each integration.

Less direct benefits of internal developer platforms

Here, we’ll have a sideline section for things where I won’t be able to calculate for you as it’s done on a case-by-case basis. However, these things are significant, often being a main driving factor for platform engineering on its own. Explaining this in-depth is beyond the scope of the article.

I think it’s fair to say that without a proper level of governance, people sometimes do crazy things such as storing sensitive data in plaintext or exposing unprotected access to internal systems. Or just when we leave it to individuals, they do something and simply forget. It creates a significant opportunity cost and should be somehow included in the economics of internal developer platforms. 

This section is exactly about that.

1. Improved security and compliance

When it comes to security and compliance, development teams typically must take care of:

• Addressing non-functional security requirements before going live in production. This includes hardening processes, implementing policies, performing security assessments, or engaging a vendor to conduct pentests.

• Measuring the potential risk of a data breach. Based on the Cost of a data breach 2023 | IBM report, the global average cost of a data breach in 2023 was $4.45 million, which shows an increase of 15% over a 3 year period. Each company should assess the potential impact for itself based on the nature of its business.

These are highly subjective numbers specific to your organization. In contrast to doing everything yourself, a centrally managed platform that has been audited and tested for InfoSec requirements means that all applications hosted on it are automatically compliant at a non-functional level. And you only do it once for all teams! 

2. Improved business continuity

Apart from the direct costs, service outages create trust and credibility problems. By improving infrastructure reliability companies can avoid the cost of downtime. Atlassian’s article examining the cost of downtime shares some spectacular reports, including a 14-hour outage in March 2019 that cost Facebook an estimated $90 million. The article also identifies a per minute downtime cost that is applicable to businesses outside of tech giants like Facebook:

A more recent report (from Ponemon Institute in 2016) raises Gartner’s average from $5,600 per minute to nearly $9,000 per minute.

This is a significant cost so it should be a feature in your platform engineering calculations. Speaking from my own experience in the retail sector, we were able to save about $120,000 per month with a new deployment platform simply because the infrastructure was stable.

3. Improved time to market

High-performing organizations that have adopted platform engineering practices can see a lead time for changes several times faster than those of low performers (days instead of weeks).

Without a developer platform, the teams would have to:

• Integrate and pre-configure deployment tooling

• Figure out a way to monitor and troubleshoot

• Satisfy infra-level security requirements out-of-the-box

• Establish support and incident management processes.

In contrast, teams working with a developer platform can significantly reduce the mean time to production because the platform enables developers to deploy and operate software in a secure, efficient, and reliable manner.

4. Reduced total cost of ownership

Having multiple teams designing, implementing and operating their infrastructure leads to higher costs of ownership. Each team has to run and configure systems themselves. In contrast, a centralized, well-architected environment brings direct cost benefits. 

According to insights from KPMG:

• Right-sizing instances typically reduce the total cost of ownership by up to 7 percent.

• Reducing environments and using auto-scaling can reduce TCO by up to 9 percent.

• Capitalizing on favorable pricing models and commitment discounts to improve average cost rates can reduce costs by up to 10-percent.

5. Accelerated migration

Platform engineering helps to lower the costs and impact of migrations. Instead of loosely coordinated, unstructured migration efforts, we have a consistent and transparent approach.

The development teams spend weeks or months migrating in case of vendor change or cloud migrations.

Business case summary

If you’ve been working along through to this point, you should now be ready to put the findings of your ROI calculation into a business case summary, along these lines.

Time to value

This represents the time requirements to build your platform which is capable of onboarding development teams. Establishing additional processes around operational excellence should be also included. 

ROI (return per year)

This represents the return on investment in platform engineering.

Net effect per year

This represents the money equivalent after deducting all costs related to building and operating the platform.

How much efficiency gain do you need from the start? 

Getting to the next level of efficiency is a long-term game. It always takes time. It's like adding another "nine" to your uptime SLA. I'd advise you to think for yourself and not buy into the idea of another platform MVP in a few weeks. The time to "hello world" is always fast and impressive, but getting something production-ready involves a thousand little details. On the other hand, it doesn't take much effort to see the positive impact of platform engineering early on, even when the platform is not fully finished.

Let’s have a look at two examples of platform engineering efforts that bring value early:

• Exploring the problem space in your company. Especially building a better understanding of how developers work, what technologies they use and what patterns emerged among different teams. All these insights are valuable input to your leadership discussion. If you don't know where to start, you can either work with external vendors that offer low-cost, fixed-time platform discovery assessments (for example the company I work for) or consider assessing this by using off-the-shelf products such as DX: Developer Experience Insights Platform which I can personally recommend.

• Starting team enablement activities. It’s like running a platform team without the platform product yet. Where platform engineers act more like enablers, helping a single development team pave the way to production while providing valuable feedback for future platform development efforts.

In case you face financial constraints, it’s worth looking into the potential cost savers in this space:

• Narrow down the platform scope to a single capability. This could be self-service provisioning of company-compliant and well-integrated Kubernetes clusters. Eventually, expand the team and platform boundary to areas which need attention.

• Offer limited SLA which simplifies the architectural requirements and doesn’t require a fully-fledged operations team yet. Instead of providing a highly available architecture, it might be something suitable for struggling teams or low-tier apps serving traffic during business hours as a starting point.

• Build gradually on top of Managed IT services or existing infrastructure blueprints in your organization.

Apart from all these positive calculations, it’s worth asking yourself: are there any additional risks of building an internal developer platform that can impact the overall cost? What about measuring the cost of cooperation between various teams, stakeholders and the central platform team?

That’s it for now

Money is a universal language that everyone understands. Now you can use the calculations you've developed to advocate the value of platform engineering within your organization.

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 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. I’m open to writing collabs.

Read previous articles:

1. Platform Engineering Primer

2. Unveiling success through platform engineering

3. On platform adoption: essential mindsets and approaches

4. The nature of work in platform engineering

5. Internal developer portals: a springboard to platform engineering success?

6. Navigating platform engineering: the big picture 

In our day-to-day work, we may interact with people who don't have platform engineering expertise. Or you or I may find ourselves in a situation where we are about to join a platform engineering initiative without a sufficient understanding of the subject. How do we navigate this space so that we do not slow down the engineering team or even unconsciously sabotage their efforts? 

I remember several times when it was almost impossible to conclude a discussion because the people leading the project needed a deeper understanding of the specific domain. We wasted a lot of time talking about basic concepts that everyone could have been briefed on earlier, yet this wasn't made part of the plan. People tended to rely on their initial viewpoints rather than considering broader perspectives. This often resulted in frustration, inefficient use of time, and eventually a lack of trust. A more structured approach could have been used to bring about a collaborative and trusting environment.

As in any field, it takes time to develop the right judgement to contribute in a meaningful way. Platform engineering is a relatively new concept, so we often need to educate people about it. I strongly believe that platform engineering success is directly related to how close key people in the organisation are to core work at the beginning of the platform engineering journey. While getting these people on board, upgrading your own orientation within the platform engineering landscape can help immensely.

Let’s admit when it comes to building an internal platform for developers, there are many approaches and none of my articles can fully convey what it is really gonna take in your context. However, I do see value in giving you a mental model to use while implementing an internal developer platform. This is something I find essential and use when educating others around me.

If you are an engineering manager, architect or team leader, my work is intended to help you in this educational endeavour. Times when this article will be useful include:

• Get everyone in your organisation on the same page

• Improve your clarity so you can get others on board

• Gain an understanding that allows you to make a meaningful contribution to the initiative

Finally, if you are still exploring whether or not platform engineering is a good fit for your organisation, have a look at my earlier article, Unveiling success through platform engineering, which explores this topic.

Let's start by familiarising ourselves with some basic concepts.

Key concepts around platform engineering

Building a clear mental model around platform engineering is an essential first step which brings confidence and enables people to contribute. Every platform will have a different set of priorities, architecture considerations, and unique people behind it. Personally, I start by understanding basic concepts and then gradually zoom in on specific areas that are closely related to the work itself.

What is platform engineering?

Understanding platform engineering is highly contextual, depending on perspective: adopting a platform as a product, using platform engineering services or a development within the company. As organisations perceive it in slightly different ways from each other, here is the interpretation I use in my daily work as Head of Cloud Engineering at VirtusLab.

Platform engineering involves designing and building toolchains and workflows that enable self-service capabilities for teams of software developers. The aim is to deliver an integrated product, commonly known as an 'internal developer platform', that provides the operational requirements for applications throughout their lifecycle.

Often building on cloud capabilities, platform engineering initiatives are there to support organisations throughout the lifecycle of their platform. The platform engineering team takes a holistic approach to ensure that the product is aligned with the business strategy and objectives. They also make sure they fully understand the organisation's operating model, the technology landscape, and the people who deliver the software the business depends on.

Building an engineering team to design the platform and deliver the capabilities can take several forms, depending on your priorities: improved developer experience and productivity, efficiency in building data-intensive applications, faster time to market, cost optimization, security, or all of the above.

The typical objectives of a platform engineering initiative are:

• Centralise infrastructure and drive adoption of standard architectures

• Facilitate full compliance in a dynamic security and regulatory environment

• Reduce time to production by eliminating developer friction points

• Control costs, encourage code reuse, and replace multiple 'do-it-yourself' solutions

Let's acknowledge the fact that each interpretation has its virtues and limitations. Please note this is the perspective of a software engineering services company. It will be slightly different from the perspective of product vendors and end-user organisations.

Internal developer platform architecture

From a 10k foot view, most of the internal developer platforms will consist of similar areas. The diagram below shows just that.

To effectively navigate platform engineering, it’s best to understand these concepts as your starting point:

1. Platform boundary: This is a fundamental aspect of platform engineering that determines how far the platform extends: what’s in scope and what’s out of scope. Boundaries are typically formed around external systems and domains, such as compute, storage, deployment tooling, observability or security tooling. This is also a good indication of the problem space and how much the platform engineering team needs to take on their shoulders in terms of maintenance. The platform boundary is sacred and should be protected to avoid scope creep. It’s worth asking yourself: What’s the approach to defining platform boundaries? Is it based on the team's skills or organisational topology? What’s the level of alignment / overlap with the rest of the organisation?

2. The operating model explains how developers work in the organisation. In platform engineering, it’s usually presented in a self-service fashion using web portals, direct API calls, or developer tooling. It’s important to understand how many deployment and lifecycle activities are handled as part of the platform, and what the application team is responsible for (this is called the “shared responsibility model”). It also speaks to the level of autonomy vs control. A good understanding of these will help determine the best market fit for the platform in the organisation. Ask yourself a simple question - what’s the path to production? How do teams deploy and operate their software? How much support do they need from managed service teams or platforms?

3. Platform capabilities: In other words: what are the key capabilities of the platform? This could be compute, databases, or deployment as a service. What is the value proposition of the platform?

4. Engineering principles and guardrails: How does the platform engineering team approach the solution architecture? How do they keep the quality bar high? Familiarising yourself with these aspects provides a better understanding of existing architectural tradeoffs and how technical decisions are made. 

5. Platform technology landscape: What are the key technologies used in the platform; what are its building blocks and components? How do they interact with each other? Are they open-source or proprietary? How many of them are reused internally vs just operated as part of the platform only?

6. Level of abstraction: the level of abstraction is the degree of complexity at which a system is viewed or programmed. The higher the level, the less detail or control. The lower the level, the more detail and control. These are related to the engineering maturity of the organisation. Typically, the more experienced the engineers, the more control they need. Is the solution an Infrastructure as a Service, Platform as a Service or Deployment as a Service? How much control does it provide in terms of service management aspects, custom configuration, and observability?

7. Team enablement: Is the platform engineering team actively involved in helping application teams overcome obstacles and speed up migration efforts, or is there an external team doing this work? Can the platform engineering team focus on building and maintaining the platform, or does it also act as an enablement team?

8. Operations and Site Reliability Engineering: Complex initiatives require a wide range of skills and processes. Is the current team capable of addressing existing issues? Is this approach sustainable over time? What’s needed to achieve operational excellence in the platform team? Platform engineering mostly requires a software engineering mindset, and experience shows that it is good to introduce SRE capabilities early in a project and scale them out when the platform gets closer to general availability.

Finally, it is important to understand where platform engineering sits in the organisation topology. It may sit under infrastructure, application development, or even a dedicated developer experience business domain.

Implementation process

In an earlier article, I already explained how platforms come to life and mature over time. This is a good place to start. However, when it comes to the actual implementation process we need to break it down into the most important things that happen at each stage. This section provides ways to think about them.

Step 1. Understanding fundamentals

At this stage you need to explore existing technology and processes so you know how to adapt and what can be potentially reused. Conduct interviews with a few development teams to better understand their operating model and the challenges they face on a daily basis.

Introducing platform engineering has organisational implications. You need to communicate platform engineering initiatives company-wide early on. It helps to check for potential competition or overlapping initiatives. This helps avoid the friction in the future. Based on this knowledge, define boundaries and key areas of the platform. Take into consideration the size of and how capable your platform engineering team is. Use this knowledge to define the platform boundaries and key areas. Often the fewer the better.

You should now have a good level of understanding of your organisation’s needs and can make technology choices based on the existing technology landscape and engineering principles. Carefully consider whether it makes sense to introduce new technologies, as in many cases introducing a new practice is costly and requires additional training and procurement. Not every organisation is a high performer; sometimes it’s better to set realistic expectations and use well-understood, established technologies. 

The next step is to define the right abstractions that fit your organisation’s current operating model. Decide which one fits your needs: Infrastructure as a Service, Platform as a Service or Deployment as a Service. Each has unique benefits and tradeoffs. In addition, you should look at this phase holistically and assess how it fits into the private vs. public cloud vs. edge landscape if your organisation has that scale.

Now you are ready to start designing the solution architecture by first defining key design considerations. Architectural guardrails help the team make platform engineering decisions.

Step 2. Design the platform’s concept model

At this stage, it’s better to focus on a single area because it shortens the lead time to build it and deliver the platform POC. You can’t build a platform that satisfies everyone, aim for 80% of use cases, the remaining 20% are edge cases that are probably too costly to address. Do not jeopardise the platform based on the opinions of a vocal minority.

Run a series of spikes to see if the initial assumptions make sense. You may want to adapt the Request for Comments (RFC) approach, which is useful for gathering feedback in a more scalable and asynchronous way.

As a result, you should have at least a basic solution design in the key platform areas, as it may be increasingly difficult to undo some decisions later. Some example areas might be access control, onboarding, networking, security, scaling or multi-tenancy.

Write everything down in the form of a design document. You’ll be presenting and returning to it many times in the future. Ensure overall architectural alignment with enterprise architects, if applicable. Discuss this with decision makers, and various development teams, and finally get the executive buy-in for the early implementation work.

Step 3. Build and validate the platform prototype

First, you need to agree on the outcome, scope and timeline. It’s important to set and manage expectations upfront. It’s almost certain that you will face external dependencies and need to manage the risk.

Finding an early adopter team is also crucial. The ideal team should be: 

• The right size so that you are motivated to look after them during this phase, preferably as part of a customer journey. 

• Able to participate in an early adoption programme.

Invite them to participate in a customer journey, ask them for feedback often, and listen to their pain points.

Deliver the first prototype, preferably within six months. You want to validate assumptions and fail fast. Pivot is less expensive at this stage.

Start advocating for the platform at an early stage to build the adoption funnel. Planning for migration (e.g.,  from already existing platforms) always takes more time than you expect. It also helps identify additional requirements and potential blockers.

Step 4. Mature the platform for general availability

Putting the platform into production and achieving operational excellence always depends on your unique organisational goals and what you want to achieve with platform engineering.

At this stage you may want to consider:

• Optimising costs and whether it makes sense to implement some form of cross-charging model to hold teams accountable.

• Establishing a release management process and achieving a higher level of automation in general are important at this stage. From now on, it cannot be done on a case-by-case basis, it has to be reliable.

• Achieve operational excellence. Depending on the circumstances this could be building a Site Reliability Engineering capability, improving lifecycle management processes or introducing 24/7 support.

Assuming all of the above, the platform engineering team structure at this stage may not be appropriate for this phase and may require additional staffing.

What your platform team needs to move forward

Empowering your platform engineering team is the best leverage you can get. This creates a ripple effect throughout your organisation.

Platform engineering is about delivering value to developers, and the best people to understand their needs are platform engineers. They operate at the same level of context. Nothing will replace human-to-human relationships, so as a leader you need to create favourable circumstances for your platform engineering team to have the time and space to build those relationships. If the work is process-heavy, if people need approval at every stage, or they spend too much time in non-engineering meetings, they won’t have the space to look beyond the current scope. The bounded engagement model, where platform engineers work directly paired with developers on some fixed-time, fixed-scope work is the most efficient approach.

In my experience, empowering the platform engineering team includes:

• Having an enabler/disruptor/innovator role in leadership that supports moving the needle, managing friction, and driving change outside of the platform domain.  Historically, people who keep their head down are not the best fit for this type of role.

• Enabling the team to contribute directly to the roadmap.

• Let the team process, prioritise and propose implementation of feature requests alongside the product management (take ownership).

• Get the team actively involved in support activities, migration and onboarding so that they are constantly exploring the problem space.

• Give the team the final say on when to move to the next stage of platform maturity.

• Help them advocate for the platform in the organisation so they have a chance to prove its value. Focusing on both top-down and bottom-up approaches has the greatest impact.

These things may sound obvious to most of you. And that’s fine if you already understand them. But for those platform engineering efforts that are not yet aligned with innovation programs, they will have to emerge in other ways until they are more widely recognized. Understanding and adapting to how people in your organisation think about platform engineering is an essential first step.

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

Read previous articles:

1. Platform Engineering Primer

2. Unveiling success through platform engineering

3. On platform adoption: essential mindsets and approaches

4. The nature of work in platform engineering

5. Internal developer portals: a springboard to platform engineering success?

It's even harder for the many companies that have evolved from a body-leasing model with no significant technical expertise or intellectual property of their own. They simply don't have the leverage to differentiate themselves in the marketplace, and at the same time, the strategy of employing engineers loosely attached to the parent company makes their workforce a tasty morsel for talent hunters. The truth is that such service companies have never had to sell their services and develop efficient sales processes, as referrals and the general prosperity of the market have been enough to keep them growing for many years. At the end of the day, many customers are left with nothing more than price as the basis on which to choose a service provider. No easy situation when competing with developing countries with more competitive price differences.

Let's put aside our concerns for a moment and see what new opportunities are available to us today. 

Cloud engineering becomes more cross-functional

Aside from advances in AI, the cloud technology landscape has stabilised. Cloud providers continue to monetise on managed platforms and seek to consolidate on public and private clouds. The majority of developers are now familiar with cloud engineering concepts such as containers or infrastructure as code. Setting up another automation pipeline or spinning up infrastructure for the application is not something that requires a dedicated cloud engineering team unless these things are done at scale or aligned with some enterprise-wide innovation programmes. There are still a number of cloud engineers who support other developers in their day-to-day work. But these core skills, once rare and expensive, are now found in every team and department in a typical engineering organisation. That's good, because it gives us more room to deepen our skills in other areas of cloud engineering. So how do we create an edge and stay relevant in the market?

I have several observations here:

• An increasingly cross-functional role. With established cloud engineering expertise now more widely distributed, the focus is shifting to cultivating a productive DevOps mindset, rather than creating another functional silo to deliver infrastructure services to software teams. Meanwhile, there's a tendency to overlook other non-functional aspects such as automation, reliability, performance, observability, cost optimization and security. And cloud engineering is well-placed to fill this gap.

• Increased demand for software engineering skills. People who know how to code are better able to think about complex distributed systems, while also being able to build the underlying tools and automation for developers. There is still a place for people with traditional ops backgrounds, but they will need to re-focus somewhat towards Site Reliability Engineering (SRE).

• Platform engineering as the unifying factor. Emerging on top of DevOps, platform engineering is beginning to be recognised as a solution for enterprise-wide initiatives between infrastructure, developer experience and data engineering. It requires a good track record in the software development lifecycle (SDLC). This is reminiscent of the move from systems administration to DevOps, which required many to upgrade their skills to keep up to date.

• Cloud engineering gravitates towards data. In the past, cloud transformation was often the starting point for literally any commercial discussion with an engineering service provider. Now, the majority of these early conversations are about data engineering. Whether it's data analytics platforms, data-intensive applications or AI infrastructure, there's a significant overlap between cloud and data. It's often a challenge for cloud engineers to navigate the data landscape. But the reverse is also true. Bridging the gap between cloud and data is a smart strategic move.

• Cloud engineering roles become more customer-facing. Today's problems are not trivial to solve and often have organisation-wide issues, which brings consulting skills into the spotlight. This requires decent communication and writing skills that most developers do not typically have.

Overall, this means that cloud engineering is more domain-specific. Engineers in this area will need to recalibrate depending on the circumstances.

Service companies need to find their focus

For many years, software engineering services companies increased headcount as their margins grew. This approach is no longer sustainable. To increase company value, you need to specialise more. Delivering more distinctive value to customers and building clearer differentiators in the marketplace will become top priorities. Software engineering services companies will do this or slowly go bust.

Shifting to higher-value cooperation models is difficult because it requires different sales approaches, consulting skills and technical or industry-specific expertise. But it definitely delivers a better margin. Competing to be the best at everything no longer pays off. Which leads to the next point.

Engineering excellence: Can companies see through the buzzword fog?

The emperor has no clothes when it comes to some digital transformation claims. However, software engineering services companies are often reluctant to point this out. That's understandable, because it's not in their interest to do so. The bigger the initiatives they sell, the better.

I hear a lot of stories about clients being ripped off by another big consultancy (I won't name names here to avoid unnecessary resentment). They pull the senior people off the project after a couple of months or simply don't deliver on the promise of quality work. It's a fact.

In today's world, customers increasingly expect software engineering service providers to adopt a time-bound enablement model. This means that the customer wants to own the intellectual property (IP) and be self-sufficient once the project is complete. Customers are realising that relying solely on external providers can be risky and are prioritising solutions that they can sustain in the long term. Software engineering services companies need to adapt to this changing landscape by offering enablement-focused services that empower customers to manage their own technology in the future.

Overall, I believe these changes will make a positive impact. Specialised consultancies will guide the client’s organisation on a path of building modern engineering capability. While solving interesting engineering and organisational problems.

Would you agree?

Let's face it, expecting developers to be experts in everything is unrealistic. That's why many engineering leaders envision a single, easy-to-use platform where everything works smoothly. It may sound like a tall order, but it's all about abstracting complex things so that developers can focus on creating quality software. From where I stand, it makes a lot of sense. I hope you'll join me as we chart a course towards the ultimate goal of platform engineering: a central hub for monitoring and managing the entire software development lifecycle.

These days, we are seeing a huge surge of interest in the adoption of internal developer portals (IDP) as a solution to improve the developer experience, scale existing knowledge and facilitate leadership in organisations. One of the most common pilot projects today is the introduction of an internal developer portal.

However, many organisations find it difficult to align the different dimensions, create the right contract between the platform and the portal, and then use that contract to create a successful portal. The resulting chaos and wasted effort are often enormous. In contrast, a portal, if done well, acts as a gateway through which your platform is embraced by the majority of its intended users.

As I mentioned in my first article, my goal has always been to broaden my horizons in the area of platform engineering and to glean wisdom from some of the brilliant minds in the industry. This article was inspired by a conversation I had with Zohar Einy, the CEO of Port, who's as close to the subject of this article as you can get.

As the person behind Port, the internal developer portals (IDP) product, he shared its most frequent use cases. He also discussed what companies want to achieve and the common pitfalls. Reading between the lines, you can discover all of this, along with my perspective.

"Everyone has a different and individual way of working, so we shouldn't provide a one-size-fits-all experience. Instead, we provide a toolset that allows you to create the experience that works for you and your organisation." Zohar Einy, CEO of Port

In this article, we’ll explore:

• The potential value of adopting an internal developer portal in your organisation.

• How companies approached building developer portals before the current IDP era.

• The way internal developer portals (IDP) work from an architectural point of view.

• What comes first, the platform or the portal?

• Reduce workload by integrating your portal efforts and ongoing platform development.

• The pitfalls to avoid when building or adopting IDP products.

What drives organisations to invest in developer portals?

We, the shapers of engineering effort in digitally intensive organisations, are now well educated. We know how important it is to make developers' jobs easier and how that can impact business results (Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations). The aim is to streamline tasks through code reuse, adherence to technical standards and the adoption of design guidelines. That's all well and good, but you know what? Developers still sometimes struggle to put it all together. This means that our ultimate goal may still be missed. Every decision on how developers dedicate their time in a non-functional world comes with trade-offs.

How can we help our people succeed? We can focus on engineering enablement as a strategy and scale our existing knowledge. Crucially, we also need to bring senior leadership closer to the work happening on the ground, so that they're aware of the challenges and friction points, and the opportunities to empower developers.

An internal developer portal is one of the keys to engineering enablement in organisations. It helps us make the shift from top-down to developer-centric. Whenever we need to connect the dots, a developer portal acts as the 'connective tissue'. It allows us to facilitate many processes, including:

• Compliance and governance. All businesses want development teams to adhere to organisational standards. An example: coordinate code freezes from a single point.

• Streamline feature deployment and service scaffolding. Of course, consistency means something different in each organisation. Portals give you the flexibility to create an experience that works for your organisation.

• Simplify cloud and infrastructure as code. Teams often struggle in this area. Internal developer portals facilitate the inner source approach to eliminate duplication and encourage collaboration.

• Improve incident management and on-call processes. When microservices impact each other, it's a challenge to triage incidents on time and escalate them to the right team. Having clarity about how systems interact and who owns what is essential.

• Manage permissions to external or internal systems which usually end up as tickets. Portals allow you to manage in a more self-service way. Provide an approval flow or manage just-in-time access as needed.

• Support other self-service capabilities, integration with existing CI/CD systems, triggering of custom actions or management of feature toggles.

• Additional visibility into various aspects such as service catalogue, API versioning, team topologies or costs. An internal developer portal allows organisations to create scorecards or track productivity metrics such as DORA.

• Centralised documentation so that developers don't have to search for information from multiple, unfamiliar sources.

This is by no means an exhaustive list. The number of processes routinely offered as self-service via internal developer portals will grow as the organisation and its developers grow.

What we used before the IDP era

The field has developed rapidly in recent years. Let's take a look back to see how far we've come. 

Before the IDP era, organisations built custom web portals to abstract common operations such as onboarding, access management or provisioning new cloud accounts. Typically, each technology department created its version of the portal. And it was all built primarily to control rather than enable developers. I'm pretty sure you've seen something similar in your organisation. In most cases, the user experience wasn't great, it was slow and at the end of the day, it was just an abstraction of all the spaghetti of disparate systems and manual work underneath.

On top of that, we often heard that developers didn't want another "clicky thing", and that they preferred code-based interfaces. So it was hard to find the balance and make everyone happy. Fortunately, modern IDP solutions offer both intuitive GUIs and code-based interfaces such as SDKs, direct API access or CLI tools that don't derail efforts to improve automation across the board.

Put simply, the primary shortcomings of this legacy way of doing things were:

• Lack of an API-first mindset when building these portals. It became increasingly difficult to streamline multiple processes together due to different API formats or the lack of an API format altogether.

• Infrastructure engineers are not typically front-end experts. The result was often poorly designed web portals with non-intuitive interfaces.

• Limited extensibility. Adding features and integrations was difficult and time-consuming. The high level of coupling and technical constraints significantly increased lead times and hindered overall progress.

• Duplication of effort with multiple teams typically building their portals in slightly different ways.

Let's take a look at how this legacy way of doing things fits into a maturity model:

I see the move to powerful IDP solutions such as Backstage or Port as a logical evolution in response to the increasing complexity, integration requirements and efficiency demands of today's software development. 

They aggregate information but often fail to integrate workflows or reduce developer friction. Developers still face the challenge of context-switching between an IDP and its underlying tools, which slows their workflow. That’s why we need to build a solid contract between internal developer portals and platforms which is outlined later in this article.

Do you think it draws a complete picture of how things have evolved? Have I overlooked something important?

How they work: developer portal architecture

Internal developer portals typically support a wide range of capabilities that you tailor to your operating model, tech stack, common practices and team topologies. Looking at this from a high-level perspective, the most notable areas are:

The core of the design is always around self-service. This is the central point where other internal or external capabilities interact. Depending on the use case it might be accessible via a simple web interface, direct API call or command line interface tooling. This mechanism is also responsible for the integration with your internal platform which I cover in the next section.

Besides that, IDP solutions typically provide:

• Software catalog - a central place to store relevant information about software inventory, team structure or API schema and versioning. 

• Blueprints - which serve as a starting point for scaffolding an application of a piece of infrastructure. 

• Approval flows - provide a consistent and transparent way of keeping track and approving access to various cloud resources or external systems within the organisation.

• Custom plugins - enable portal users to extend existing capabilities by implementing their integrations or workflows. It might be a low/no-code approach or a dedicated programming framework to use.

• Insights - sometimes called scorecards provide real-time data about the current state of the services, their compliance status or other types of metrics. 

To give you a more tangible example of how internal developer portals are built, let’s have a look at Port's high-level architecture. It’s a typical Software as a Service (SaaS) architecture with additional components which can be deployed in the customer environment. The product leverages AWS-managed services, as software is written using common programming languages such as JavaScript (Typescript and React), Python and Go.

1. AWS DocumentDB is used for storing the configuration of integrations such as a user's Ocean integrations and his dynamic webhook configurations.

2. AWS RDS is used primarily for RBAC information, the configured roles, and their permissions.

3. AWS Managed Streaming for Kafka is used to provide dedicated Kafka topics to users, which they can use to listen for changes in integration configurations and receive notifications about new self-service action requests.

4. All integrations written using the Ocean open-source integration framework are written in Python, some integrations such as Port's K8s exporter are written in Go, and the rest of the stack is written with NodeJS, Typescript and React.

5. The connectivity between SaaS and customer environments uses Rest API with JWT auth.

6. Port has an open-source integration framework called Ocean, all new integrations that Port publishes are open-source and use the Ocean framework as their core, you can learn more about Ocean here.

As you can see, building a portal is not a trivial task, it involves several components for data storage, streaming and even the need to create a custom framework to let users extend existing portal capabilities.

Platform or portal first?

Think of internal developer portals and platforms as two separate systems, each with its own life and different teams working on it. Deciding which one to implement first has significant implications for your platform strategy.

By introducing an internal developer portal first, you simply decide to start building the abstraction. You set the stage for self-service and automation. It gives you a lot of flexibility to model interactions and limits future problems associated with modifying some of the underlying solutions when they need an update to stay fit for purpose.

But it doesn't clean up the mess underneath. If you have some flaky managed services or processes that are mainly ticket-driven, the portal won't solve those problems.

In comparison, the introduction of a new platform is likely to require developers to adapt to a new operating model and migrate their services to take full advantage of the platform. However, developer portals offer the flexibility for developers to select only the processes they want to access in a self-service manner.

Let’s take a look at a simple comparison of what each approach provides.

What's my opinion? In most cases, building and operating a stable, scalable and efficient platform infrastructure is a key starting point. This unlocks the basic capabilities that can later be exposed in a self-service manner via an internal developer portal. Starting with the platform creates an interesting opportunity to partner with developers and observe how they actually do their work. So we can understand friction points, eliminate them and bring more standardisation across the stack, and then build a portal on top of that knowledge. Otherwise, with portal first, we’d have to experiment with self-service interfaces, revert what didn’t work out and constantly change how developers work until it stabilises. And at the end of the day, this is a more costly approach. Moreover, it is important to have a clear vision so that the two initiatives eventually converge. In some rare cases, if the teams share a vision and have a collaborative nature, it is possible to develop both in parallel.

There are many circumstances in which you probably don't need a portal right away. This is a nuanced question, so I decided to put it to other people who are also closely involved in platform engineering.

 Here is a selection of the views expressed in the conversation thread shown above:

• “Platform first for sure. You want to add value to teams first before you have to add a portal experience on top”

• “You can have a platform without a portal. A portal without a platform makes no sense.”

• “Always the correct answer: “it depends”. But from my point of view, if the platform is a product, I would include the portal as part of the MVP (2-3 services addressing common problems + portal + implementation layer).”

• “Platform first, get the MVP and buy-in and then use that experience to build the portal.”

Integrating your platform with developer portals 

Looked at holistically, all efforts to build platforms or portals aim to solve developers' problems. Portals create a gateway to platforms and platforms provide a solid foundation for portals. This combination brings value.

When integrating the two, consider the following aspects:

1. Level of coupling. This refers to how the portal and platform work together and the degree of interdependence between them. A reasonable level of coupling improves maintainability and enables the portal and platform to scale company-wide. It also allows them to be developed and tested in isolation.

2. Level of ownership. This minimises potential confusion over who owns the various services, automation and interfaces. A clear level of ownership is shown below. 

3. Level of abstraction. Identifies the desired operating model for developers. For more mature organisations it’s better to stay with open standards in technology, while less mature or less engineering-focused benefit more from a high level of abstraction.

Now let's look at common portal-platform integration patterns from a more technical perspective.

• Declarative configuration in git is probably the most common pattern used in custom-built IDP solutions and is relatively easy to implement. It’s also often integrated with a command line interface (CLI) tooling which supports additional validation and automation techniques. For developers to prefer code integrations instead of web interfaces this is the best approach.

  

• Agent-based is commonly used in more advanced IDP solutions and especially as part of SaaS products that provide access to real-time data, as well as a number of existing integrations with 3rd systems.

  

• Direct API integration is a traditional way of integrating systems. It’s flexible but requires additional development efforts.

All of these three integration patterns can be used interchangeably depending on the use case.  

Some common pitfalls

Having seen quite a few successful and less successful attempts at building internal portals for developers, here are some common pitfalls I’d like to share with you.

• Approaching internal developer portals in a vertical way. This often leads to building multiple portals which provide a limited set of capabilities, are inconsistent and make it difficult to automate processes end-to-end. The full promise of IDP is to have a single pane of glass for your service catalogue, costs, resource management, blueprints and more.

• Providing just a static view instead of automatically collecting the live data across software and resource catalog. You should be also able to perform actions from there like: spawn new microservices and create new environments. Otherwise, it makes no difference than another Confluence site which requires a lot of admin work to keep up to date.

• Not having a buy-in from developers. Where often the development of IDP is driven top-down without input from the developer community. It might lead to a mismatch of use cases and actual needs.

• Lack of shared contribution leads to capped innovation and growth. It’s not solely an infrastructure project. 

• Not investing in the right design which is user-friendly. In other words, building an internal portal by the infrastructure folks alone is not gonna work out. You need someone with design skills.

• Abandonware portal which is not actively developed once the initial set of features has been delivered. This especially applies to custom-made portals which don’t have a dedicated team to maintain it.

There are many views on when and how to introduce an internal developer portal to an organisation. Let's draw upon my conversation with Zohar once more, to better understand his perspective:

“Connecting and bringing live data, which is reconciled with the source of truth, is crucial for the portal. Without it, you end up with just another, maybe prettier, documentation site.”  Zohar Einy, CEO of Port.

We also touched on some of the challenges they face with their IDP product. One of them is meeting customer demand, prioritising which features to build into a portal is a real challenge. Especially when it comes to integrations, where they have a dedicated integrations team to deliver value quickly. When you build a portal in-house, developers ask for more, and that is when it starts to break.

Let's leave it there for now

The title of this article suggests that portals propel progress towards platform engineering goals, much like a springboard propels a diver into the air. But now we can see that there's more to portal implementation than a simple starting point or driver for platform engineering success.

As organisations begin to realise the value of internal developer portals, the synergy between the portal as a gateway and the platform becomes critical. However, for organisations that have both platform engineering and internal developer portal initiatives, the result is often two separate products with a common goal and potentially overlapping functionality that must make trade-offs to co-exist.

It is important to recognise that internal developer portals are becoming a part of the platform engineering discipline. These two efforts need to be properly aligned and mutually supportive to improve the chances of achieving greater developer autonomy and productivity.

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

Read previous articles:

1. Platform Engineering Primer

2. Unveiling success through platform engineering

3. On platform adoption: essential mindsets and approaches

4. The nature of work in platform engineering

Although I started my career in traditional business application development, I quickly discovered my passion for distributed systems, security and the complexities of the non-functional side. I enjoyed looking under the hood to connect and automate as much as possible. Even with a new project, breaking down business processes into programming logic became monotonous and needed more excitement. All in all, this was the catalyst for my move into cloud engineering.

As my career shifted direction, a few things struck me that I had not seen before.

• The cloud-native technology landscape was still in its infancy, most of the technology we were using at the time wasn't stable and production-ready. At the same time, there was a huge appetite across the software development industry to adopt new cloud-native technologies and stay ahead of the curve. Unfortunately, there weren't reference models for how to use these technologies, information on best practice and, most importantly, clear ways to enable solutions at scale (today we call them golden paths). This created an exciting opportunity to pave the way for others facing the same uncertainties.

• As a result of the rapid evolution of the cloud-native landscape, people working in the software development industry experienced increasing cognitive load. This created a challenge for developer efficiency that is still being addressed today.

• In infrastructure, a software engineering mindset had begun to take hold. This shift was a response to the increasing complexity of most emerging technologies, which were based on distributed systems principles. This shift also meant that I could leverage my previous programming experience for example to build Kubernetes operators and CLI tools, or achieve higher levels of automation using various SDKs.

As I worked through these challenges, I realised that it wasn't just about the technical stuff, but also about understanding the human side. Solving these combined puzzles made my work more satisfying and opened doors to impacting the organisation as a whole.

So, naturally, my journey shifted from cloud engineering to platform engineering. Today, everything I've mentioned above is the bread and butter for most platform engineering teams.

In this article, we’ll look at the distinctive aspects of platform engineering and the unique nature of the work in this space. We’ll also explore how having the right people in place can have a significant impact across the business. Finally, we’ll also briefly touch on key considerations when hiring and, in the long term, scaling the platform engineering team. 

Overall, it will give you a better perspective on how people working in platform engineering think, what they value and how to interact with them effectively.

How platform engineering differs from traditional application development

Before we get into the intricacies of the nature of the work and my observations, let's lay the groundwork for how platform engineering differs from typical application development.

The distinction between platform engineering and application development is both subtle and significant. Application developers focus primarily on front-end and back-end components, working closely with business processes. Platform engineering operates behind the scenes. Unlike customer-facing roles, these positions are internal, and dedicated to streamlining the software development lifecycle processes within the organisation. They primarily interact with developers.

Platform engineering is about solving problems at scale. This means that systems often need to be even more scalable and reliable compared to the scope of a single application. The bigger the organisation, the more challenging the work. For example, it might involve enabling new technology, considering how it will be used in the context of your organisation, writing documentation, defining patterns and building self-service processes around it. So that at the end of the day, the approach is well understood, standardised and easy to automate. It also fits use cases for the majority of users in the organisation.

Here is the list of key areas of focus in platform engineering:

• Infrastructure automation and development tools: Ensures that infrastructure spin-up is fully automated using the Infrastructure as Code approach. This often includes developing custom tools (using programming languages) to abstract common operations in a simple, user-friendly way.

• Infrastructure baselining: Provides golden paths to production by stuff like deployment patterns, environment promotion, code generation, and other types of reusable blueprints.

• Infrastructure lifecycle management: Keeps the infrastructure up to date, well integrated and accessible to end users so they don't have to worry about it.

• Scalability and reliability: Takes responsibility for providing end users with a fully functional environment that is stable and scales as the user base grows or during traffic spikes.

• Security and compliance: Often concerned with standardisation efforts and ensuring that potential attack vectors are eliminated across the technology stack.

• Monitoring and continuous improvement: Continuously monitoring the health of systems, implementing automation in this area and actively looking for ways to do things better.

• Support and incident management: Establishing a formal process to help end users with their day-to-day issues and resolve production incidents in a timely manner. Often acting outside of typical working hours.

I’d say, platform engineering tends to attract individuals who want to make a bigger organisational impact. It applies to both individual contributors and decision makers who inspire change through the organisation. They always have a collaborative nature and are efficiency-focused.

It takes me back to the initial days when we were expanding our platform team. Alongside my colleagues, we came up with the following candidate profile. And you know what? Not much has changed since those days! I continue to refer to it whenever I recruit someone for the platform engineering team.

The ability to tackle new challenges that come with a lot of uncertainties, quickly adapting and learning, while also taking initiative, remains essential in platform engineering.

Typically, platform engineers…

Solve other people’s problems

As part of the platform engineering team, your ultimate goal is to build an internal solution for application teams that enables their day-to-day work. This ranges from day-one activities such as managing access, infrastructure configuration, setting up tools or providing out-of-the-box technology integrations. But it goes much further, to helping them deploy and operate production services in a safe and reliable way.

You have to look holistically, both taking into account the user's perspective and the organisation’s realities with what is possible and what is not. At the same time, actively communicating limitations, explaining do’s and don'ts and facilitating the flow of work. Moreover, it takes a specific type of skill to understand where exactly the cognitive load is and how to optimise it.

Engineers in this space need to be passionate about solving other people's problems, often supporting developers with a vast difference in level of experience ranging from someone who barely understands the tech landscape to seasoned experts who expect full customisation and control. They act as a bridge between technology and its users, ensuring that solutions are not only effective but also user-friendly.

Automate themselves out of a job

That’s the only way to handle the complexity and scale. People scale linearly, while the right automation scales exponentially. It’s essential to build an automation-first mindset in the platform team from day one.

People building platforms need to strive to automate themselves out of their job in order to scale out. Engineers in this area are supposed to streamline inefficient processes, so other people can experience less friction. Traditional system administration roles or old-fashioned operations are not capable of doing this work. It requires software engineering skills in DevOps.

Are ready to take the blame

Depending on the existing integrations and level of coupling with other systems, while building and operating the platform it’s inevitable to aggregate failures. It’s often the case that you put your reputation at risk because someone else messed something up in a different place which you only abstracted. Now you are accountable to fix it and make it the right way going forward. Platform engineers are not stepping away from the bottom of the problem. 

In the context of incidents, accidental downtime or other production issues, we often talk about the importance of blameless culture in the organisation, but the reality is that we’ll always have stressful conversations. You need to be okay with this kind of situation. The blast radius in platform engineering is always bigger than in the application scope alone.

Always keep the lights on

Platform engineering involves running large-scale infrastructure in production, supporting it 365/24/7. Often resolving issues outside of your comfort zone while managing communication under the pressure of people who are impacted.

People in this space need to embrace the responsibility for the entire lifecycle of the infrastructure. This often involves being on call to address unexpected issues, which means being prepared to dive into problem-solving at any hour, not just during conventional working hours. People who favour a stable 9-to-5 schedule may find that platform engineering is not the ideal choice for them.

Their work is often invisible when everything runs smoothly, however, it becomes critical when the unexpected happens.

Community is essential in platform engineering

Platform engineering is a cultural change, and to be successful, it always needs a developer community as its foundation. Developers create value by using and building on the platform. You are scaling the platform organically by creating a dedicated space for engineers to collaborate, share knowledge, and help each other. Being actively involved in building the community is an integral part of the platform engineering team’s role.

Platform engineers play a role in building a community by hosting product demos and show-and-tell sessions and advocating platform use. They focus on engineering partnerships and one-to-one relationships to extend existing offerings or ensure interoperability with other systems. In larger organisations, they work with enterprise architects to ensure consistency in technology and architecture decisions. This helps to promote the platform and increase its use.

Building a developer community is a one-way door decision, it's hard and it takes time to initiate. However, if done right, it can empower the entire organisation. For more detail on this topic, I highly recommend listening to this podcast by Amir Shevat and Mikeal Rogers:

Measuring & Managing Community Orgs, Developer Relations and Beyond | Andreessen Horowitz 

Platforms change constantly

While the lifecycle of the platform extends beyond typical applications, it is constantly evolving and requires adaptation. Changes are driven by organisational and user needs, and intensify as more teams adopt the platform.

"The platform is not trying to anticipate everything. It's trying to enable people to build better solutions." - Platform Strategy: Innovation Through Harmonization - by Gregor Hohpe

Imagine you are building a cloud platform, whether on Azure, GCP or AWS. You need to constantly keep up with upstream changes in API version, access control, security and more. You may find that the functionality you've already put a lot of effort into is provided out of the box by the cloud providers themselves. Don't be afraid of this, it's good! It means you are on the right track, you just need to adapt.

Part of a platform engineering team's role is to guide the organisation through the ever-changing technology landscape. The team continuously monitors new and changing technologies and the benefits they may provide. Evaluating and testing these technologies turns this awareness into guidance and actionable knowledge. I plan to write more on this subject in a future article.

As adoption of the platform increases, so do the needs that the platform has to meet. There may be things that were overlooked in the initial design, or scalability may have become an issue. However, you must be prepared to absorb a lot of new information on unfamiliar topics.

Why multidisciplinary expertise is vital

From a technical perspective, platform engineering requires multidisciplinary expertise to navigate between different platform domains and emerging processes, covering various aspects from basic understanding of the field to specific tasks.

Platform engineers are typically involved in every stage of platform development ranging from problem discovery, prioritisation, solution design, implementation, technical documentation and support. To give you a more concrete example, in addition to the standard implementation-related work, they need to be able to do the following:

• Understand non-functional requirements such as reliability, disaster recovery, scalability, security and user experience.

• Work in a product-led engineering fashion and actively participate in product discovery, customer engagement, prioritisation and value measurement.

• Write clear and concise user-facing documentation, including architectural concepts, how-tos and troubleshooting guides.

Platform engineers pave the way to production for other developers, connecting the dots and making sure other people don't reinvent the wheel. Given what's expected, this is not a junior role because you can easily get disoriented without solid fundamentals. Do you agree?

Rather than a fictional unicorn, platform engineers are more like real-life octopuses. They are highly intelligent in the way they coordinate a number of actions that take place in parallel.

The nature of leadership in platform engineering

Depending on the organisational context, a person leading a platform engineering effort may have the title of Engineering Director, Head of Technology, Engineering Manager or Product Manager. Whatever the title, this is a very demanding role, requiring a lot of stakeholder management, diplomacy, internal sales and general bridging. It requires holistic thinking, strong systems design skills and hands-on operational experience. In other words, they need to be the CEO of this initiative, always looking ahead and thinking big.

I always look for someone with skin in the game. Somebody who can play politics at the right level to get the organisation to actually build something that solves the developers' problems. On the other hand, people who spend all their time in the paper land without actively engaging with the platform engineers are not ideal for this role.

In my personal approach, platform engineering is about building the structure and the bridge to efficiency according to existing corporate standards. But it is also about breaking the rules. Sometimes you have to ignore standards and think independently. Many people struggle with this and prefer to play nice to avoid confrontation.

“When you know the rules, you’re allowed to break the rules.” Breaking the Rules – @ASmartBear

I have seen a lot of vague standards in my career. It's frustrating when you really want to make things better, but the current way of doing things is sub-optimal and no one is willing to look at it. Platform teams need leaders who empower and encourage them to challenge the status quo.

Scaling a platform engineering team

Sooner or later you will face the bottleneck of scaling your platform engineering team. The need to scale depends on several factors, including:

• Consider the size and number of development teams that your platform supports.

• Define what you are trying to enable your internal customers to do and assess your level of involvement in supporting them.

• Clearly identify the boundaries of the platform and the desired level of integration with external systems.

• Evaluate the current team workload, including the level of context switching between engineering, non-engineering and support activities.

• Assess the time available for innovation and experimentation beyond the standard roadmap.

You don't want your platform team to scale linearly with the organisation or the number of developers it supports. In fact, I would say that considering a new platform team member shouldn't be a default choice. It always changes the dynamics of the team and may not be the optimal solution at the time. Fundamentally, track adoption and other metrics such as Net Promoter Score (NPS) or developer productivity SPACE to guide the growth of your platform team.

Typical symptoms of team scaling issues include:

• Too much work in progress, which is not really caused by poor project management, but by the amount of ad-hoc work, end-of-life activities or simply end-user support. Before you consider adding more people to the team, try to put more emphasis on a healthy balance and a reasonable level of pushback. In other words, consider a sustainable pace first.

• There is limited collaboration between team members as they struggle to understand the full scope of the problem. You start to see less active participation in meetings because people simply can't digest everything on their plate, so they keep quiet. This could be an indication of knowledge gaps in the team, so a greater focus on knowledge sharing and documentation could be a solution for the time being.

• The growth of the platform creates gaps in skills and responsibilities. Maintaining a sufficient level of multidisciplinary expertise across all areas of the platform will become too difficult. You'll need to start thinking about becoming more specialised in one area, such as release management or observability. Understand the preferences of the team members and then decide if you have the blind spot, ad hoc expert involvement may also be an option.

• Extending the platform boundary or supporting additional integrations requires more responsibility from the platform team. This includes both maintenance and support overheads. This is where you should push back by default, unless you have very specific reasons to expand.

If the problem space becomes too large for the platform team to handle, it's a good idea to consider extracting a piece of the platform into a separate module and then delegating the responsibility to another, more suitable team in the organisation. A good example might be considering adding support for data stores when it's not strongly represented in the team's current skill set, and it's better to delegate that responsibility to others while still maintaining it as a key platform capability.

In most cases, organisations start small with just one platform team. However, in large organisations, a platform may eventually require multiple teams to build and operate it. Based on my observations, there are two common ways to scale the platform team.

Organise by subdomains

This method is based on splitting the existing team into smaller sub-teams that focus on a particular area of the platform, while increasing the number of people. For example, a common use case for subdivision is as follows:

• Site reliability engineering: Essentially responsible for lifecycle management of the platform, continuous improvement, scaling and performance monitoring.

• Support: Answering other people's questions, helping with enablement and onboarding.

• Implementation: Building the platform and automating processes. This can be broken down into specific technology areas such as networking, security, observability, compute, storage and more.

• Consulting: Working across the product and platform teams and working with the company’s technology strategist. This role helps to inform platform strategy, build roadmaps and understand the business-specific problem space.

• Migration: Supporting development teams in migration or merging other platforms.

There is, however, one important caveat:

“Generally speaking, teams composed only of people with single functional expertise should be avoided if we want to deliver software rapidly and safely.” Team Topologies by Matthew Skelton, Manuel Pais.

Organise by value streams

Based on my conversations with some people in the industry, they don't necessarily agree that scaling the platform team through smaller, more autonomous sub-teams is the right thing to do. Sooner or later it creates coordination overhead, knowledge gaps and becomes too hard to maintain. 

Instead, they suggest aligning the team around the entire value stream. So they take ownership of the specific outcome from start to finish. 

The way it works is that they form a fixed-time squad focused on enabling a specific product or team, frequently reconfiguring and evolving in their own space. The value stream in this case relates to services and products within the scope of the platform. It's based on a layered approach where one team provides the base platform and the second team focuses on supporting the service on top of the platform.

Which approach is better? Well, asking that is a bit like choosing between a road trip and a scenic train ride. Both have their charms. Let me leave this as an open question as it depends on the scale, scope of the work or structure of the team topologies. In my humble opinion, organising by sub-domain is more popular and typically happens organically. On the other hand, the value stream approach requires some careful planning and a different way of budgeting.

Let's leave it there for now

We've explored the unique aspects of platform engineering and how having the right people on board can have a significant impact on your business. We've talked about traits to look for in platform engineers and ideas for scaling your team. Anything I missed?

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.

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:

1. Solving developer problems, those that are possible to solve at scale.

2. Getting buy-in and strategic alignment.

3. Starting internal marketing early.

4. Finding the right time for the change to happen.

5. Establishing a community to scale up.

6. 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:

1. Continually exploring the problem space by researching and understanding user challenges.

2. Building relationships with people inside and outside the organisation.

3. 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:

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

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

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

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

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

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

3. 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:

1. Consolidate multiple platforms.

2. Deprecate less strategic platforms.

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

Since this is the beginning of our journey, I feel the need to say a little bit about myself and what motivates me to write. After all, some of you may be sticking around for the whole series, so it's only fair that I introduce myself, right?

I've spent seven years immersed in the world of platform engineering. From embracing new technologies and building teams to refining workflows and streamlining tech stacks, it's been quite a ride. I've had my fair share of tough moments and sub-optimal decisions that have almost left me and my clients sinking in technological quicksand! But the thing is, we've always managed to stay afloat. These experiences have given me a rather unique perspective. They have sharpened my critical thinking and strategic skills and enabled me to see many of the pitfalls and opportunities that lie ahead.

Working with brilliant minds across various sectors has broadened my perspective. I am unwilling to keep the knowledge I've acquired to myself. My objective has always been to utilise technological advancements to enhance our lives instead of getting in the way of it. Platform engineering offers a unique opportunity to do just that, which is why I write these articles and eagerly await your feedback.

One final note: I'm all about keeping it simple. I write in plain, everyday language because I want this to be a smooth ride for everyone. My goal is to make sure that even if you're not knee-deep in technical stuff, you can still dive into this series and come out with something useful.

So, with that out of the way, let’s begin.

Where are we and what got us here?

It’s as good a place to start as any ;)

Well, it's safe to say that DevOps is pretty much the standard these days. Most of us in the industry have jumped on the bandwagon.

DevOps came about as a response to the growing burden on engineering teams. It's been the method of choice lately, with the whole "you build it, you run it" concept becoming the norm. The only catch is that it hasn't scaled as seamlessly as we'd hoped. Unfortunately, it requires specialised skills that are difficult and expensive to find. The bigger the organisation, the more teams duplicate time and effort by doing the same thing in different ways. In response to this problem, organisations are increasingly focusing on engineering enablement as a way to increase developer productivity. They're providing the right tools, streamlining processes, and diving into automation and self-service offerings. And guess what? Internal developer platforms are coming into play to make the whole cloud journey smoother, especially at scale. It's about giving developers the freedom to deploy and manage software without breaking a sweat.

Developer platforms streamline existing processes and reduce time to production. They help organisations address the challenges of infrastructure complexity, which has continued to grow under the DevOps approach.

You may disagree, and that’s OK ;) 

If you have a different opinion, or feel that I have missed something important, please leave a note in the comments. It's my aim to answer every question people leave there.

So what?

What if you look at it from a different angle? You might think of platform engineering as a niche hobby that only engineers and techies really understand. But what about the real business impact? And how can those of us with technical backgrounds make these potentially valuable results crystal clear to everyone in our organisations?

Well, fear not! There is a section in the middle of this article containing the answers to these questions and more…

• What is the cost of not having a developer platform in place?

• In what ways do developer platforms benefit organisations that implement them?

• What are the potential pitfalls?

• How do we communicate all of this clearly?

If you want to jump to that section, scroll down to “Is platform engineering worth the investment?”

Otherwise, let’s continue by looking at the state of platform engineering today.

Platform engineering: the current stage of evolution

It was a great moment in my career: We implemented a centralised platform to reduce lead time to production from around six months to less than two weeks. In other words, we reduced project ramp-up time by an order of magnitude - 10 times.

This approach has huge implications for development teams, who have traditionally struggled in this area due to a lack of time or expertise to deal with the burden of a modern cloud infrastructure.

The split between time spent on infrastructure and applications will vary depending on team structure and organisational expertise. It's always been a trade-off, as it's increasingly common for teams to spend more time managing infrastructure than developing new features. Organisations that adopt a platform engineering approach can dramatically free up delivery teams to focus on their core business, while leaving the configuration and management of the infrastructure in the reliable hands of dedicated experts. This is illustrated in the diagram below.

As you can see, with a platform engineering approach, the infrastructure-related work is becoming more predictable and there is much less variance of unexpected activities.

When it comes to the actual data, platform engineering has been classified as an innovation trigger in the Gartner Software Engineering Hype Cycle. The chart below shows a 2-5-year horizon for platform engineering to emerge and be fully accepted by the mainstream market. Beyond the fevered lens of hype, platform engineering is starting to be taken seriously for its direct benefits and enabling qualities. This shows that organisations are aware of the need to improve developer efficiency and address the increasing cognitive load of engineering.

Building a centralised platform is also a viable option as part of a company's digitalisation journey. Modernising existing IT systems and adopting a new engineering mindset on a large scale is difficult. That's why you need some level of consolidation and a central place to facilitate change. For me, platform engineering has always been an impetus to change culture and processes first, and technology second. When we talk about digital transformation, this may be a more tangible implementation to consider.

Platform engineering emerges

Let's take a look at two problem statements that express the concerns that eventually led to the emergence of platform engineering. These should be familiar to you if you're in a digitally intensive business.

The statements come from a top 10 global grocery and general merchandise retailer that processes thousands of transactions per second, supports the delivery of more than 1 billion items per year, has nearly 200 development teams, and an annual European turnover in excess of £50 billion.

"It takes about two months of initial effort to set up your own infrastructure. In addition, it takes around two weeks of effort per month from an experienced DevOps engineer to maintain the infrastructure."

"Development teams reported up to three weeks to complete day one activities such as onboarding, setting up access and CI/CD before they even start coding."

These concerns, echoed by many organisations, have led to wider adoption of cloud-native technologies and modern development practices, improving time to market. The idea of building internal developer platforms came from the same desire for change.

How are internal platforms for developers actually built?

When it comes to building internal platforms for developers, let's look at two scenarios that companies often find themselves in.

Platform engineering: an evolutionary approach

In 2016, three colleagues and I embarked on a new client engagement. Our main goal was to implement a new retail fraud detection service. Shortly after the start of the engagement, we noticed that the developers in this area were struggling with the stability of the cloud infrastructure, resulting in frequent accidental downtime. Each week, the Technical Programme Manager (TPM) would present a spreadsheet detailing the revenue loss associated with service interruptions. Thousands of pounds were being lost each time. 

We assessed the current situation and, rather than build yet another application, we began to build a shared infrastructure for the five teams in this area. The cloud-native technology landscape was gaining traction. It was the perfect time for a bit of innovation. We launched the first instalment of self-hosted Kubernetes on AWS, creating a shared environment that supported full infrastructure automation, data storage, secure access and monitoring. After this had been in production for a year, the engineering director responsible for the company's global infrastructure took notice. He had previously struggled to comply with regulations and manage the costs associated with the public cloud. To address these challenges, we created our first platform engineering group. Over the next year, we scaled our solution to support hundreds of developers.

I'd say this is the most common scenario for how companies build platforms. It starts small: a few engineers build a solution that multiple teams adopt. Over time, they come up with the idea of sharing it with the rest of the company. This is a perfect example of how real innovation can come from a handful of people working under some form of constraint. A key consequence of this approach that we've seen is that it's hard to scale your existing platform to a larger number of teams because it was never designed to do so, both in terms of architecture and support.

Platform engineering: a top down approach

The second scenario is more top-down: when a company's leadership recognises that it is facing challenges with its current operating model and decides to make way for the new platform. The problems they see are typically

• Inefficient infrastructure lifecycle management, leading to unintended downtime or teams struggling to keep up with upstream changes.

• Long lead times to production, where the infrastructure takes longer to spin up than expected. Lots of manual hand-offs or time-consuming technology integrations to deal with.

• There are always compliance and security gaps that need to be addressed. However, organisations find it difficult to implement changes quickly. It takes time to coordinate changes and fine-tune standards.

• High infrastructure operating costs are often a top priority. Engineering teams make suboptimal architecture or technology choices just to stay under the radar.

From what I've seen, most companies facing these challenges don't have the technical capability to build an internal platform. Naturally, they start looking at off-the-shelf products, most of which are not a good fit for the specific way their organisation works. This is particularly true in terms of existing processes, integrations, ways of working or the level of customisation required. In fact, most companies, especially larger ones, are still building their own internal platforms. 

The way I see it, the issue of building vs buying platforms is part of a larger discussion that will be covered in a separate article.

The transition from DevOps to platform engineering

Taking a holistic view of how organisations can move from a DevOps approach to platform engineering, the steps could be as follows.

1. Question expectations. Invent something new without insisting that it meets outdated or ineffective standards. Do it within a team or smaller group, as doing it on a large scale straight away is tough. Sometimes, shadow projects become the new normal. You never change things by fighting the existing reality. Instead, build a new model that makes the old one obsolete.

2. Introduce automation by standardising the technology stack so it can scale later. Do it in a single team and focus on fixing bugs. Once things are stable, you can extend it to other teams in the same area and across the organisation.

3. Distribute automation, provide code and usage guidance, and support developers as contributors. Build a community of developers around your solution to scale it exponentially. Many companies engage their engineers in collaborative work using the inner source approach.

4. When you are confident in the current design, create reference architectures and have them tested by multiple teams. Provide a baseline implementation for other teams who are not domain experts. To make it work for your organisation, we think about the overall structure and design. We also take into account any known trade-offs.

5. To help developers improve their release management and host workloads, we offer a managed platform. It's secure and reliable, built on top of the existing solution. Create a dedicated team of experts to run the platform and support other engineers.

6. Popularise best practices by sharing documentation, samples and success stories. If you have enough money, consider making a special team to help other teams use the platform and solve problems. This team does not need to maintain a separate backlog, as it can embed itself in other groups as a service. Read more on this in Team Topologies by Manuel Pais and Matthew Skelton.

Is platform engineering worth the investment?

Let's briefly look at the benefits and returns you can expect from investing in a platform engineering approach.

Decades ago, a few bigger technology companies identified the critical factors: 

• Infrastructure standardisation

• Self-service developer UIs

• The right level of abstraction

• A dedicated team to manage everything as a platform.

This approach enables developers to build, deploy and operate applications more efficiently and with higher quality.

And here's the bottom line: Companies that nurture their developers perform five times better. The main reason is that it's increasingly common for teams to spend more time managing infrastructure than building new features. Take a look at the chart below, which clearly shows this performance gap.

By adopting a platform engineering approach, organisations are successfully bridging the gap between infrastructure and development teams, resulting in increased collaboration and productivity. Employees have a sense of a broader developer community, which boosts their agency. It also helps to retain key talent.

Ensure the platform engineering initiative has a sound footing

There are two fundamental questions that need to be answered before committing to a platform engineering initiative. 

First, consider whether platform engineering is the right approach for your organisation based on the challenges you face:

• The size and complexity of your business. Would economies of scale benefit your organisation? Would centralising resources create efficiencies?

• Operational excellence. Are service outages, undetected errors or problem resolution times an issue in your organisation?

• Goals and direction. What do you want to achieve? Standardised infrastructure? Improved security? Reduce time to production? Optimise cloud spend?

• Current operating model. Are there differences in the way teams within your organisation approach software quality, security or deployment? Do your teams face bottlenecks or slowdowns due to a lack of standardised tools or processes?

Let's face it. In some cases, the do-it-yourself approach is better, costs less and gives your developers the freedom of choice that really works for them. Putting people through another migration is not cheap either. I've seen many examples of platform development being treated as a pet project and failing because the platform wasn't built for clear reasons. As a result, the platform team needed more direction and platform adoption was disappointing. In contrast, I have seen heavy and opinionated platforms that limited rather than empowered users. In addition, scaling the platform and supporting this growth in usage by increasing the number of operational team members, many of whom lacked a software engineering mindset, meant that the initiative was not successful in the long term.

Second, make sure you hire people who have the ability to execute the vision of the initiative. If you're considering building a platform, it's highly likely that your organisational routines and existing processes will inadvertently cause it to fail. Don't give up! Building a platform at scale requires people with multidisciplinary skills and a very different mindset to doing it on a smaller scale. These people need to be passionate about solving other people's problems, customer focused and not afraid to take responsibility for running a large number of services in production under some form of SLA. Not to mention streamlining existing processes and tackling drudgery and friction. Identify the go-to people in your organisation. You know who they are, everyone wants their time.

Platform engineering is an organisational effort that requires significant up-front investment. It must be approached strategically to realise its value. It typically takes up to a year to start seeing tangible results. To deliver the results, you need to have a consistent set of guiding principles for the platform, as well as executive buy-in. This is where a mission, vision and roadmap come into play.

Now that you've identified a solid opportunity for your company, you'll probably want to talk to your colleagues to get them on board, and help them understand what's at stake. The next section will help you prepare for this.

Communicating your platform’s mission and goals

A mission statement helps to guide our day-to-day decisions and actions. From making architectural changes and shaping the product roadmap to designing end-user interactions.

When it comes to platform engineering, I think it’s fair to say that most platforms will share a basic mission statement similar to this:

We aim to make it easier and quicker for developers by offering a complete and standardised environment that's also secure, compliant and cost-effective.

The commonality of this mission doesn't mean it's not valuable. Each platform must meet the objectives of cost, reliability, security, technology and developer efficiency in slightly different ways. Managing the platform requires a delicate balance between the needs of the developers and the realities of the organisation.

There are many factors that go into balancing these goals. Let's examine the relationship between these goals in the context of creating a mission statement for your platform.

Keeping costs under control is the most important thing in most cases. Especially today, as we all face an economic downturn, where literally all companies have started to look at cost optimisation. Some of them are trying to control public cloud costs, while others are thinking about cloud repatriation and moving workloads back to on-premises. In both cases, a well-designed platform can reduce costs through resource utilisation, limiting software licences, reducing accidental downtime, or creating shared services that can be used by multiple applications or teams. It is important to identify what the key cost drivers are in your organisation and to include them in your mission statement or goals.

Ultimately, we all want to run production services in a secure and reliable environment that meets SLA requirements. However, it's often the case that developers don't keep the infrastructure up to date. Lifecycle management is a complex process and can lead to downtime. As a result, Meantime to Recovery (MTTR) becomes less predictable. All of these issues lead to production incidents. Having a dedicated team of experts to keep the lights on definitely helps to mitigate the risk.

Most developers are not security experts. Home-grown infrastructure (network, access rights, workloads) is not continuously tested for info-sec requirements. With platform engineering, every workload can be compliant at a non-functional level from day one. With platform engineering, it's much easier to introduce new policies and compliance requirements without disrupting the user experience, and it doesn't require as much effort as a do-it-yourself approach.

Technological advancement has always played a significant role in building a competitive advantage in the marketplace. It's fair to say that platform engineering facilitates the adoption of new techniques, helps keep pace with emerging technologies and brings new team topology patterns. However, organisations need to be prepared for such drastic changes. Often, new practices can be introduced without considering the time and effort required by people to integrate them into existing processes and working habits. That's why defining the enablement plan is one of the key success factors of platform engineering. This involves a lot of work to raise awareness of the value of platform engineering, to train people and to show them how to navigate a new landscape.

When it comes to efficiency, bridging the gap between infrastructure and application space is becoming top priority. To give you a more tangible perspective, the platform provides necessary interfaces and processes for developers to self-serve themselves and work in a consistent way. At the end of the day reducing cognitive load in engineering.

By now you probably have a mission statement in mind that fits your business pretty well. Before we go any further, let's look at two examples from my own experience to keep the inspiration flowing.

"Our mission is to converge disparate infrastructure solutions to improve our technology efficiency, economies of scale, technology portability and security.

To do this, we're creating an opinionated, standardised, enterprise-integrated architecture and sharing it using internal open source software. We are also hosting this infrastructure for teams and providing infrastructure operations support for teams that have traditionally struggled in this area."

"Building a deployment platform for production and non-production environments that spans multiple cloud providers and data centres, freeing engineering from day zero and day one activities to deliver solutions for customers and developers, and making it a joy to use."

How do internal developer platforms mature over time?

Based on my own journey in platform development, it's pretty clear how platforms come to life, grow and eventually find their footing. From my perspective, the patterns of platform evolution tend to follow a familiar path. Building platforms often means encountering the same iterations over and over again.

Initial discovery

People are starting to realise that the problem exists and needs to be addressed. The do-it-yourself approach is no longer scalable or cost-effective. Organisations begin to explore the problem space, either on their own or by engaging external consultants.

This phase involves discovery and interviews with teams and their managers. The result is a synthesis of the existing tech stack, identification of bottlenecks and friction points in day-to-day operations, and recommendations on how to address them.

Mission and vision

This is the time when product and engineering work together to build a strong case for why senior management should invest in the platform engineering idea. This usually results in full executive buy-in or enough funding to build the prototype.

Mission and vision are treated as guiding principles during the platform development process. Having clarity on this helps to push back unnecessary work and avoid the situation where the platform is "all things to all people".

Concept model

Now comes the execution. The platform engineering team starts with the initial architecture design, technology choices and documentation of the concept model, which can be validated with technical leadership. This results in a prototype with a limited set of capabilities to demonstrate value and trigger thinking about actual deployment. Typically, if successful, this is enough to release funding for the next project milestone.

Early adoption

From an engineering perspective, this phase focuses on overcoming scaling issues, implementing key capabilities and achieving higher maturity in terms of processes and non-functional aspects such as disaster recovery, incident management, security or documentation. Most of the gaps and friction points are addressed during this time by working closely with the application teams.

From a leadership perspective, this is the time to start assessing the value of the platform, typically based on the number of teams or applications on board. The financial viability of running a platform engineering team is also often explored.

General availability

At this stage, everything becomes more seamless, especially in the areas of onboarding, external integrations and lifecycle management. The platform can be consumed in a self-service fashion without a lot of manual intervention. In addition, in most cases, the platform is becoming a strategic direction for new teams to offload infrastructure management. This is the peak time in terms of user base. It's worth noting that it takes a lot of effort to get to this point, and some platform development efforts will simply never reach this status, either because of sub-optimal design or company policy.

Contained

Eventually, the nature of the platform engineering work becomes more operational. The platform engineering team keeps the lights on, and does no substantial product work. Sooner or later, the platform is seen as old, part of a routine or less strategic. There are several reasons why platforms become contained. The most common are: 

• Leadership decides to build something new to keep up with the ever-changing technology landscape

• Mismatch with current strategy 

• The platform is too costly to operate or adoption is declining.

Decommissioning

Once the platform is contained, the natural next step is to plan for decommissioning. This phase is mainly focused on migrating the platform and untangling dependencies. This always takes longer than originally planned. The nature of the work involves coordinating and discussing migration timelines. In some cases, supporting technology integration activities. Finally, everything is removed and the platform no longer exists.

Building an internal platform for developers is a rollercoaster!

Platform development is a very different beast from your typical application development project. It can be quite a bumpy ride, dealing with existing bottlenecks and resistance. Trying to automate these clunky, manual processes to deliver a smooth user experience is a real test, not least because people in the organisation tend to raise their shields when they encounter the unfamiliar.

Your success will depend on others, and you'll work hard to create the visibility needed to drive adoption of your platform, often failing to convince some very opinionated people. You will gain trust by helping other engineers through difficult situations. This will often take you out of your comfort zone. It is about understanding a problem space beyond the boundaries of the platform itself, which may include technologies in use, integrations, processes, custom code, and so on.

Defining the boundaries of the platform and diplomatically pushing back on incompatible ideas will be inevitable and difficult, so there will always be a risk of scope creep.

Now, let's look at some of the pitfalls you and your colleagues are likely to encounter and should be aware of.

Platform engineering pitfalls

While it's easy to come up with success stories that are truly dazzling, let's not overlook the importance of critical thinking in delivering a healthy new platform. The following pitfalls can act as useful reminders of critical thinking’s value.

Platform engineering is not about optimising problems that should not exist in the first place. Inefficient processes or broken services need fixing at the source of the problem. For example, you can't fix underlying DNS resolution issues by shifting them to the platform engineering team. Doing this leads to suboptimal platform design, poor developer experience and wasted engineering potential.

Choosing the right time to build a platform is an important decision. Suppose the technology stack isn't standardised enough, or the current operating model hasn't been fully assessed. In this case, it's too early to build a platform. If most teams have already modernised their infrastructure or recently completed migration efforts, then it's too late. In either case, there's a risk that a newly built platform won't solve the right problems or will be too expensive to deploy.

Multiple platform engineering initiatives often lead to internal competition and politics. People tend to protect their castles. It's an unhealthy situation to have two platforms competing for the same user base. To address this, create a robust workload allocation process. Suppose you are still facing the complexity of running multiple platforms. In that case, there is an excellent opportunity to specialise platform engineering efforts on those unique and different requirement profiles, for example, public and private cloud.

So, why do successful companies invest in platform engineering?

Without platforms, each team would be faced with trying to solve the same problem. Taken together, these teams would find themselves solving the same problems over and over again. This inefficient approach is all the more likely when you consider that no team can afford to spend a lot of engineering time collaborating with other teams when their focus is on delivering business value.

The other key observation in today's world is that organisations are starting to develop true hybrid strategies to support the ever-growing data and number of applications, and to optimise previously overlooked cloud spend.

Platform engineering is the solution for efficiently running mission-critical enterprise software in production without compromising the pace of innovation.

As digitally-intensive organisations explore the promise of platform engineering, they begin to see the broader implications for their entire business. They see how internal developer platforms and the agility they bring act as a gateway to modern business success.

Now that you've read this article, I hope you have a more complete view of the platform engineering landscape and its 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.

The cloud-native technology landscape has matured to the point where we have all these building blocks available to us. From the technical perspective, we are now capable of building reliable infrastructure at scale, supporting developers with tools and platforms, and ensuring compliance and security at the right level. However, somehow companies still find it difficult to navigate in this space.

It’s been seven years since I started working in the platform engineering space to help companies find the optimal way in this ever-changing technology landscape. It involved enabling new technologies, building teams, improving ways of working and bringing standardization to their tech stack. Meanwhile, I experienced a lot of tough moments, making sub-optimal decisions which almost led to disaster in some cases, but somehow always staying on top of the surface. This gave me a unique perspective on this domain, especially in terms of understanding the pitfalls to avoid.

During that time, I worked with many brilliant minds, from whom I learned a lot. It would be a shame to keep this knowledge just for myself. It’s always been a goal to use technology to improve our lives without getting in the way of it. I believe this is finally possible with platform engineering.

This fall, I’m going to dedicate the time to structure the knowledge and share the complete spectrum of building and operating internal platforms for developers. I will touch on technology, strategy and real-world examples of how successful companies invest in platform engineering.

This will result in a series of articles, interviews with subject matter experts and potentially some podcasts. Stay tuned!