
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.