Guest Author

Top 8 Mistakes Made by Platform Engineers

Platform engineering is centered around building developer self-service tools to reduce errors and increase reliability. You can think of it as the next step to the DevOps culture.

Platforms, also known as Internal Developer Platforms (IDP), are delivered by platform engineers to cover the operational needs for the application’s lifecycle, ideally increasing performance without increasing cognitive load for the dev team. IDPs usually look like an extra layer on top of the tooling and technologies a dev team already has, thereby providing a golden path that handles the complexity of their setup more effectively.

Are you considering developing an IDP but need help figuring out where to start? Maybe you’ve taken some steps already, but you are concerned that you may be taking it too far. Don’t worry! This article highlights the common mistakes made by platform engineers when developing an IDP. After reading it, you’ll be able to tell whether you are on track, what not to do when you get started, and how to address these mistakes.

1. Platform engineers reinventing the wheel

Everyone thinks that they have an extraordinary and unique team. But chances are your team is not as unique as you think. Often, the needs of a certain software development team occur across other software engineering teams. If that weren’t the case, we probably wouldn’t have products like the ones cloud providers offer.

Most platform engineers and their teams make the mistake of reinventing the wheel by building their own device farm, provisioning their own infrastructure, and even spending time writing their own generic Helm charts when they could have saved their dev team hundred of hours and headaches by using platforms that offer that same functionality. The truth is if your platform engineers are developing the exact tool that already exists, then they are doing something wrong and not utilizing their time and resources efficiently.

To avoid this, focus only on building functionalities that are unique to your setup or your team; otherwise, you are just reinventing the wheel by building tools that already exist.

2. Only building dashboards to fix the problems

You’d often hear people say, “If only we could get this in a dashboard so that we know what is happening”. There is the notion that the first step to fixing a problem is knowing what the problem is. However, the truth is, displaying what the problem is visually won’t get it fixed.

Using dashboards may help management to visualize what’s happening, and there’s nothing wrong with that, but that shouldn’t be the top priority of your IDP because your IDP should aim towards reducing failure rates, increasing reliability, and simplifying the processes your dev team follows. In essence, you should only implement dashboards if they address a more vital issue like onboarding a new teammate.

Here are some blueprint questions you could ask yourself and your dev team to prioritize correctly. Rank them in order of how many times they happen out of all of your deployments, and then attack them: Are you setting up a new environment or service? Are you adding or removing any resources? Are you adding or changing environment variables or other app configurations? Is there anything creating unstructured maintenance and errors? Is your infrastructure hanging or delaying in any way?

3. Spending too much time planning and too little on shipping features

Getting a well-planned and functional IDP is all about prioritization. But how do you know if you are prioritizing correctly? Well, this should be based on your deployments’ procedures frequency. If you add services or dependencies every once in a hundred deployments, this shouldn’t be your biggest priority.

Before requiring certain features that might not offer the biggest return on the time and resources invested, these questions would be worth asking to prioritize better: Can less frequent procedures be attended to with other tools? Is running a script enough? Is there any other platform that we can use that already has this feature implemented? When you answer these questions, you’ll be able to ship functionalities with a higher priority and create feedback loops that create a better experience for people using your IDP.

Another thing to avoid is building your IDP without carrying the dev team along. The thing is, if platform engineers are siloed and building the IDP secretly and then deliver it to the dev team, it has a higher chance of failing because it might not meet certain requirements, but if you ship and create positive feedback loops between the dev team and your platform engineers, the adoption of the IDP will be massive and as such have a great return of investment.

4. Not designing for every developer on your team

Internal developer platforms should be accessible to every developer in your team. Since you are treating your IDP as a product, part of the user team will have more than one level of knowledge and/or seniority, so you should build for every level of developer on the team. If you build only for the most senior developers, juniors won’t be able to use your IDP, and you will end up with the problem stated above.

Good IDPs are designed for the weakest link on the team. Ask all of your dev team for input but beware of the other mistakes mentioned here. Just remember that the needs of junior developers shouldn’t restrict senior developers and vice versa.

5. Trying to build one platform to rule them all

When trying to reduce cognitive load, cleaning up the problem of having too many tools always comes to mind, but you shouldn’t because transcribing scripts from one technology to another can be a distraction, and benefits might be lower than the investment. Implementing the “If it ain’t broke, don’t fix it” rule is always a plus here!

To avoid this problem, try to standardize and restrict responsibilities to avoid having too many platforms doing too much (CI platforms, for example) and aim towards creating a great developer experience without the hassle of having to rewrite everything, set up new tools, or even worse, set up your development environment again.

6. Assuming their platform is good because it is being used

Success isn’t measured by whether your IDP is being utilized or not. It being used must make it a good IDP, doesn’t it? Well, not really! Platforms tend to be robust as they intend to replicate what you already have in the works, but they don’t consistently achieve it. Sometimes, it is a mediocre platform that teams still use because of the investment made in the IDP or for some other reason.

You should always aim to make processes of your IDP multiple times better regardless of its usage. This is why you build IDPs as products!

As in the planning and shipping features mistake, don’t have your platform engineers build in secret or try to rule all your processes with one IDP. Instead, start small and build your IDP as a product. Build one feature and deliver the best possible experience with it, your team will thank you later, and the adoption of the IDP will be taken care of by itself.

7. Reducing dev capabilities by abstracting too much

If your IDP is creating golden paths, that’s ok, but if you restrict access to underlying abstraction technologies, something is wrong. Remember, abstraction almost always reduces capabilities.

To tackle this common mistake, don’t abstract just for the sake of abstraction. If your IDP abstracts individual layers away from the developers, it better be because it is needed or delivers a specific value.

8. Make the whole dev team adopt the “if you build it, you run it” approach

If you build it, you run it, right? Ok, so if the whole dev team built the product, the whole team should run it? Well, probably that’s not the wisest move. If you let the whole team run the ops of the product, you will have everyone familiarizing themselves with new technologies instead of getting work done.

Eventually, the product will regain focus, but only the wisest and most skilled resources on your team will be managing environments and configurations, and their input is lost on the product. Eliminating key person dependencies is necessary, but this doesn’t mean everyone has to be an expert in everything; otherwise, productivity will fall.

Yes, you can avoid key person dependencies by having your whole team use the IDP but always optimize for a degree of cognitive load that the team is ready to handle without losing grip on the product being built.

Closing thoughts

So what now? Keep the following points in mind when building or updating an IDP:

• Have your platform engineers use the product approach to build your IDP
• Products (e.g., your platform) mainly rely on voluntary adoption, so solicit regular feedback, iterate, launch the platform, and market it internally to your dev team.
• Try to avoid the mistakes listed in this article, and your developer self-service platform won’t have you needing 1000 experts to run 1000 services.

Thanks for reading this article. If you have any questions or concerns, share them in the comments section.