Open up a web browser.
Google “What is Platform Engineering?”.
You’ll be greeted with a massive amount of links.
As you go through each Google result, you’ll notice a trend. It’s all about Developer Experience, customer service for internal engineers, and treating the Platform Engineering environment like a product. A good product encompasses amazing developer experience, so it all comes down to treating your environment like a product.
In this blog post, you’ll dive into what a product is, how to implement a product mindset as an engineer, and how to advocate for the product you build.
What’s A Product
You’re reading this on a device, right? Maybe a phone. Maybe a laptop. Maybe a tablet. You’re reading this blog post on a product.
A car is a product.
A couch is a product.
A garbage can is a product.
And think about it, all of these products are aimed to give you something in life. To make your life a little more efficient. A car that has cooled and heated seats. A garbage can that has a foot pedal so you don’t have to manually open the lid. It’s all about enhancing your life with the product. Making life a little bit more efficient.
Now, as we all know, that’s not ALL products, but many would argue that’s the goal and intention of all products, even if it’s not the actual outcome.
When you, as a Platform Engineer, build an internal platform for internal engineers and developers to use, you’re building a product. That product is being used like any other product – to enhance the quality of life. To make life more efficient in that particular instance.
What’s A Product Mindset
There are three things you should keep in mind as you’re building a product.
- Did you confirm what the internal engineers/developers need from the product?
- Was the platform created and planned as if it were NOT an internal platform?
- Has it been tested by users outside of the Platform Engineers that built it?
All of these points are critical, but number 2 is something that really sticks out. When departments build internal tools, there’s this notion that it doesn’t have to be 100%. Customers aren’t seeing it. People aren’t paying money to use it. Therefore, it can be created “just enough” to “be okay” and “to work”. That’s the completely wrong mindset to have in this instance. What you’re building should be looked at just as good, if not better, than what external customers are using. Why? Because what you’re building as a Platform Engineer is how the external customers are getting their product and most importantly, it’s the internal teams within your organization that need your help.
Once number 2 is fully understood, it’s time to go back to number 1. Did you talk to the teams? Do you know what the teams need? For example, do they need a GUI or a CLI? What tools do they need to interact with to make their life easier to do their job?
Last but certainly not least is number 3. There’s nothing worse than building something, testing it yourself, giving it to the public, and not getting the outcome that you expected. Always have internal test users who are not part of the Platform Engineering team.
A few other things to keep in mind are:
- Document accordingly.
- Understand engineer/developer needs.
- Research the needs of internal engineers/developers
- Always think about Developer Experience (DevEx)
Market Your Product
One great title for a Platform Engineer is “Enabler”.
Platform Engineering at its core is meant for one thing – to enable engineering teams. It’s to make the lives of internal engineers and developers more efficient. It’s to ensure as much reliability when the internal engineers are deploying workloads as possible. It’s to enhance their experience.
But if they don’t know about the product you’ve built, how will they know how much it’ll enhance their lives?
One job of a Platform Engineer is to be the platform’s advocate. You’ll need to show the platform to the internal engineers, show them the benefits, and the ease of use. You’ll have to “sell” them the idea of it (sell is a harsh word, but it’s inevitably needed). Marketing and sales aren’t usually part of an engineer’s job description, so think about it like this – if a product is so good that no one can ignore it, it doesn’t have to be sold and marketed from the traditional sense, right? You just know that you want it and you must have it.
That’s how internal engineers and developers should be thinking about the product you build.