[headwind]

Right, why wouldn't it be best to let the business logic live with the business teams?

I agree with team ownership. Unfortunately, teams and their ownership domains are organized in odd ways due to business needs.

However, that suggests to me that there's more reason to house the "ground truth" with the team that owns the ground truth.

If 3 teams each own different features, they'll each write their own business logic.

[proc0]

I would say there are different "ground truths". For engineers, this is computer science theory, and for business, it's what makes sense from a market perspective and what's best for the customers. This is why having engineers worry about customer needs is a huge mistake, at least in my opinion, because it takes away from engineers focusing on what they do best.

The solution could be something like creating two distinct domains, and then bridging the gap. You would have the engineering domain, in which abstractions follow information theory, and then you would have the business domain, which follows whatever the business wants. Then you would need some kind of bridge, whether it's teams or roles in each team, that translate and mediate back and forth. This way the business can ask for XYZ feature, the bridge teams or roles would then consult with engineers how to break these up, and then engineers would implement it. Additionally, engineers would have complete ownership over their domain.

I think the reason it doesn't work that way, is because the business side wants complete transparency over engineers, which constrains them for no reason. I also think these constrains are impacting the business value in the long run because software isn't being used to its full potential.