Microservices vs. Monolith: The Trade You're Actually Making

Part 14 of 17 · ~1 min

Conway's Law and Team Boundaries

Conway's Law is the observation that what you build ends up shaped like the way the people who build it talk to each other — groups that rarely coordinate tend to ship correspondingly disconnected pieces of software, on purpose or not. Furrow's actual service boundaries, once they existed, mapped almost exactly onto its three teams: Fulfillment owns Harvest and the packing/delivery logic, Billing owns Billing, and Farm Partnerships owns the harvest-matching service. That's not a coincidence — it's the Inverse Conway Maneuver in action, even though nobody called it that at the time: once the three teams started operating with real day-to-day independence, the software naturally wanted to be organized the same way, and fighting that by keeping everything in one shared codebase would have meant three teams constantly stepping on one shared release process.

It's also worth being direct about why Furrow actually split, because it wasn't primarily a scaling decision. Furrow at the time of the split was comfortably servable by a slightly bigger single server — the real pressure was organizational. Three teams sharing one release process meant Billing's slow, high-stakes proration fix was blocking Fulfillment's unrelated substitution-notification feature from shipping, for no reason connected to either feature's actual readiness. A five-person team working out of one codebase simply hasn't grown into that particular pain yet — which is most of the reason microservices fit an organization with several genuinely independent teams so much better than they fit a small one, regardless of how much traffic either is actually carrying.