Systems as Mirrors

Summary

There’s something quietly unsettling about Conway’s Law. Most people who’ve worked in software long enough can sense its truth. What unsettles is what it reveals when you sit with it.The law definition, in its original form, is:Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.— Melvin E. Conway, How Do Committees Invent?At first, it seems structural. Org charts become system diagrams. Split your teams by department, and the system splits the same way. But over time, the reflection deepens. The system doesn’t only mirror who talks to whom — it starts echoing what’s understood, and what’s avoided.The most confusing systems I’ve seen don’t reflect complexity. They reflect ambiguity.You see it in familiar places. One service checks a user’s admin flag. Another checks something else entirely. A third overrides both. A field like “approved” means one thing to scoring, another to compliance, and something looser to product. The code bends around uncertainty. But what it adapts to isn’t complexity — it’s a missing decision.This gets worse when teams try to support everything. A lending flow starts with a clean path. Then you add freelancers, students, returning users. You don’t create new flows. You add flags: hasPayslip, isStudent, incomeSource. Logic branches. Models fork. Scenarios pile up.Each rule makes sense in isolation. But together, they blur the center. “ApplicationApproved” starts meaning different things depending on the path taken. Eventually, no one can say what it means — only how it behaves under certain conditions.The system still works. But its meaning doesn’t.This is where outcome-driven modeling helps. Jobs To Be Done is one approach. It shifts the focus from who the user is to what they’re trying to accomplish. It asks what outcome they’re hiring the system to deliver — and what tradeoffs they’re willing to make.A persona tells you...