3 ms·

I don't really understand the practical value of internalizing Conway's Law. Presumably you are designing your engineering organization to be as productive and

I don't really understand the practical value of internalizing Conway's Law. Presumably you are designing your engineering organization to be as productive and efficient as possible? If your product reflects your org structure, why does that matter? Put bluntly, does Conway's Law give me anything actionable to consider when I'm building an engineering org?

zug_zug 3y ago
I thought the article kinds of explains it already -- silod teams will then create silo'd features (that won't play together well, won't look consistent, won't feel consistent). Thus to create a truly integrated product you need have cross-team organizational communication structures.
AgentOrange1234 3y ago
This is the key question for me too. TFA gives some hints, like, - can we use this to empower a team to really focus on a key component, removing other concerns from them? - how do we ensure consistent quality across the user experience, if different teams own different parts? But I don’t yet have a clear thesis, or even a collection of key tradeoffs to consider when thinking about how the org design will impact the product.
kuchenbecker 3y ago
A decision that will need to be made is how projects are run. An engineering-driven org might be broken up along systems. However, cross-cutting projects will suffer a communication barrier. You could instead align teams around initiatives rather than systems to execute, but then tech debt will increase in those systems as people forget their original intended purposes in favor if getting the project done.
ninkendo 3y ago
> Put bluntly, does Conway's Law give me anything actionable to consider when I'm building an engineering org? Because your architecture will match your communications structure, it means that if you want your system to work a certain way, you’ll want to make your org chart match it. If the system architecture is the thing you want, and the org chart is what you can control, it follows that you should mold your organization to match your desired architecture. Conway’s law is a law, not an anti-pattern. Resisting it is a bad idea, instead learn and understand it, and plan around it.

zug_zug 3y ago

I thought the article kinds of explains it already -- silod teams will then create silo'd features (that won't play together well, won't look consistent, won't feel consistent). Thus to create a truly integrated product you need have cross-team organizational communication structures.

AgentOrange1234 3y ago

This is the key question for me too. TFA gives some hints, like, - can we use this to empower a team to really focus on a key component, removing other concerns from them? - how do we ensure consistent quality across the user experience, if different teams own different parts? But I don’t yet have a clear thesis, or even a collection of key tradeoffs to consider when thinking about how the org design will impact the product.

kuchenbecker 3y ago

A decision that will need to be made is how projects are run. An engineering-driven org might be broken up along systems. However, cross-cutting projects will suffer a communication barrier. You could instead align teams around initiatives rather than systems to execute, but then tech debt will increase in those systems as people forget their original intended purposes in favor if getting the project done.

ninkendo 3y ago

> Put bluntly, does Conway's Law give me anything actionable to consider when I'm building an engineering org? Because your architecture will match your communications structure, it means that if you want your system to work a certain way, you’ll want to make your org chart match it. If the system architecture is the thing you want, and the org chart is what you can control, it follows that you should mold your organization to match your desired architecture. Conway’s law is a law, not an anti-pattern. Resisting it is a bad idea, instead learn and understand it, and plan around it.