Build Platform Engineering as a Product for Dev Adoption

So, your company is creating a platform engineering platform and is onboard to use it to create, test and deploy all the software applications that are built inside your operations. That is great, but now you need to take another important step — approach it as a product throughout its development and inception so that your company keeps it fresh, popular, and responsive for your developers who will be tasked with using it.

“If you actually want to build something that is going to solve a problem and be good over the long term, you really must understand what the problem is,” Daniel Bryant, a platform engineer, developer relations specialist, go-to-market professional, software developer, and the head of marketing for platform engineering vendor, Syntasso told The New Stack.  “You chat with your customers — your developers in this case — and ask, ‘Hey, what is your biggest pain point? Where do you have friction in [your work] day?’”

Using this approach, developer pain points can be addressed, resolved, and minimized, which will encourage their adoption of a platform-engineering platform that is seen as a critical tool for the companies that invest in planning and building these frameworks, said Bryant. For companies, these are the same approaches that must be taken when marketing and selling a product, he added.

“You have to do marketing within the company and you market it as a product” to encourage internal developers to “come and use my platform,” said Bryant. The move to platform engineering brings in a standardized set of tools for all developers to use, which is maintained and updated by system administrators who choose the tools, package them together, and present them as a platform for the developer teams.

The idea is to provide curated, self-service sets of development tools that encourage developers to be able to tackle their jobs without having to maintain, collate, and update their own toolsets. In the big picture, the idea of platform engineering is to ensure that developers can spend their valuable time generating great, clean, and innovative code for their companies, rather than looking for their own tools and wasting time.

But for that to work, for all these efforts to be a success, companies that are using platform engineering must be sure that they get critical buy-in from their developers so that the platforms are adopted and utilized to do their code building, said Bryant.

“Because if they are doing their own thing [assembling and using] their own tools, that is not solving this problem,” he said.

But by approaching these platforms as products that are aimed directly at their developer users, Bryant said that he believes it can inspire better buy-in from users. “Anecdotally, at Syntasso we see that. And there are industry reports that lean in that direction.”

For this to happen, the planning for successful platform as product approaches must start at the nascent stages of a platform engineering strategy as it is being envisioned and implemented, he said.

That means getting ideas from developers at every step through the software development processes, including coding, shipping, production, and more that will help to provide value and insights that allow the platform as a product concept to succeed, said Bryant.

“It is basically applying product thinking,” he said. “It is all the thinking we do when we design our iPhones or apps or whatever, just applying that methodology, that thinking, to the internal developer platform (IDP) [that is being built]. And it is important to think long term.”

Top Tips for Platform as a Product Success

So, how can a successful platform engineering implementation for an IDP be built from the ground up to succeed as a product that drives innovation and success for developers and companies?

Bryant has several tips for systems administrators and IT managers who are tasked with making platform engineering work within their companies.

• “Ensure that someone within the team has a product owner mindset,” he said. “The infrastructure folks, they have not been building products. They have been racking and stacking. And it is not in a disrespectful way that I say this, but … we need to train the folks that are doing it to have a product mindset. That is key.”
• Also critical is that the platform as a product team and organizers must talk to developers about what is being planned, implemented and finalized, said Bryant. “Too many times in my 20-year IT career I saw us building stuff without talking to our customers [developers]. The same goes for the platform – who you are building it for, why [it is being built] and what their problems are. You will never build the right thing [without addressing these issues.]
• “And the third thing I would say, is to measure the results from day one” to get a good feedback loop, said Bryant. “Get that baseline, because some folks do not know what impact they have had because they have not measured from day one. They will think they have made it faster, [but will not know unless they] measure from day one.”
• Always make improvements and tweaks to keep the platform product vital, efficient, and up to date for its users because the process is a voyage, not a destination, said Bryant. “Focus early on delivering value as quickly as possible,” he said. “We talk a lot about [creating] the thinnest, minimum viable platform (MVP)” on which to base a company’s IDP to keep it simple and create a solid product for developers who once they see it will realize that they need to have it.
• Do not worry about establishing quick wins, but instead be sure to deliver real value that shows a path for further progress in the future, said Bryant. “That is a hard balance. I have seen people try to get quick wins and then the product only works for a month or so. It is not very good. I have seen some folks obsess about long-term value, and then they do not show any value upfront. So, the platform itself gets canceled from a budgeting point of view. So, you need to get this balance of showing value early, fixing real problems, ensuring that developers have a minimum viable product in this form, but with an eye to … sustainably evolve the platform to meet more and more use cases, to provide more and more value.”

Ultimately, an IDP that will be successfully created inside a company is one that is continuously maintained, improved, changed, and that incorporates feedback and operational insights, said Bryant.

“We talk about platform decay quite a bit at Syntasso,” he said. “You know, just entropy in the world in general, like new versions of things come out. And then people do not maintain things. Then the platform decays. You need to be on that kind of thing, too.”