Blog

Platform Engineering Essentials: 5 Key Learnings Before You Start

28 Mar, 2024
Xebia Background Header Wave

Are you starting on your platform engineering journey? Are you looking at how to create a successful platform with lasting value? Do you want to get people to come along on the journey?

Platform engineering can help organizations reduce cognitive load for development teams and create a significant improvement in developer experience (DevEx) as well as several other areas.

Whether you are looking to create standardization in how applications are structured (for instance for compliance reasons or to make your portfolio of applications more maintainable), looking for a golden path in automation, or want to be able to bootstrap applications fast, the possibilities and opportunities for organizations to improve software delivery are vast.

But this vastness of opportunities in itself can present a challenge. There can be a variety of reasons for starting a platform initiative with very different outcomes that don’t always go together well or can even be mutually exclusive.

Combine this with the urgency to jump on the bandwagon that is felt in many companies and several risks can be observed:

  • Underprioritze the needs of the actual users of the platform in favor of other interests
  • Opaque goals and lack of vision, result in everyone having different expectations
  • Omitting to set measurable goals and validate if they are achieved
  • Starting without the right buy-in and commitment
  • Not taking the culture and skill level of the organization into account
  • Creating false expectations

Based on these observations and being part of the implementations of Internal Developer Platforms (IDPs) Continuous Delivery as a Service (CDaaS) in various organizations I will be sharing 5 of my biggest learnings.

1. Build a platform based on an actual need. For example, to improve developer experience, reduce cognitive load, or bring desired capabilities to the teams that were not available before. This may sound obvious but I believe it is not.

Don’t build a platform because it is trendy, looks good on your resume, or you’re dying to work with the tech. Have clear goals before you start, start measuring your progress on these goals right away so you know you are on the right track.

Test that the capabilities you want to deliver are actually desired by the teams. Gaging early if teams are eager to onboard is your first test if your platform is feasible.

One form of approach could be to deliver one capability quickly to onboard teams onto, and then expand from there. Do not build a platform with all the capabilities you want to include in the target state before onboarding teams and getting feedback from them.

If no one wants to onboard, you might be working on the wrong problem. By starting small you potentially save a lot of time and effort.

 

2. Set targets and start measuring from the beginning. Don’t treat metrics as an afterthought; start measuring the usage of the platform and how it contributes to your goals from the beginning.

As an example, you could look at some of the newer DevEx or SPACE frameworks for inspiration if you are looking to improve the developer experience. Start collecting information by doing surveys.

Using surveys you can start collecting valuable information fast and it is often a lot easier to achieve than capturing metrics through automation. Involve the development teams in what you want to measure. This will help to create buy-in and validate needs.

In the same way, if the goal is standardization, auditability, and cost reduction the information you capture should reflect that.

Measuring from the beginning will help you know that you are on the right path and provide you with early feedback.

 

3. Make sure it has the right organizational commitment. Building a suitable and sustainable platform is more than a technical challenge; it might also require a change in the way people work and sometimes new skills are needed. This is true in lagging organizations but even in places that are more innovative.

You need commitment from management to support the budget and communicate the importance. You need commitment from teams to onboard and learn new skills. Therefore, you can not easily create a platform as a side project, it has to be top-of-mind for the organization to be successful.

Even if you choose a bottom-up, “grassroots” approach you do need a form of support from the management so that you don’t end up with something that is unsupported and only causes problems down the line instead of solving them.

 

4. Use fair terminology and manage expectations. There can be several legitimate goals you want to achieve with a platform you onboard your teams on. You need to be fair about the goals you are set to achieve so you don’t raise false expectations. So, if the main goal is compliance, say that, and say why. Don’t call it productivity.

When your goal is to make teams work with a pre-defined set of tools and processes, autonomy decreases in exchange for control. These are trade-offs you need to consider, and you need to communicate these trade-offs.

 

5. Keep the developers’ interests at heart and keep stakeholders in check. Platform engineering holds a promise for more productivity and better software, but at the same time it can turn against the interest of developers and achieve the opposite:

  • Using metrics generated by the platform to compare teams against each other
  • Locking everything down to a few trusted sources, trading developer’s freedom for security (and achieving the opposite)
  • Forcing a single set of supported tools and processes, while making it hard to diverge from the golden path for automation will take away autonomy

Metrics can be threatening in an unsafe environment, lead to anxiety and teams might create ways to game the system.

Paradoxically, locking down everything might make your platform less secure. Make sure the security office understands this, and make good agreements beforehand to prevent slowdown.

This is also where good and responsible Product Ownership comes into play: You need someone who gathers needs from relevant stakeholders and weighs these different interests against each other while making sure the interests of the users of the platform are taken care of. It will be harder to meet other goals if their experience is under-prioritized.

Carefully consider these factors before proceeding.

 

Conclusion

When building a platform be aware that you can not change how an organization works and software is developed just by bringing in new tools and technical capabilities. It should be part of a bigger effort and requires mindset and skills to make use of these capabilities successfully.

You need to be aware of the culture in the organizations you work for and realize that the tech can be used for good and bad. If you risk the latter to be true, make sure those organizational issues will be worked on before proceeding.

The goals you want to achieve need to be clear to everyone.

Be fair in your communication and never lose the developer experience out of sight trying to achieve the organization’s needs or you won’t achieve your goals. Instead, fairly balance the developer’s needs against other stakeholder’s interests and communicate trade-offs.

Measure your progress continuously to know when you are on the right track. Make sure you have the right organizational commitment. It can not be a side project. Onboard teams as early as possible for real feedback.

By taking the above advice at heart it is my belief you will dramatically increase the chance to create a valuable platform with lasting value.

 

Bert Rijsdijk
I help teams to speed up and improve the complete software delivery process. My mission is to get software in the hands of users faster by reducing time to market, enabling early feedback, and giving development teams the capabilities they need to succeed.
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts