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.

This post serves as the underpinning for a number of other posts that are or will be on my blog.

Intro

This article will introduce a model for how to conceptualize the process of understanding a system.  The system models a subject area as a cloud of connected points, where each point is a fact, and each connection represents a relationship between those facts.  This system of modeling can be used as a basis for developing concrete expressions of cognition.

Consider the Sandwich

As a means of illustrating this modeling system, let’s look at applying it to the making of sandwiches.  We’ll start with a single sandwich.

The box above represents the fact that a pastrami sandwich is an identifiable entity.  This is a fact that a person can learn, nothing more, nothing less.  Knowing this fact implies no other knowledge though, so let’s add some more facts.

We’ve added some more facts to the map here.  The sandwich is made of other things.  Note that the components are separate things from the fact that the sandwich is made of them.  You can know that both brown mustard and pastrami sandwiches exist, but not that the sandwiches are made with mustard.

Also, note that the relationship is directional.  It’s the same fact conceptually, but depending on which direction it is approached from, it looks like a different fact.  This implies another fact we can add.

Something can be a composite object, meaning it is composed of other things.  All our ingredients are also composite objects, though (mostly for readability) the implied Made of/Ingredient in nodes for all those ingredients are not included.  However, this illustrates an important point.  You can know that a pastrami sandwich is a composite object, and that all the ingredients are also composite objects, and even that the sandwich is made of all the ingredients, but still not know that the sandwich being a composite object infers that it is made of things.  This inference is key to extrapolating additional meaning from the links between Composite Object and each ingredient.

The Secret (of the) Sauce

Let’s zoom in on the brown mustard.  While the actual implementation of the sandwich is explicitly and exclusively brown mustard, that doesn’t mean that that is the interpretation fixed in the minds of the people learning this fact map.  One person may recall it as “yellow sauce”, another just “mustard”, and the guy who hasn’t had to make a pastrami sandwich in 18 months may just remember “there’s a sauce or something here.”  While these are all valid recollections of the core fact, they, and their differences, are important for understanding the complexity involved in having multiple people work on this single sandwich domain.

The “yellow sauce” person might think that lemon pepper dressing is a valid option, the “mustard” person would think that yellow mustard qualifies, and the “maybe sauce” guy could think that he might have misremembered and it’s supposed to be cucumbers, not a sauce at all.  In isolation, all these different interpretations could be accounted and adjusted for, but if these people are coordinating on making sandwiches, it could lead to thoroughly unpleasant food, or an incorrect order being placed with their supplier.  Visually, we can represent this in our model as a cloud of interpretations connected to the actual fact, creating a cloud of understanding around the given fact.

Another point to call out here is that these understanding points shift over time.  There’s an implied statement above in that the “maybe sauce” guy used to know more detail, but as his distance from the topic grew  and focus shifted in his role, his memory got fuzzy and faded.  Assume he spent the last 18 months prepping veggies, so his focus has shifted from sandwiches, and that’s why he’s putting cucumbers on the sandwich now when he’s pressed into service on the sandwich line.

Now we can start to see this cognition model incorporates a number of things about team and time dynamics, not just purely the pure facts.  From this, we can start to derive a quantifiable measure of complexity of a system in context of the organization that works on it.  This measure can be used to evaluate the cost of different organizational, process, and architectural changes on the complexity of making changes to the system.

Moving Toward Measurement

Let’s step back from the sandwiches now and generalize.  Consider any system modeled as a cloud of facts, with each fact in turn modeled as a volume enclosed by the points of understanding of the team members that directly interact with that fact, with each team member being plotted as a new dimension.  That then makes a starting point for a formula for the complexity of any given fact:

c*d^(1+(mp))

c = base complexity of the fact

d = average distance of the points of understanding for a given fact

m = a constant, to be determined by experiment, which at least in part represents the likelihood that a team member will need to talk to another team member to make progress on a given change for that fact

p = the number of people who work directly with the given fact

The complexity of the system, or any slice of it, is then the sum of the volumes of all the fact bubbles for all facts within the system or slice.  One important take away is that the impact of team size on change complexity is exponential.  This is a trap that many organizations fall into, because when a team is small, c overwhelms the other parts of the formula.  However, teams hit an inflection point with both d and p, where the solutions to complexity that have worked in the past no longer do, and in some cases are actively counterproductive.  I will expand on the implications of this and more in future posts.