Have you worked on a software project that seemed pretty straightforward at the start and somehow evolved into something much more complicated than what you thought it should have been? Maybe your team inherited an application with a large and complex codebase that nobody wants to touch and everyone complains about? Have you seen user requirements that did not make much sense but somehow they were deemed to be critical and required complex technical solutions?
I think everyone who was worked delivering software has faced these challenges at some point if not on a daily basis. Quite often in companies one department blames the other for these situations, sometimes the easiest is to blame developers or a project manager, or maybe the system integration partner you have chosen, and why not ... you can also blame the technology. But how many times do we actually look at the company structure and try to understand how this could have affected the outcome?.. This is what Conway's law is about, in 1968, computer scientist Melvin Conway stated
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.
His statement, beyond being applicable to software, is a sociological observation that proposes that any system is constrained by its organization structure and will mirror the way of communicating between the different members of the organization. This is quite evident in large organizations with many teams involved to deliver a product, you could also argue that this is the reason why very small teams whose members have very well defined roles will deliver robust designs faster and while certainly very often there are technical or external reasons why projects fail to deliver the expected results, teams should also introspect and try to improve their structure and methods of communication.
I leave you with a great talk on the subject