This message was deleted.

For me currently I think there is not enough guidance on what success looks like for Platform PM and how a good career path would look like. Compared to other customer facing PM roles this seems to have less visibility and impact is not that tangible to business, hence the need for many proxy metrics sometimes.

We do 2 things, 1. Build 2. Get it Adopted Getting it adopting it where value lies aka outcome. I have seen leaders questioning KRs that focuses on adoption facepalm Another challenge is that Platform PMs dont do enough to talk about their work, so that hinders visibility and growth aspect. Sometimes leaders (without eng backgrounds) are not interested to hear all that API stuff. So the question to ask to these leaders and ourselves is: If a tree falls in a forest, and there’s no one around to hear it, does it make a sound?

I fully agree with the the 2 key challenges/things to focus on, and I would add "create a platform experience that your users love". In some cases adoption may be helped by top-down decisions (eg. in an enterprise setting), and yet as PM you should make sure that people actually enjoy using your service.

Not the biggest challenge but one of the challenges: Roadmapping and communication the value in simple words, so that management, engineers etc understands what the platform team is doing

Engineers normally understand - I struggle the most with management communication („oh, yet another DevOps project we don’t understand”)

It always comes down to communication. The issues I always see are different stakeholders not speaking the same language. i.e People building platforms for their own needs, and not properly understanding what their users actually want or need. Or they’re just simply not able to communicate the value or reasoning behind the platform in language their users will understand or care about. Not to mention, the gap between being able to communicate to leaders - this is why the platform matters, and what it will do. The things your engineers are likely to be excited about will be completely different to what your leadership care about. Take for example, the push for UIs - leadership often love the visualisation, and the “efficiency” but most developers I know want to just work in code, and not click on boxes in an interface. So you end up building something that excites leadership, and ends up with barely any adoption since your devs just want to write code for everything.

@Luca Galante This hits hard 🧠 "_People building platforms for their own needs, and not properly understanding what their users actually want or need._"

Cv- driven design :)

For me one of the biggest challenges is how to get my full team as enthusiastic as I am. They have so much on their plate as a Platform Team, and that makes it tough to create focus and keep momentum on creating an IDP.

Feel you there @Erik Leonard. Just watched an issue unfold this week where despite the initial excitement, once the going got tough, it became harder and harder to allocate the time and resources need. It’s why the MVP process is so important. Start small, prove value, convince your stakeholders and then expand out piece by piece. Otherwise, you’ll take so long to get results, that it’s hard to keep the momentum and excitement going

as a leader, you also need to be a cheerleader for these initiatives so you can keep the momentum going. leading via conviction is hard for many folks, especially in traditional platform / infra folks where being in the spotlight hasn’t been seen as a positive but it’s the right leadership style to model and leverage with this space

@John Tosas upvote

The conviction angle is super key @Jordan Chernev. The challenge there though comes from who is pushing the initiative. Platform engineering touches so many stakeholders, and it’s rare that all are aligned from the get go on what the goals are, and even what the possibilities are (or even aligned at all). You might have full conviction as a head of platform but if all your devs think it’s a waste of time - or worst case, your senior leadership aren’t aligned at all, and don’t see it as a strategic priority…

you don’t have to convince everyone from the get-go either. usually, there are two camps that emerge during the early stages. those who are super excited and want to be on the platform for a variety of reasons and those who are skeptics and need to see more / be convinced more into the value add. those are different audiences to approach at different parts of the platform lifecycle.

i think it can be sort of tempting for us engineers to assume what's wanted/needed, develop to our vision, and expect that it gets adopted. but platform engineering very much requires that product-oriented thinking that many of us have to actively shift our mindset to accommodate. we've always served developers but now we're really serving them a product which needs management and buy in. the understanding of what a platform team does needs to be way more understood outside the team than our simpler devops processes ever were. i feel like its not just communication/collaboration that's key, but also our own relationship with the work and how we serve it to our stakeholders/community/developers - less green-field, more brown-field; submitting to the reality of what's actually needed from us. more soft skills needed than i thought i would ever have to cultivate but it's great to really have an impact and see the platform actually serve the team!

daphne, agreed. similar to a successful SRE program, the platform engineering journey is cultural mindset / evolution first, technical second

you don’t have to convince everyone from the get-go either. usually, there are two camps

always happy to get an early adopter, but success is when you get acceptance from the skeptics 🙂

similar to a SRE program, the right set of product and technical leaders will be influencing the entire technology, and as a consequence, the business

100% agree @Jordan Chernev. Why I push the MVP idea so hard. Better to demonstrate value with a simpler use case first, and the expand out as you can. Otherwise, too often you end up losing momentum before you’re barely able to get anything done before you’ve proven proper value. MVP also makes a preliminary timeline short enough that throwing a Gartner or Thoughtworks report at leadership can give you the time you need😄

> always happy to get an early adopter, but success is when you get acceptance from the skeptics agreed. this is why early wins that showcase value add to business outcomes is important. the right set of support wheels to help with this transition is to generate a set of business case style artifacts that can help people considering using the platform make that jump. ditto, internal business side stakeholders who talk to each other about decreasing their time to market / GTM. if there is a document or talks that help them see the value add of their product teams using the platform, you are winning on behalf of everyone

Agree 100% @Daphne Rickards on culture first. And i don’t disagree that conviction is key @Jordan Chernev. If you aren’t convinced by it and aren’t a believer, how are you going to convince anyone else to make the push towards platform engineering.

other tactics to try are: using current users of the product platform to talk about their wins / successes by using it. think voice of the customer. a message from a customer is a lot more influential than the best propaganda we can generate and deliver on as priests

Nice one. Thanx Jordan

i suppose the lead by conviction did come out on display in this thread a bit too 😉

Would sure make a great PlatformCon talk @Jordan Chernev. We’ve had some great submissions but the best talks are always from actual leaders / practitioners sharing their learnings from real experience

agreed. i have a few ones i can share but due to timing, they won’t be a good fit for this year’s instance. count me in for the year after of whenever the next one is

we’ll get there, i pinky promise and i hate losing my fingers