Your Platform Team Is Selling the Wrong Thing

Remember those LEGO catalogs from your childhood? They didn't just show you bags of random bricks, they showcased complete, beautiful designed sets arranged in inspiring scenes. Each set came with clear instructions, all necessary pieces, and the satisfying promise of building something meaningful. The same principle should apply to platform engineering, yet many platform teams are still focusing on delivering individual bricks rather than complete sets.

From Building Blocks to Platform

In the early stages of building a platform, having flexible and individual LEGO bricks makes a lot of sense. However, as platform teams learn more about what developers need, transforming these loose bricks into well made sets becomes increasingly valuable. While many platform teams rush to turn these bricks into complete sets, there is a risk of creating abstractions too early. In tunnel construction, they say:

you need to dig tunnels to dig a tunnel'

They dig exploratory vertical shafts to study the rock composition before starting with the main tunnel. A great principle that all platform teams should follow.

This means getting hands-on with development teams, watching their work, spotting their struggles, and seeing what patterns emerge. Only through this deep, hands-on exploration, platform teams can identify where meaningful abstractions are truly needed. However, success rarely comes on the first try, and that's perfectly fine, keep on digging.

Throughout all this work, simplicity remains the north star. However modern platform teams face an interesting paradox. Though the best solution often involves less code, today's platform teams need to embed themselves deeply in the application stack. This often means writing more code, not less. This enables them to fully own the problem and not just the solution.

Building Trust and Adoption

One of the biggest challenges platform teams face is earning the trust of development teams. Development teams are constrained by resources and can't afford to spend significant time on migrations without certainty of success.

What makes this transition even more challenging is that development teams know their current stack inside and out. While their existing architecture might not be perfect, they understand its quirks and know exactly how to troubleshoot when problems occur. Asking them to give up this familiarity means asking them to trust your solution completely. This trust must be earned over time.

The Extra Mile Matters

When approaching a problem, platform engineers should put themselves in the developers' shoes, considering what might make adoption challenging and how to simplify the process. The Dialog Style communication pattern shows how such an empathy view can make a huge difference.

Making things possible isn't enough! Platform engineering is about making them simple.

Part of going the extra mile also means being humble enough to learn from what already exists. Just as LEGO studies how children actually play before designing their sets, platform teams must study how developers actually work. When platform teams encounter "shadow IT" or homegrown solutions, they shouldn't dismiss them as problems to be eliminated. Instead, these solutions offer valuable insights into what developers truly need. Smart platform teams study these alternatives carefully. What pain points do they address? Why did teams choose to build or adopt them? Learning from the strengths of existing solutions, including unofficial ones, helps shape a platform that truly serves them and the company.

Marketing Why It Matters

Whether building a product or internal platform, it's easy to fall into a common trap of believing great technology will sell itself.

If we build something amazing, teams will want to use it.

This assumption couldn't be further from the truth. Even the most powerful platforms need effective marketing to drive adoption. Think about those LEGO catalogs again, they don’t just show the pieces, they show what is possible.

Successful platform teams understand that selling their solutions involves more than highlighting new features. It requires demonstrating concrete value by showing development teams what they won't have to do anymore. This means clearly articulating how the platform eliminates tedious tasks, reduces maintenance burden, and frees up time for more valuable work. However, it's equally important to emphasize what teams can continue doing. Developers want to know that adopting the platform won't force them to abandon the aspects of their work they genuinely enjoy.

The goal isn't just to showcase features, but to build confidence that the platform is the right choice today and more so tomorrow.

Conclusion

All software engineering teams want to do the right thing, but figuring it all out on their own is incredibly time-consuming. Platform engineering is about making this process significantly easier, but not by providing more LEGO bricks. Instead, a platform should provide complete LEGO Sets. While loose bricks offer flexibility when needs are uncertain, once a platform team better understands those requirements, they can deliver well-documented, ready-to-use sets that teams can trust, and most importantly, build upon.