Five Ways Your Platform Engineering Journey Can Derail

Platform engineering is a powerful tool that IT admin teams use to provide just the right combinations of software tool lineups for their application developers. But like anything in work and life, it is not perfect. There can be some challenges in creating and using it as well.

To help recognize and lessen some of those pitfalls, The New Stack spoke with two platform engineering experts who shared their advice for how they handled some of the common challenges they faced using this approach inside their companies.

Jordan Chernev, a senior technology executive for platform engineering and SRE in e-commerce, retail and real estate, said pitfalls in platform engineering lay in wait around many corners.

Pitfall 1: Change Processes, Not Just Names

Chernev’s first pitfall is when a company tries to start platform engineering by only changing the name of its current development practices, without doing the real work.

“Simply rebranding an existing infrastructure or DevOps or SRE practice over to platform engineering without really accounting for evolving the culture within and outside the team to be product-oriented or focused” is a huge mistake, he told The New Stack. “In practice, that means not having explicit product managers working with or on the team helping to capture cornerstone items” such as user personas, user market opportunities or the reasons for using platform engineering with each work stream. “Just hiring product managers is not a successful approach either,” he said. “One needs to elevate the culture of the entire team to think product and customer outcomes first.”

Pitfall 2: Not Ensuring That Product Backlogs Aim Directly at Your Developers

Another major pitfall, he said, is not having and maintaining product backlogs — prioritized lists of work for the development team — that are directly targeting your developers. “For the groups who have backlogs, they are usually technology-oriented,” he said. “That misalignment in thinking across planning and missing feedback loops is unlikely to move progress forward within the organization. That ultimately leads the initiative to fail to deliver business value. Instead, they should be developer-centric,” said Chernev.

Pitfall 3: Not Informing All Employees of the Business Value of Platform Engineering

This is another important point, said Chernev — companies that do not clearly articulate the value-add of their platform engineering charter to both technical and non-technical stakeholders inside their operations will not fully be able to reap the benefits of the platform’s use across the business.

“If teams are not thinking along the lines of product use cases and being able to speak about the program’s benefits to senior level executives … the message will likely fall short,” said Chernev. Platform engineering team leaders must be able to communicate how it is accelerating the time to customer outcomes while using the same R&D headcount and software costs without compromising on uptime, performance, security and availability guarantees, he added.

Pitfall 4: Do Not Use Force Against Skeptic Developers

There are going to be members of your developer team that do not want change, said Chernev. It is OK. Let them adjust to the changes at their own pace.

“Forcing platform adoption on users as opposed to them organically adopting it is likely to backfire,” he said. “Even if a platform-as-a-product does provide value for some subset of cohorts within the community, it is unlikely that it will meet everyone’s needs at all times.”

Instead, platform teams should optimize for solving for the 80% of end user needs while actively supporting users who choose not to be on the platform, advised Chernev. “Teams need to have choice and if they do not, this will turn into a hard-to-navigate-and-win cultural problem within the enterprise,” he said.

By allowing hesitant developers to make their own choices, “This will also create the proper incentives for platform teams to build better products and actually have to compete for quality of user experiences,” said Chernev.

Pitfall 5: Not Tracking the Project’s Success with Solid, Provable Metrics

Platform engineering can only go as far as its results will take you, said Chernev. “A lack of North Star metrics that help guide the program’s success” will slow down platform engineering efforts, he said. The most important metrics to track and report on are adoption rate, end user Net Promoter Scores, key outcomes delivered from teams using the platform-as-a-product, and platform onboarding time.

“Platform teams will be more successful if they realize that this set is just the start of the journey as opposed to the end destination,” said Chernev.

“You Will Always Have People Who Don’t Want to Get on the Bus”

Our other platform engineering expert, Dylan Scholz, platform engineering director for an online insurance marketplace, said that to him, the most important pitfall from Chernev’s list above is when companies decide to crack down and try to make every developer adhere to new platform engineering mandates.

“You will always have people who don’t want to get on the bus” to arrive at platform engineering nirvana, said Scholz. “A pitfall is trying to be perfect and capture every scenario out of the gate. Sometimes you will have individuals who may not want to adopt the platform that you are using and letting some of those edge cases fail is fine.”

Think about it from a product adoption life cycle, said Scholz. “You have your early adopters, you have teams that are kind of in the middle, and you have people who do not want to do it, which is often the last 5%.”

At some point, retreating from those last-minute battles can be the right thing to do, he asserted.

“You do not want to create a hostile environment or a central compliance team that forces people to do things they do not want to do,” he said. “You need to try, ‘Hey, we are here to help make tools better and make it easier for everyone.’ And eventually, over time, they will adopt your platform. Sometimes perfect is the enemy of good.”

It is also important to avoid the pitfall that all platform engineering tools chosen for the platform by the IT administrators are the right choices all the time, he said.

“Knowing when a tool is not working is really important,” said Scholz. “If you pick a tool and the tool is wrong, it is okay to admit it is wrong and pivot. It happens occasionally. You must listen to your engineers. If your engineers say, ‘This tool sucks,’ you absolutely need to take that customer-first approach and say, ‘This is a really bad experience.’”

To battle that pitfall, it takes a responsive admin team, he said.

“You must establish that feedback loop with your customers, the engineers,” said Scholz. “And you really must have your finger on the pulse and ask how things are going. There is a bit of art sometimes involved with picking the right tools that solve the problems that engineers must solve.”