This message was deleted.

Well I agree ... The IDP is its own product within a company, and the same things that apply for a "regular product" should apply here as well. The only difference is that your end customers are actually your coworkers 😄

💯 As discussed with @Lorne yesterday, even some companies (that we work with) apply a budget to each team - so they can spend virtual money to afford service from the platform. So, even if they are technically your co-workers, they are managed as customers. I love this approach because it forces you as a platform team to really deliver the promise and be proficient in communication and product building

I can just agreed on that

Platform Engineers must be obsessed with developer experience

I kinda feel like these two are becoming the same in my mind. I find it hard to distinguish truly the difference.

Hey @Romaric Philogène, I just start with the topic so I'm not this much into it so forgive me if my question is naive. Don't you describe the "Product Owner" role? I agree that people of any proficiency work better and produce better results when they have an interest in the product themselves. I'm just curious as I perceived the degree to which you describe it with being obsessed with growing the product and the developer experience as the obsession of adding value for the user (aka developer in this case) a product owner should have. It also fits to "It's similar to building a company" which goes along with the saying the PO is the CEO of the product. Also communicate and sell (not selling like a salesman but catching people) would fit to this. So my question is: Do you think for Platform Engineers it's more crucial to be highly invested in the product than for other software engineers with end user facing products? And if, why? Or is it more like you having a high standard you demand from every technical role independent on the product (which would also be fair and good, i mean... always strive for the best right?)? Or do you have "the ONE Platform Engineer" in mind which serves as the Product Owner in the Team for the platform Platform in terms of a product. They should indeed be a Platform Engineer / DevOps / Dev themselves but it doesn't count for the whole team? The latter would be comparable with the responsibles for other developer facing products like frameworks (spring, micronaut, react, you name it) if they work with scrum / agile or any other framework that has a sole responsible and produces products.

(Related to this post -> I write something a bit longer on my personal blog: https://romaricphilogene.substack.com/p/platform-engineering-1-the-developer - I will respond to your questions later today)

For most of our technical jobs, mastering the human side is the biggest component to success. Whether it's building the right thing in platform engineering, cooperating on bigger projects or getting the correct intentions behind a infrastructure request, talking and understanding others is what will allow you to make the fastest progress. Tech choices are important, but the tech is usually the "easy" part

I agree! the way we see it at Port, the secret isn't to think about the different components of the internal developer portal, such as "I need a software catalog" (this logic also applies to any part of the platform engineer's stack), but to think about the different experiences provided to the developer (e.g. "the developer needs to interact with cloud cost data in a way that's effective and simple"). This forces a product management approach, since it puts the question of developer-jobs-to-be-done as a core concern. And of course, the next logical step is to think about adoption - and to use adoption strategies -so that the product is in use .... this can be anything from measuring use of the portal, surveying users, net promoter scores and more https://www.getport.io/blog/leveraging-product-management-strategies-for-your-developer-portal

Yes really love your write up @Lou Bichard 👏 well done

I agree with dev and ops being really close to the same jobs. I’ve worked in an environment where basically everyone had written groovy - the team I was on wrote it for Jenkins and the devs for their app (idk what part). I’d also edit maven/gradle configs, but devs had created it and devs were responsible for approving it. That said, devs sometimes got paid more and generally didn’t have the same level of access to infrastructure as ops did. We also rarely drank together or hung out with each other (which I see as a problem).

I often wonder why DevEx and Platform Engineering were split into two different categories in the first place. It makes no sense. Think about it… the primary role of a Platform Engineer is to literally make the platform exactly (or as close to) what the developer/engineer needs… that’s the definition of ensuring a proper experience.

I agree with you @Michael Levan - and that’s why I spend 90% of my time explaining that the role of a platform team is to make sure their customers/end users (developers) use what they have built. At the end of the day, it’s all about Developer Experience. If there is friction using their platform, then there is no adoption, no improvement and it’s just a fail!

I agree. But I do think it's valid to have separate terms. For the last 2 years I've been looking at DevEx with my client and I tend to use that term to mean everything from when an engineer receives their welcome letter to the company (arguably even the interview process, but we unfortunately don't control that) right through to a leaving interview when they leave the company - and everything in between. We aim to make all of that an awesome experience. A HUGE part of that nowadays is IDP to make their day to day and product initiation frictionless. But there's also a lot of other stuff like getting hardware, socials, swag, communities, learning opportuntities, PAY!, etc, etc.

It’s just too much. Too many terms. Too many different ways of explaining the same thing. All it does is cause confusion

Weirdly… when I think back to my developer experience team days, we were kinda layering on the “platform as a product” side onto an existing platform lead by folks who were very heavy on the infra/cloud side.