kislayverma

Just fixed it. Sorry for that!

>It sounds like the teams they ended up with just weren't cross-functional teams.

You are exactly right! And yet everyone thought they were organized by functions/objectives/OKRs or whatever. The blind spot is what I want to highlight here.

"Data-Delivery" is an anonymization. The team shipped a specific data set that I did not want to name.

That is well put, and I'm going steal some of those words in the follow-up I'm writing. I essentially feel that teams should grow when tech and process initiatives have led to creation of a whole new problem space that can be explored independently.

Consciously applying Conway's to identify communication boundaries sounds like a good way to get there.

That is correct. Wen I am wrote about "communication overhead" I meant having to talk to other teams to get the work done. Talking within the team (including PM, stakeholders etc.) is, IMO, desirable to set the overall team vision and to keep everyone on the same page.

I feel that once two teams, no matter how closely related, get the feeling of two different "mandates" (often personified by two managers, sometimes not), it becomes very expensive to keep them aligned. It is probably faster(wrt achieving the end goal) to go with fewer people in one team.

I agree. Looking at the "final practices" of a well-oiled team and just picking them up without any of the context about "why" they work "for that team" is half the reason no good idea (Agile, microservices, Jira) stays that way in software industry.

I'm still writing it :)