The Kubernetes platform engineering north star - How to convince your boss that an internal platform accelerates business

So you want to convince your boss that having a platform engineering strategy for your IDP or Internal Developer Portal is important. First of all, what is an IDP? An Internal Developer Platform (IDP) is a centralised, self-service system within an organisation that gives software developers everything they need to build and deploy applications without dealing with the underlying infrastructure complexity. Think of it like a company-specific virtual vending machine (service catalogue) that provides standardised templates, workflows, and resources so developers can focus on writing code. This is so they don’t have to mess around with configuring servers, setting up databases, or managing CI/CD pipelines. IDPs typically include monitoring and observability, APIs, and automation tools that handle repetitive technical work. Bad news for rogue developers who run shadow IT, but an IDP can enforce company security standards. Conversely, one of the many benefits of the IDP is that it helps with reducing the cognitive load for developers. But where do you start with building one or if you already have an IDP, whether it’s built on best practices? We have so much information these days, and you might not have time to distill all the information to make sense of it. Not to mention, there’s already a few issues piling up that need your immediate attention. You and your team might be dreaming about that single platform that rules them all, where all your developers will willingly use your platform to deploy all the infrastructure they need. While your platform operates seamlessly, without you being woken up at odd hours in the morning. In reality, it’s not that easy - Kubernetes can be complicated if you let it. There are so many ways to get your platform wrong, especially if you’re not keeping up with the version and dependency upgrades which inevitably comes around every few months. If you don’t have standardisation around how you’re going to operate this IDP, then people in your team wouldn’t know how to fix it when it’s broken. I’ve seen many customers struggling with getting started with 1. Convincing their boss around the benefits of building an IDP and 2. Continue to advocate for the platform to gain use. Unfortunately, if you build it, they (developers) won’t come running to it. Not to mention 3. How do you ensure you have operational excellence built in so you don’t suffer from dreading Kubernetes upgrades and suffer catastrophic application failures because of it. Haofei Feng and I co-wrote this document around how to start thinking strategically on platform engineering and improving the maturity around your Kubernetes model. Although we wrote this with Amazon EKS in mind, the same principles can be applied to any Kubernetes platform you’re using. I’ve been channeling Gregor Hohpe and his platform strategy book throughout this process. I highly recommend having a read of his books! Why Platform Engineering Matters Why should your organisation care about platform engineering in the first place? The short answer: Developer productivity and organisational agility. The longer answer is that a well-designed internal platform lets your developers focus on writing code instead of wrestling with infrastructure. It provides consistent, self-service access to the cloud-native capabilities they need, enhances developer flow, and ensures security and compliance by default. Yes you need to think about security and compliance in your organisation, no matter how boring this might sound. While you’re at it, it doesn’t hurt to become friends with the security team. They’ll give you some great pointers to look out for if your idea needs approval internally. The Platform Engineering Vision A successful platform engineering vision has several key components according to the CNCF Platforms White Paper: Platform as a product: It should be designed with your end-users in mind, likely developers focusing on building common use cases across products. Focus on user experience: It should meet users where they are, offering multiple interfaces (GUIs, APIs, CLIs). Documentation and onboarding: We’re all guilty for this, you gotta have documentation. Make sure you not only write how to use it but keep your docs updated frequently. Ever encountered a time where someone in your team took some time off and couldn’t fix an issue because it wasn’t documented anywhere? Additionally, it’s important you do some internal training and mentoring to help onboard the users that are going to use your platform. This also acts as a bit of an internal marketing exercise too. Self-service capabilities: Users should be able to request and receive capabilities via self-service. What does that mean? Ultimately you want developers not having to mess around with infrastructure to make things work. Wouldn’t it be great if they can get a single page web application vended to them like a virtual vending machine? Imagin

Apr 24, 2025 - 04:30

The Kubernetes platform engineering north star - How to convince your boss that an internal platform accelerates business

So you want to convince your boss that having a platform engineering strategy for your IDP or Internal Developer Portal is important.
First of all, what is an IDP?

An Internal Developer Platform (IDP) is a centralised, self-service system within an organisation that gives software developers everything they need to build and deploy applications without dealing with the underlying infrastructure complexity.
Think of it like a company-specific virtual vending machine (service catalogue) that provides standardised templates, workflows, and resources so developers can focus on writing code. This is so they don’t have to mess around with configuring servers, setting up databases, or managing CI/CD pipelines.

IDPs typically include monitoring and observability, APIs, and automation tools that handle repetitive technical work. Bad news for rogue developers who run shadow IT, but an IDP can enforce company security standards.

Conversely, one of the many benefits of the IDP is that it helps with reducing the cognitive load for developers.
But where do you start with building one or if you already have an IDP, whether it’s built on best practices?

