Community
Community
Overview
The story and values that drive us
Ambassadors
Become a Platform Engineering Ambassador
Events
Check out upcoming events near you
Reports
Check out the #1 source of industry stats
Jobs
Find your next  platform engineering role
GET CERTIFIED
Advance your career with Platform Engineering Certifications!
Get Certified
Join Community
Join as an individual
Join as an organization
Certifications
FOR INDIVIDUALS
Introduction to Platform Engineering
Platform Engineering Certified Practitioner
Platform Engineering Certified Professional
View all
FOR ORGANIZATIONS
Certified Enterprise
Certified Service Provider
Certified Training Provider
View all
BlogLandscape
Get certified
Join community
Join community
Get certified
Platform Weekly, the best newsletter in Platform Engineering. Subscribe now
Blog
How to generate value quickly when starting a platform initiative
Infra
DATA
DEVEX
AI
Leadership
SECURITY
DATA

How to generate value quickly when starting a platform initiative

Balancing leadership buy-in and dev team needs is key for platform engineering success. Prioritize adoption, ship small impactful solutions, and avoid complex early initiatives.
Dean Whitaker
Technical Principal & Consultant @ Yoh
•
Published on
February 7, 2025

When launching a platform initiative, a platform team must address the needs of two key groups: internal development teams and organizational leadership. One of the biggest challenges platform teams face is trying to simultaneously satisfy both. If the platform team focuses too heavily on securing leadership buy-in - by emphasizing metrics or large project initiatives - it may struggle to deliver value to the dev teams, which are focused on shipping code. On the other hand, if the platform team prioritizes tackling the issues dev teams face without clearly aligning those efforts with the company’s strategic goals, leadership may question the platform’s value.

Unique challenges

Platform teams operate at the intersection of feature teams and larger organizational challenges. As a result, they must navigate additional variables that traditional feature teams don't typically face - especially those related to leadership expectations.

Often, platform initiatives begin as a directive from leadership, which places significant pressure on the platform team to demonstrate immediate value and impact. Leadership needs to see the return on investment early, making it essential to show how the platform contributes to broader organizational goals. This is especially challenging since many organizations measure ROI based on externally-facing products, where revenue is easier to track. However, because platform teams focus on improving internal team effectiveness, leadership may struggle to assess the platform’s value.

In addition to leadership challenges, platform teams must “sell” their products to internal development teams. Many developers have not used an effective platform before and may not know how to engage with the platform team when a new initiative is launched. Without clear communication and training, this disconnect can significantly slow down the platform team’s success.

Finally, the platform team itself will need to go through a learning and growth period. It’s unlikely that the team will initially be staffed with experienced platform engineers familiar with all the technologies used by dev teams. This ramp-up is inevitable, but minimizing it is crucial to maintaining leadership’s trust.

Where to start 

To generate value quickly and begin making progress, prioritize adoption rate as the primary metric. This allows the platform team to:

  • Show some kind of ROI to leadership
  • Learn and mature from feedback
  • Assess how well the platform is meeting dev team needs

To drive adoption and showcase value, the platform team must ship solutions quickly. At the start of an initiative, “front-running” potential solutions can slow progress. Instead, aim to deliver small, impactful solutions that meet these criteria:

  • Start small: Deliver a shippable solution in less than a week, ideally in the hands of customers quickly.
  • Impactful: Focus on solutions that are already recognized as valuable by the organization. If an issue hasn’t been identified as important yet, you may be moving too slowly.
  • Measurable: Ensure there’s a clear path to demonstrate the impact of the solution. This doesn’t necessarily mean complex metrics; it just needs to show the solution is having the intended effect.
  • Already understood: Prioritize solving problems that leadership or dev teams have already identified. These solutions are often easier to implement and have immediate value.

