> Aka don't fall prey to Conway's law

You can't not fall prey to Conway's law. You can only choose how you organize your people and their interfaces.

You can't do either. How a system is structured drives how the organization running it is structured; how an organization running a system is structured drives how the system is structured.

This is natural and even beneficial: it reduces communication and coordination costs, which is the costliest and hardest part of any organization or system. Perhaps that sometimes lands you in a suboptimal local minimum, but escaping that is usually quite costly in the short term. Think about how often top-down reorgs actually generate value.

Right! Decide on the shape of the software, then rearrange your organization to match.

This is probably good advice for CTOs and directors who manage software products, but it seems to imply the rest of us have to make software that already matches the political structure.

Try building software that doesn’t match the political structure. I guarantee you will regret it.

You’ll constantly be dealing with all the problems because nobody else will care.

Sounds like a way to spend a lot of your time doing “cross functional work.”

I never thought about that as a euphemism for "you're doing it wrong." Makes me rethink my priorities...

It’s not, and it can be very useful to the org. But I find it a huge pain in the ass.

Another way of saying that is to be strategic about where you go against the grain of the organization. I’ve seen that work well when it was something important where the value was high and poorly when someone was either just being dogmatic or overestimated their ability to negotiate.

A long time ago I remember hearing a good bit of advice that for a new project you should innovate the product or the tech stack but not both. I think this is similar: unless you have a lot of resources (people + political clout), don’t buck the existing org chart in more than one area if you can avoid it.

Org will be orgs… and I find it hard to disagree with you :(

The only counterexample to Conway that I have seen working is “away teams”:

https://pedrodelgallego.github.io/blog/amazon/operating-mode...

Conway's Law and Murphy's Law. They'll get you every time.

(Some of) Werner's advice in his own words (from the linked article):

* "I always urge builders to consider the evolution of their systems over time and make sure the foundation is such that you can change and expand them with the minimum number of dependencies."

* "There are few one-way doors. Evaluating your systems regularly is as important, if not more so, than building them in the first place."

> Evaluating your systems regularly is as important, if not more so, than building them in the first place.

This is useful advice to people who can make high level org decisions. But they don’t necessarily know what’s going on at a software level.

The people who do know what’s going on often have a very hard time getting buy in for refactoring. Many of them (rightfully) conclude it’s better to just make management happy churning out features.