238. Conway's Law & Division of Labor

Melvin Conway noticed a curious symmetry between the shape of organizations & the technologies they created, an observation that might be invaluable for avoiding disaster.

-Links for the Curious-

Patterns of Modularization: The Dynamics of Product Architecture in Complex Systems (Brusoni & Prencipe, 2011)

[ReynaSingh]

Always great to see another video on this channel. Keep it up

[PetersonSilva]

For most of the video I was just thinking "well 90% of these problems are caused by capitalism & hierarchy more generally". But as some of these comments point out this gets into more general issues about specialisation. Great video as always!

[ineshahuja]

Love every time I get a notification for this channel. Keep it up!

[TheGemsbok]

Oddly, I've encountered this same issue of 'premature modularization' while working alone on large writing projects. My initial outline into discrete sections or 'chapters'---necessarily drawn before the vast majority of the writing or analysis has been done---inevitably crams huge swathes of final material into singular sections, while elsewhere spreading small amounts of work over multiple sections.

If I'm not vigilant about occasionally restructuring, this can lead to me rushing through important stuff or stretching out unimportant stuff. And yes, it's often at the interfaces (or transitions) between such sections that I can most easily notice this has happened. Almost makes me want to give up planning and structure, and write everything---even analytical work---linearly on a big scroll Kerouac-style. I guess that would be the equivalent of assigning an entire engineering project to a single person in the hopes of avoiding certain undesirable mirroring artifacts.

[Infantry]

I have a couple of thoughts, not refutations really though.

One thought is about software development in general. Creating a Software Architecture Specification document is important so that we can consider fall outs in advance (I work in information security, so its one I know well). In this case, compartmentalizing is sort of required. Beyond architecture, I remember being taught in school of a design document, another document generated before work actually started, that translated the architecture into specific libraries to use, classes to generate, maybe even functions to implement. Perhaps tbe reason this happens in software is that its supposed to be easier to make these adjustme ts later, when they come up. Certainly easier than changing how a factory creates some hardware, anyway. Maybe this is just something we take for granted, until something is too complex, and we end up having to completely rewrite a program, which very rarely goes well despite all the promised upsides.

I definitely see the point in having disparate responsibilities, it grows people's skills and can enable someone to jump on a problrm when it arises, rather than hunting someone down or having a meeting about how to get the thing done. I have acted in a program management capacity, kind of sort of, and it greatly benefitted me to have knowledge of the organization, different contacts, how various parts of the product worked in more or less detail. Specifically for information security, it was required that I know a little bit of everything.
On the flip side, that also meant that I was overworked. Having fewer disseminating lines between components can mean having fewer people that wear excessively many hats. The advantage of specialization that I sorely miss is having a consistent workload that i know, before I even start, what its scope and shape is. But then again, I work on a team thats constantly being pulled around due to things breaking or customer requests being escalated. I think the problems for my team are less about how we are dealing with this law, and more about how we're already in a state where lots of components aren't communicating well with each other.

Apologies for the ramble, but I'd say that's evidence of a good video, gets my mind thinking :) thanks for another interesting video!

[Macieks]

I haven't heard of the name Conway's Law but this concept always seemed very intuitive to me as it can be observed in every human technology. But that made me think if that's specific to things made by humans because of the limitation of our brains which are not able to comprehend whole systems at once. For example what if because of this limitation we are destined to never create some great invention that couldn't be broken down into simple subsystems.

That made me think of existing examples of complex systems and I thought about how the human body works. It was created by evolution, not humans but there's still division of labor, subsystems and interfaces within the human body. But still there are some aspects of the human body that can't be divided like that. For example predicting how your body will react to a certain drug is impossible right now without actual testing using medical trials because drugs interact in complex ways with many systems at the same time and it can't be broken down easily. But maybe that's not part of the "design" of the human body but rather an unexpected emergent property.

[passingthetorch]

This is kind of an example of Stone duality -- where a logical/algebraic structure is transformed into a geometric/topological structure

