Any tips on ensuring smooth functioning between Analytics teams and Platform/Engineering teams so that analytics team don't get stuck in the middle?

Teams I have coached have taken a few different approaches. Some have treated the data platform as a product. So they create a Data Platform Owner role who engages with the different Analytics teams early to see whats on their roadmap and then works to prioritise what data platform features need to be delivered so the Analytics team can use it. The Platform/Engineering teams treat the Analytics Teams as their customers. Another approach is to collocate a platform/engineer skilled person in each Analytics squad. They build out initial platform features as they are reqiured. Those features are then iterated on in the future as they are reqiured by other Analytics Squads. I have seen wokred with teams where the iteration was done by a dedicated platform squad, but also where it was iterated by the next Analytics squad that needed that feature. Let me knwo if you want any more details on any of these approaches.

Highly recommend Avo (Avo.app). The platform was built with a git-branch type workflow to remove the bottlenecks that stem from less technical teams (product, marketing, etc.) relying on analytics teams to design and communicate what's needed from engineering to measure certain KPIs/metrics. These requirements are usually crafted in a spreadsheet, doc, github, etc. and very few teams know how to contribute, so the dependence on analysts gets them stuck in the middle -- and their time is much better spent elsewhere.

Analytics teams need room to explore and experiment, and the Platform/Eng teams need good requirements for building new analytical assets. The one I see most common is: 1) someone analyst uncovers a new way to analyze something 2) business gets good insight, love it. wants more of it. 3) platform/eng gets asked to support "in prod" 4) it takes foreverrrrrrrr Everyone loves to poke fun at step 4 and how it "always takes forever" but the truth is, there is a giant chasm of communication between these two groups. If Enginneers ask the analyst for their "code" to reproduce it, it often is in a different language and probably not even built cleanly off the existing Warehouse. So, the Engineer is in uncomfortable territory figuring it out. And maybe the definition of some underlying metric isn't even correct, and the analysts learn to just accept the data and then create their own adjustments for it.Rasgo is a free product that was built with this in mind. The analysts can either use python or a web interface to point-and-click their way through transforming data directly from the DW tables. They can do this quickly for insights and analysis. If they want to ship something to the engineers, all the steps are compiled behind the scenes directly into SQL or dbt models that the Engineers can pick up and hit the ground running. I work there and we're looking for feedback, so I would be happy to hear from you if you check it out or have questions.