There's a principle in software development — Conway's Law — that says organisations tend to build systems that mirror their own communication structures. It's one of those ideas that sounds academic until you see it play out in a real project.
The version we encounter most often: a business has two teams that don't communicate well with each other, and the system they built reflects exactly that. Two modules that should share data don't. A process that spans both teams requires manual handoffs because nobody thought to automate the join. The seams in the software map almost perfectly to the seams in the organisation.
We've also seen the inverse. A tight, well-communicating team builds systems that are coherent and joined up, even when they're technically complex. Not because they followed some methodology, but because the people involved were talking to each other constantly and the decisions they made reflected that.
This matters for how we approach projects. When we're scoping work, we try to understand who will use the system and how those people relate to each other. If there are silos, we want to know about them — not so we can fix the org structure, but so we can design something that works despite them, or ideally helps bridge them.
It also shapes how we structure our own process. The developers on our team talk directly to clients. Not everything goes through a project manager. That's a deliberate choice. When the person writing the code can ask a question and get an answer from the person who knows the business, the gap between what's specified and what gets built gets smaller. A lot of software problems are communication problems in disguise.
There's a version of this that applies to the client side too. The projects that go well tend to be ones where there's a single person on the client team who owns the decisions, understands the business context, and is accessible. Not a committee. Not a chain of approvals. One person who can say yes or no and explain why.