[landspide]

There are often three actors. The person in the middle defining the interface is often not thought of. For example the person responsible for defining the interface between a wheel and hub, or defining an api between backend and frontend. Often it is a delegated role based on which side of the interface is seen as more important (complexity, safety, etc), with that said, having a dedicated role could be seen as 'too many cooks'.

[Macieks]

Also it's funny how the word "bureaucracy" wasn't used even once in this video or the description.

[abrahamel-gothamy]

Love ur content man!!! Simple, insightful, and scholarly. Chef’s kiss 😘🤌

[d.lawrencemiller]

At the very small company I work for, there is no clear and definite division of labor on most engineering tasks. Everything is assigned on a per-project basis and we almost exclusively meet virtually and work independently. In theory, it shouldn't be a problem with a small group size. But in practice, it does take a long time to accurately communicate information because everyone in this company already has a part-time or full-time job elsewhere. We aren't always available to each other.

I think the idea that eliminating highly granular division of labor reduces cost and labor only holds under the assumption that all your loosely defined business units and the individuals that comprise them can and do frequently communicate. When work needs to be done asynchronously or without contact at all, having a clear division of labor that everyone knows in advance can be instrumental to the completion of work. When it's unclear who does what and it takes hours or days to find out, it can result in incomplete work, delayed work, or unnecessarily duplicated work.

[Xob_Driesestig]

I think this not only applies to goods, but also services. How many times have you been on the phone to try to fix a problem, only to be pinged around between different departments all claiming that your specific problem is not within their purview? Sure, some of it might be laziness, but some of it is the genuinely belief that other departments are there to solve your problem.
This is especially dangerous for social welfare programs. Here in Belgium our social welfare programs are generally pretty good once you're actually in one, but the process of being passed around and getting stuck between departments because of missing paperwork can be horrible.
I always made the analogy with science (also kinda part of the service sector) and how an interdisciplinary team is generally better at solving a mystery since they're less likely to get stuck in their branches (simplified) models and jargon. I suspect that straight up assigning a government official to a person seeking help will cause them to find the necessary help much more quickly, just like straight up assigning a team to focus on the big mystery is often better than letting each of them solve part of the mystery.
Perhaps this analogy I made between the service sector and research teams can be strengthened by Conway's law.

[bthomson]

9/11 highlighted the less than perfect interface between police and fire costing lives! There are so many, many examples of this kind of disconnect. Each group focuses on their own internal structure and can be myopic about coordination with others. How about even allies not really acting together! Sad!

[alexdemoura]

Aren't mirroring enterprises a consequence of Fordism?
And did Fordism not have a reasonable period of success?
And didn't this success affect the educational system to a point of ultra-specialization in Universities and Technical Schools?
It is obvious that the newer concepts of distributed information technologies, networks, the Internet, and data sharing have had far more impact than Taylorism.

It also seems evident that these new concepts work very well for innovation-oriented ventures - but will they work for mass production once a level of standardization of modules has been achieved?
After so long at an enormous cost across generations?
How would it be possible to change after so much time of education focused on specialization?
How would we get 4 billion adults out of their comfortable cocoons?
It is an illusion to think that so many people who have dedicated so much time to their own specialization will change their perspective to work in companies similar to Google or Apple.
Whoever sees the big picture becomes CEO - who will sanitize the toilet? Or who will supply the coffee machine?


I believe that for highly complex projects, you should have a team of no more than ten people with a very broad vision of the project. But the more complex a project is, the more the demand for expertise grows.
New enterprise concepts can work very well with small companies, with medium-sized companies dedicated to technological innovation - but it is not possible to get a JWST in space without modularity, compartmentalization, and extreme expertise - sometimes with a lot of internal confidentiality.

I don't know, I have my doubts - and I also don't know if the strong resistance to change that I encountered throughout my experience made me disappointed and disbelieving in such drastic managerial innovations. I don't believe most people want, deserve, or are ready for that kind of change.