This gives us a lot of flexibility on what to tackle. It could be a pipeline orb that simplifies a deployment, an addition to an existing logging framework, simplifying a permission set, moving something that already exists into Terraform, etc. If it satisfies the above criteria, it should be on the table for consideration.What do dev teams need?Once we’ve identified what problem we want to solve, we need to make sure we’re building the right solution to that problem. This is where we really get to focus on building for the dev team.For dev teams to quickly adopt a solution, it should satisfy these four criteria:

  • Frictionless: Dev teams should be able to easily integrate the solution into their workflow with minimal disruption. It should, at a minimum, be “better than what they are currently using”
  • Reduces complexity: Solutions should minimize cognitive overload, making developers’ tasks simpler.
  • Improves speed: Solutions should help developers perform tasks faster, whether it’s improving unit tests or simplifying access requests. Even a helpful "How-To" guide can be beneficial.
  • Generic and specific: Solutions should be tailored to the needs of the dev teams but flexible enough for future teams to adopt without enforced patterns.

What to avoid

Common pitfalls include focusing on highly impactful but complex tasks, such as redesigning or building a K8s cluster. While these initiatives may have high potential impact, they can take weeks or months to ship. This waterfall-style approach opens the door for delays, causing leadership to lose trust and dev teams to question the value of the platform.

Additionally, avoid targeting overly narrow solutions. Early on, focus on problems that impact multiple teams. For example, if 40% of code is in Java but 80% of developers are using GitHub Actions for CI/CD, prioritize addressing pipeline challenges over creating a Java starter kit. There will inevitably be solutions that are skewed towards certain teams over others, we want to avoid those in the beginning. 

It’s also best to avoid introducing solutions that attempt to replace solutions dev teams already have a partial implementation of. For example: If teams are using a logging framework, but they aren’t getting the right data points or metrics from it, getting dev teams to pivot quickly onto a new solution is going to pose a hurdle to adoption. Instead, it’s better to target areas where teams are lacking a solution altogether, as any solutions added to those areas will have a larger initial value.

Conclusion

Launching a platform initiative requires balancing the needs of internal development teams and organizational leadership. The key to generating value quickly is to prioritize adoption rate as a primary metric, delivering small, impactful, and measurable solutions that address recognized problems. This approach ensures that the platform team can demonstrate ROI to leadership while also meeting the practical needs of dev teams. Focusing on frictionless, low-complexity solutions that improve speed and are flexible enough for future use will encourage dev team adoption. It's essential to avoid complex, lengthy initiatives and overly narrow solutions in the early stages. By remaining agile and targeting areas where there is a clear, unmet need, the platform team can build trust with both leadership and dev teams, driving long-term success and value.

👉 Master all the key concepts of 
     platform engineering
👉 Design your first Internal Developer Platform
👉 Get access to best practice blueprints + templates
Download Course Info Pack
Share this post

Related articles

Ambassador
Infra
DEVEX
AI
DATA
Leadership
SECURITY
Infra
DEVEX
AI
DATA
Leadership
SECURITY
Ambassador
Community
Domain-driven, AI-augmented: The next chapter of platform engineering
Ajay Chankramath
CTO @ Brillio
•
•
Ambassador
Infra
DEVEX
AI
DATA
Leadership
SECURITY
Infra
DEVEX
AI
DATA
Leadership
SECURITY
Ambassador
Community
Platform engineering is reshaping the digital landscape
Cédric Derue
Solutions Architect @ Capgemini Engineering
•
•
Ambassador
Infra
DEVEX
AI
DATA
Leadership
SECURITY
Infra
DEVEX
AI
DATA
Leadership
SECURITY
Ambassador
Community
Fighting compliance trolls killing platform engineering
Jon Skarpeteig
Tribe Lead Global Platform @ Signicat
•
•
All articles
Join our Slack
Join the conversation to stay on top of trends and opportunities in the platform engineering community.
Join Slack
Sitemap
HomeAboutCertifications for individualsCertifications for organizationsEventsJobs
Resources
BlogPlatformConWhat is platform engineering?Platform toolingKartographer
Join Us
Youtube
LinkedIn
Platform Weekly
Twitter
House of Kube

Subscribe to Platform Weekly

Platform engineering deep dives and DevOps trends, delivered to your inbox crunchy, every week.

© 2025 Platform Engineering. All rights reserved.
Privacy Policy
Privacy PolicyTerms of ServiceCookies Settings
Supported by
Platform engineers earn up to 27% more than DevOps. But most engineers report not knowing where to start👇
Platform engineers earn up to 27% more than DevOps. But most engineers report not knowing where to start. 👇