Let’s expand on the sandwich shop from the Fact Cloud post.  One shift manager decides he wants to increase efficiency and provide a mechanism for sharing and disseminating best practices.  He decides to attack this problem with automation.  He’s trying to decide between building automation oriented vertically or horizontally; does he go for a sandwich-o-matic (oddly branded application_template) or look to make a meat applicator, saucerator, and suite of other specialized tools (collectively known as core_libs for some unknowable reason).  He decides on horizontal, because obviously it’s easier to Do One Thing Well at a time and maximize functional reuse.

Everything is going along well, the shop is growing, the team is expanding.  The shift has ten employees working it now, and they all have specializations in one or two of the tools, and unofficial subteams are starting to form around those specialties.  Then one day, the store owner issues an edict, a reorg one might call it, specifying that teams are to be vertically integrated along sandwich types (he calls them lines of business), and all employees are to be maximally flexible generalists, not tool specialists, as that is agile, and he heard about how that’s a good idea when getting his MBA; the accountant also likes it, as it makes P&Ls much easier to understand.

The problem now is that you have an on the ground implementation that is optimized around horizontal specialists (meat technician, sauce ops, etc), but your organization requires that employees move from station to station to deliver a sandwich.  Now everyone has to learn multiple specialties, while simultaneously getting less in practice time with each.  In addition, the saucerator has a nozzle clean cycle (for some reason, the button for it is labeled “code review and merge”) that takes an extra 30 seconds every time the sauce setting is changed.  The old horizontally oriented workforce allowed the sauce station worker to intelligently batch sandwiches by sauce setting for efficiency, but now it’s first come first serve and requires a switch almost every time.  What’s more, adding new team members used to have a roughly linear impact on productivity, but now they see an exponentially decreasing impact of each new hire.

Let’s explore this mathematically, using the c*d^(1+mp) formula.  Under the horizontal team split, p, the number of people that worked with a given fact (meat technician, sauce slinger, etc) was kept under control, as each new person only impacted the complexity of a fraction of the existing team, rather than the entire team.  Additionally, since the system was optimized for specialization, it accommodated higher c, base complexity, values.  Switching the team orientation to be at cross purposes to the architectural organization massively increased complexity of delivery across the system.

The takeaway here is that system architecture and organizational structure cannot be considered non-overlapping magisteria.  A reorg that doesn’t take into consideration architectural conditions is going to wreak havoc on productivity, and an architecture built without an eye toward organizational structure, both current and future, is going to lead to poor throughput.