Most of us have come across Conway's Law - the observation that "organisations that design systems are constrained to produce designs which are copies of the communication structures of those organisations". From standalone web applications to open-source projects to large-scale enterprise applications, a project's success (or failure) comes down to the team that's trying to deliver it - so why do so many projects try to impose the right architecture on the wrong team structure?
Once you accept the the tendency for systems to end up reflecting the structure of the teams that build them, it becomes clear why a lot of software projects don't go according to plan. Your architect says you're going to use an API instead of direct database access - but then you sit your back-end developers right next to your DBA and give them a deadline to hit. What do you think's going to happen to your abstraction layer? Or you decide you're going to have an API team in London working with an app developer in Belarus and a web team in Ukraine, and then you wonder why your system's communication layers are causing performance problems?
In this talk, Dylan explores the idea that we should be designing our systems first, and then restructuring our teams to reflect the system design. We'll look at some common communication structures - including some things you probably do already that you never realised were communication structures - and how those structures affect the outcome of the systems they help to build. We'll discuss how you can apply common patterns to your teams as well as your code, and we'll talk about how to sell the idea to your boss before you start moving desks around.