We have so much information these days, and you might not have time to distill all the information to make sense of it. Not to mention, there’s already a few issues piling up that need your immediate attention.

You and your team might be dreaming about that single platform that rules them all, where all your developers will willingly use your platform to deploy all the infrastructure they need.
While your platform operates seamlessly, without you being woken up at odd hours in the morning.

In reality, it’s not that easy - Kubernetes can be complicated if you let it. There are so many ways to get your platform wrong, especially if you’re not keeping up with the version and dependency upgrades which inevitably comes around every few months.
If you don’t have standardisation around how you’re going to operate this IDP, then people in your team wouldn’t know how to fix it when it’s broken.

I’ve seen many customers struggling with getting started with 1. Convincing their boss around the benefits of building an IDP and 2. Continue to advocate for the platform to gain use. Unfortunately, if you build it, they (developers) won’t come running to it. Not to mention 3. How do you ensure you have operational excellence built in so you don’t suffer from dreading Kubernetes upgrades and suffer catastrophic application failures because of it.

Haofei Feng and I co-wrote this document around how to start thinking strategically on platform engineering and improving the maturity around your Kubernetes model. Although we wrote this with Amazon EKS in mind, the same principles can be applied to any Kubernetes platform you’re using.

I’ve been channeling Gregor Hohpe and his platform strategy book throughout this process. I highly recommend having a read of his books!

Why Platform Engineering Matters

Why should your organisation care about platform engineering in the first place?
The short answer: Developer productivity and organisational agility.
The longer answer is that a well-designed internal platform lets your developers focus on writing code instead of wrestling with infrastructure.
It provides consistent, self-service access to the cloud-native capabilities they need, enhances developer flow, and ensures security and compliance by default.
Yes you need to think about security and compliance in your organisation, no matter how boring this might sound.
While you’re at it, it doesn’t hurt to become friends with the security team. They’ll give you some great pointers to look out for if your idea needs approval internally.

The Platform Engineering Vision

A successful platform engineering vision has several key components according to the CNCF Platforms White Paper:

Platform as a product: It should be designed with your end-users in mind, likely developers focusing on building common use cases across products.
Focus on user experience: It should meet users where they are, offering multiple interfaces (GUIs, APIs, CLIs).
Documentation and onboarding: We’re all guilty for this, you gotta have documentation. Make sure you not only write how to use it but keep your docs updated frequently. Ever encountered a time where someone in your team took some time off and couldn’t fix an issue because it wasn’t documented anywhere? Additionally, it’s important you do some internal training and mentoring to help onboard the users that are going to use your platform. This also acts as a bit of an internal marketing exercise too.
Self-service capabilities: Users should be able to request and receive capabilities via self-service. What does that mean? Ultimately you want developers not having to mess around with infrastructure to make things work. Wouldn’t it be great if they can get a single page web application vended to them like a virtual vending machine? Imagine not having to deal with troubleshooting permission errors to make something work.
Reduced cognitive load: Hide complexity and implementation details from users. It’s what Gordon Ramsey used to say, Keep It Stupidly Simple (KISS). Would you want to deal with a heavily complicated platform that has all the features and patterns that you can imagine from the start? Or start simple with solid functionality and solicit new features and feedback from your users?
Optional and composable: Teams should be able to use only the parts they need and not be forced to use all the features. The more de-coupled your services are, the less blast radius. Let’s move away from the tightly coupled, monolithic approach.
Secure by default: Compliance by design and validation based on standards. Don’t have a standard? Maybe start building one. Here’s a good baseline to refer to.

The north star architecture

What does a target state architecture that incorporates modern cloud-native practices look like?

Infrastructure as Code: Terraform and Crossplane for declarative infrastructure
GitOps-Driven Automation: Argo CD and Argo Workflows for deployment and orchestration
Developer Self-Service: Backstage as a developer portal to centralise workflows
Scalable & Flexible Architecture: Kubernetes as the core platform with various optimisation strategies
Platform Governance: Integrated with IAM, security policies, and compliance controls

Source diagram: https://github.com/cnoe-io/reference-implementation-aws

Using the CNCF Platform Engineering Maturity Model

Great! You have all of the above. Can we officially call our IDP mature enough?
You can assess your platform using a four level maturity model based on the CNCF Platform Engineering Maturity framework:

Level 1 - Provisional: Ad-hoc, reactive responses to team needs
Level 2 - Operational: Dedicated platform teams, standard interfaces, centralised tracking
Level 3 - Scalable: Self-service solutions, centrally orchestrated capabilities, standard processes
Level 4 - Optimising: Intrinsic pull from users, integrated services, quantitative and qualitative measurement The above model evaluates maturity across five areas:
Investment: How staff and funds are allocated
Adoption: How users discover and use platform capabilities
Interfaces: How users interact with the platform
Operations: How platform capabilities are planned and maintained
Measurement: How feedback is gathered and incorporated

