Analysts build their own analyses instead of using shared data models because they need answers fast, not because they're territorial. The real fix: watch what analysts actually build, then turn their ad-hoc solutions into maintained data products instead of forcing them to wait for perfect infrastructure.
Chapters
It actually gets back to one of my favorite things that I talk about now, which is data modeling has such value. So why do analysts go rogue? Why do analysts build from scratch? And I think there was a long time where I was like, guys, work with us, help us build this data model. I'm like, why won't these guys work with us? Why don't they want to, like, I felt, I'm like, is it territorial? Why don't they want to divide and conquer? We'll build the model, then you just build the viz. And then I realized it was a timing thing. Analysts are under the gun to get insights yesterday, and we cannot build a model in a day. That's just not good engineering. And so if you get frustrated by that tension and you try to just constantly force resolution, adoption's gonna be limited. So now I'm much more passionate about how do we create sandboxes for analysts? How do we observe what they're doing? And then say, hey, this thing, you're using it a lot, but Todd goes on vacation and this breaks, there is no one who owns maintaining it. So what if the analytics engineers shift this left, you refactor your last mile, and now that's a data product? And they're like, when I explain that to analysts, like, we're not going to shame you for going ahead. I talk about them as being the scouts who are going out and finding the problems. They're closest to the problems, but that doesn't mean modeling doesn't have value. We can't just always be scouts and always building from scratch.
