Hacker News Reader

Having just read this and Zhamak's article, it seems that there may be some incentive alignment issue with this.

I assume a lot of valuable data originate from customer-facing applications, so the team that already has a customer-facing product now has to manage a new internal-facing data product.

My worry is that the data product won't get the love it deserves.

View on HN

This is "solved" (at least to some degree) by adding additional resources to the domain teams - data engineers get embedded and/or added to domain teams to become the data product developers in most implementations. Hard agree that you cannot give a team significantly more responsibilities without more resources to help handle them.

Is this done in an incremental way? Changing the org from the central-data-team-as-bottleneck to this is a huge step. Just thinking of all the buy-in you need makes me dizzy. Everyone seems to want direct access to the data, but are they willing to do the effort of taking responsibility for it as well?

I'd love to see how a smooth transition to this goes :)

I’d worry that the extra headcount will just get sucked into operational priorities.

The payroll engineers are always going to prioritise fixing payroll problems over supplying data scientists. More engineers could easily just end up being used fixing the backlog.

Reply on news.ycombinator.com