How should I shift my mindset when switching from a product team to a platform team?
I'm an E5 at a Big Tech company. I recently switched from a product team to platform team. This platform team was created a year ago, but got deprioritized. After a recent reorg, they resurrected this platform team with a new EM and I joined this team along with several others. Platform teams are still relatively new to this company, so people seem to have different ideas on how platform teams should work. Are there any best practices for platform teams vs. product teams?
For example:
- What are the main differences between product vs platform teams?
- What are some mindset shifts to make a successful transition from a product team to a platform team? What makes someone successful on a platform team vs a product team?
- Should platform teams always have quarterly OKRs that move metrics/have impact, even though their projects tend to be more long-term?
- How much upfront planning should platform teams do? Or is it okay to work iteratively? Is it ok to have some earlier milestones that include work that would likely be thrown away in later milestones? Or should we skip these earlier milestones and aim directly for the later ones in that case, even though that would mean it may take 2 quarters for a deliverable?
- Sometimes I feel like we're proposing a solution, then shopping it around to partner teams to see if there's any interest in adopting our platform. Is this the right approach? Or is it better to identify a specific partner team's problem and build for their specific use case, then generalize to other partner teams' needs? Or some other approach?
Discussion
(1 comment)- 32 years agoEx @Mata @Microsoft, Founder Algolab
I have been in platform teams for the majority of my career. Their time frame is usually long, and it can take one year or more to see the fruits. The work is usually initiated and driven by engineers compared to product teams where PMs will be driving mostly.
Platform teams need to think strategically about how to create an ecosystem that benefits multiple customers/partners. They need to think holistically about how the platform can be used to create value and how to encourage customers to use it. And they need to think about the long-term implications of their decisions. Once you expose an API, it is available for many different stakeholders to use, and their use cases might be totally different than what you imagined. Many assumptions you make can go down the drain and add to tech debt down the road.
Engineers have to take ownership of decisions and be willing to say no to certain requests from the partners if those requests can harm the long-term ecosystem goals.
Upfront planning is important. It depends on team to team how long they plan for. Work with TLs, managers, and partners on the vision of the team and what is required. There is no one answer. You will get better at it by thinking about it intentionally and being adaptive.
I believe it is important to identify a partner's problem and build for them, and later sell that solution to other teams.
