In the grand scheme of software development, platform engineering is a relatively new discipline. As such, platform engineering teams are still figuring out best practices and messing up along the way.
In a talk at PlatformCon 2025 last week, Camille Fournier, CTO of Open Athena and co-author (alongside Ian Nowland) of the book “Platform Engineering: A Guide for Technical, Product, and People Leaders,” explored common mistakes she sees teams making and offers advice on how to avoid them.
“We think that platform engineering is the next logical evolution that is needed by the technology industry to really handle a lot of the underlying complexity that we’re seeing today, especially in large technology organizations,” she said. “We think this is a very important topic, but we also think it’s a very hard thing to do. We’ve seen a lot of people try and struggle to build out successful platform teams, and so we wrote this book as an attempt to help people who were struggling with platform engineering to do a better job.”
RELATED CONTENT: Building a culture that will drive platform engineering success
A common mistake people make is not putting the right people on the team, such as only including software engineers or only including operations. Platform engineering teams need a mix of people with different skills, including software engineers, DevOps, SREs, infrastructure engineers, and systems engineers.
Software engineering is a core part of platform engineering, because you need to be able to write meaningful software in order to manage complexity. “Beyond automation and beyond operations — both of which are extremely important — you want to be willing to build new software products,” Fournier said. “You want to be willing to build self-service interfaces and enhanced APIs and security and quality guardrails, but you need software engineers on these teams if you’re going to really be able to create the kind of complexity reduction that matters.”
On the other hand, if your platform team is only software engineers, that introduces a whole other set of problems. Software engineers may not want to think about operations. They want to build frameworks, they want to build a library, they want to build a blueprint, she explained.
“There is no lasting value if you do not have operational ownership … If you want to have a platform team that is not going to get defunded, you better be running some things that people actually depend on … You will build better software if you run it and maintain it in production. But the big cost of this is maintenance, it’s operations, it’s upgrades. You need people with these system skills.”
Not having a product approach is another mistake platform teams make, as this leads to building in features that users aren’t actually using. Platform teams need to be working with their end users to understand how they will use the platform.
“You’ve got to have that customer empathy in your platform team that actually cares about the people that are going to use this software and gets their input on what you’re building, so that you’re building something that actually meets their needs and demands, and not just what you think is right,” she said.
There are two major failure points commonly seen when building the platform, Fournier pointed out. One is that the platform team builds what they think their users need, and the opposite problem is listening too much to users and implementing every single feature they need.
“If you end up in this feature factory, you end up building these sort of Rube Goldberg architectures that themselves create the same problems that you got in the first place,” Fournier said. “Once you have a Rube Goldberg architecture, it’s hard to build something that your customers can more easily plug into and use. It’s hard to evolve. You become more and more of a bottleneck.”
According to Fournier, if you can blend software engineering skills, operational skills, and a product focus, that’s a great baseline for building out a platform organization.
Another major mistake is building a v2. What she means by this is that sometimes platform teams will find themselves in a situation where they already have a system, but they can’t really incrementally change it, so they go and build an entirely new system.
Problems arise because no matter how you think users are using your system, you can’t really know for sure. Odds are, there’s some team or individual relying on some part of it, and moving on to something else will result in reliability issues. Therefore, building a V2 is a high risk operation.
Another way in which it’s a high risk operation depends on the way your team is set up. She referred to Simon Wardley’s pioneers, settlers, and town planners concept. The pioneers are the ones doing really innovative work, who are comfortable with risk.
“They find something that might work, and then if they are successful, they are followed by people who are more like settlers who are comfortable with some ambiguity, and they like to kind of take something that’s messy and clean it up and make it a little bit more stable and scalable, and then over time you get the real town planners who want to make this system really efficient and are very comfortable in this sort of large system that has lots of different trade-offs for efficiency and progress.”
A V2 of a project is typically started by a pioneer, but platform teams are usually not made up of pioneers; successful platform teams typically consist of settlers and town planners.
Even if a platform team managed to think of a new innovative thing, there’s the issue of migrations. Fournier said there’s actually a big opportunity for platform engineering teams to figure out ways to make migrations less painful.
“If everybody in this room takes away one thing, think very hard about how you can make migrations much easier on your customers,” she said.
