This message was deleted.

Great question. In my opinion, it's about relationships and communication. If you know someone personally, you can more easily emphasize with them and view their needs and problems in a charitable light. Off-sites or team bonding exercises might help here. Leaders from both teams have to set an example of collaboration and compromise for others to follow.

Yes, I think we have to encourage the leadership to build relationships.

Some of the things that can bring a level of predictability and, in return stability • Small and frequent incremental production deployments and the ability to rollback if there is a problem • Using feature flags(like LaunchDarkly) to turn on/off features. C code can be deployed to production, but features are incrementally turned on or off. • Automation testing with solid code coverage • Some companies like Netflix have deployment approaches like Red/Black(also called Blue/Green) or canary deployments • Good logging, monitoring, and alerting will also help to fix issues if they occur. • From a rollout, a good approach is to pilot first with a small set of users before GA

Two things come to mind: 1. The traditional dimensions of delivery are time, scope and quality. Product managers are entirely responsible for scope. Constraints typically set time (contractual or budgetary) and quality is almost entirely in the hands of engineering. That's the conversation to have with PMs. What would the customer experience be if we delivered an unstable product? What would their experience be if six months later they found out their data was stolen? Time, scope and quality are not binary. It's a multi variable optimization process that has to happen between product and engineering. 2. It helps to prioritize a roadmap together. My colleague @Pavel Brodsky and I will share a detailed way we've been using to set our platforms roadmap at the next PlatformCon this June. Stay tuned for that :)

Hey Olga! That sounds wild! --- What I wanted to write first --- PMs should normally be very inclined to listen to their customers, understand their problems and prioritize along their needs. If the PMs and their customers are totally out of sync, then this is a major red flag. --- Thought process triggered - did I actually read your request? did I actually understand it? --- I wonder who the involved parties are. So PMs are now part of the platform. Great - platform as a product is a pattern that is proven to work! There is friction between platform and engineering. Now the tricky part: Engineering favors stability and security. Product sets ambitious goals for customer experience. Who is product? Is this the PMs or the “business folks” that drive the requirements for the engineering? If it is the PMs, then back to “What I wanted to write first”. If this is business folks driving engineering, then it’s more tricky and also Gobiraj and Nadav have already written some very good suggestions!

@Gobiraj Vadivelrajan +++++ Love the concept and practice of "speed is safety."

Have more beers together.

@Olga Sermon when you say introduced PMs to platform do you mean a PM for the platform team, or product PMs are now interfacing with platform teams? that will help me provide some advice 🙂

I mean PM for the platform team

i’d encourage this PM to talk to their customers eg the engineers. until they don’t hear the problems first hand, they won’t empathize with them nor understand what the platform engineering team is trying to do 🙂 happy to talk to whoever it is! stability and security are true customer facing as well - if the product isn’t stable nor secure, then that results in external customer issues

What also helps PMs and engineering work without friction is planning the roadmap together. To get all the stakeholders together while doing the vision and the roadmap for the product. Since products set ambitious goals, its the engineering that can tell you if the engg. team can precisely estimate if that goal can be achieved in stipulated time frame because they can tell if the current tech-debt is manageable or needs some refactoring before starting with new features. This informs the PM and helps them promise their customers what is more realistic. Also, an unreliable or flaky product won’t do any good to the users, so its always better to work on smaller iterations and PMs need to understand to ship a small yet reliable and secure feature rather than a faulty one that churns users. Setting reliability scores from the start like Service level objectives can help PMs and engg. team align on the reliability of the products.