You can read more around the maturity model here.

Path to platform maturity

What do you need to do if your platform is not there yet?
There’s a three-phase transformation approach:

Phase 1: Solidify the Foundation

Establish security controls and boundaries
Define operating model and RACI
Create IaC blueprints and DevOps pipelines
Document common consumption patterns
Develop comprehensive documentation

Phase 2: Scale and Enhance

Implement advanced self-service features
Develop an internal developer portal
Improve governance with preventive and detective controls
Collect and analyse user feedback
Provide advanced training for platform consumers

Phase 3: Optimise and Innovate

Foster experimentation culture
Hire and develop engineering talent
Form cross-functional teams for inner-sourcing models
Leverage emerging technologies like generative AI
Build robust feedback loops

You can see what this is all about in this YouTube video here about Platform Engineering with Amazon EKS.

How to talk to your boss about this

If you're trying to convince leadership to invest in improving your platform or building one from scratch, here are some talking points:

Focus on business outcomes: When I was an Infrastructure Engineer (what you’ll call a Platform/DevOps engineer these days) I struggled to tie the “business outcomes” to the tech that I was talking about. Think beyond the scope of what you do day to day. What would your team, your department and your entire organisation benefit from long-term with this platform? You can mention that this platform can help accelerate developer productivity, improve operational efficiency, enhance organisational agility, and be able to scale and scale back down when not in use, reducing costs. Here’s some more data points that you can reference in your pitch.
Show the adoption pattern: Initially, platform adoption is slow and there might be resistance within the internal teams. You need to show the developer teams the value that the platform provides by internal presentations. What if you’re afraid of running presentations or even speaking up in front of your colleagues? That used to be me, 10 years ago. I used to get really nervous and my heart would race every time I spoke within a large group of people. You know what helped? Toastmasters. There’s one near your neighbourhood or even at your workplace if you’re lucky. If not, there’s online toastmasters which you can join in. Start there, and work your way on speaking more in front of people. Don’t worry, you got this! Once you’re able to do some internal promotion of your platform, your users will be intrigued. Once they start using it, then it starts to provide value by creating a steeper adoption curve.
Highlight the cost of not investing: What we call the “opportunity cost”. Without a platform strategy, teams will duplicate efforts, security will be inconsistent, and developer productivity will suffer. Who’s seen different CI/CD tooling used by one team of developers vs another? The old tech adage of “if it ain’t broke don’t touch it” will lead to more technical debt.
Present a phased approach: You don't need to do everything at once. Otherwise you’ll fall into the trap of analysis paralysis. Start with having a solid baseline, then scale, then optimise.
Use the maturity model as a benchmark: Continuously check where your organisation currently stands and show the practical steps needed to advance to the next level. If you can gamify going to the next level and make it fun, the better for platform adoption!

Here’s a great way to capture your boss’s attention around Platform Engineering. Thanks to Frank Fan who is a Senior Specialist Container Solutions Architect for co-presenting and diving deep into this concept at AWS ANZ Summit.

Time to get building

The journey to platform excellence is a marathon, not a sprint. Yes we know, you want to get something up and running and want to impress your boss with results.
With a clear vision, a maturity model, and a practical roadmap you can refer to, you can build a platform that your developers rave about.
Not only that, your security teams will be impressed (wait, that would never happen. Security teams always seem to be grumpy), and your boss will be glad that you can help them deliver business value faster.

Remember, the goal isn't to reach the highest maturity level – it's about finding the right balance for your organisation's needs.
What's your current platform maturity level?
What challenges are you facing in your platform engineering journey?
I'd love to hear your thoughts and experiences in the comments below!

Author bio:

Haofei Feng (Dev.to user: fldhmily63319)
Senior Cloud Architect - Professional Services - AWS

Haofei is an innovative strategic technology leader with 19 years’ experience delivering impactful consulting, architecture, and managed services across the full project lifecycle—from strategic advisory and presales influence to hands-on execution and operational excellence. Renowned for aligning business objectives with advanced cloud, data, and AI solutions across regulated and complex industries. Proven ability to communicate complex technical concepts to executive stakeholders, build consensus, shape organizational vision and deliver transformation programs that drive measurable business value at scale. Recognized for authoring and presenting strategic whitepapers guiding operating model and maturity frameworks to enable sustainable business transformation.

Mai Nishitani
Director of Enterprise Architecture - NTT Data

Mai is a former-AWS Solutions Architect who is passionate about experimenting with new things.