[proc0]

The core of the problem is that engineers do not own their code. It would be like a chef not owning their food. Engineers are split into teams that the business side of the company decides arbitrarily... and because non-technical leaders are not as familiar or knowledgeable about computer science, they create incorrect abstractions that constrain the solutioning for no reason.

Imagine an app where you have feature A, B, C, where A and B are basically the same feature with a few differences, and feature C is completely different. The business side of the company might decide to create three teams, one for feature A, one for features B + C, and another for features A + C. The engineers in each of these teams are immediately setup to create complexity in the long run because the correct abstraction would be A+B and then C.

[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.

[moomoo11]

That chef analogy doesn’t work.

In any high end restaurant the menu is determined and then there’s a hierarchy of people who “implement” whatever dish.

The engineers are the line people. They’re not setting vision and they’re not doing anything beyond shipping code which is arguably like 10% of running a business, even if it’s a “tech business”.

[proc0]

Sure, you're just adding resolution to the example. If restaurants worked like many software companies, the chefs and cooks are still cooking and dealing with the food, but also running the food, taking the order, and cleaning the kitchen, while the owners decide on the menu and who gets to cook what food.