blog.silas.nyc

Organization-Architecture Alignment

May 15th, 2023

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.
The Fact Cloud Model

May 15th, 2023

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.
Inclusive Management for ADD/ADHD Team Members

May 15th, 2023

Introduction

This article endeavors to help managers and process planners accommodate neurodiverse team members, especially those with ADD/ADHD. I’ll start by explaining a few ways that neurotypical and this type of neurodivergent cognition differs. Then I will draw some guidelines informed by those differences that can help you design a process that gets the most from your neurodiverse team members, as well as make them and everyone else in the team happier, more cohesive, and more productive as a result.

The differences that we’ll cover derive from fundamental, observable, largely immutable structural and chemical differences in the brains of people with ADD/ADHD versus those of people who are neurotypical. While there are compensatory strategies to help cope with the effects, no amount of training and practice can eliminate the differences. What’s more, those compensatory strategies have real costs; for the neurodiverse individual, acting “normal”, if even possible, will always take additional effort and energy that a neurotypical individual would not have to expend. It can be useful to think of ADD/ADHD not as a general inability to focus, but rather an impediment to the control of when attention is given and what it is focused upon.

One way to think of it is that things that are autonomic functions for a neurotypical individual are conscious acts for a neurodivergent one. Another way to think of it is in terms of disability. A person who uses a wheelchair will not be able to perform to the same level as a person who can stand if forced to work in an environment that requires frequent reference to materials stored on a shelf 5 feet above their desk, no matter how many assistive tools and how much training they have to access that shelf. Similarly, a neurodiverse individual will not perform to the level of a neurotypical person in an environment that is hostile to their neurology, no matter the compensatory skills and practices they have developed. You can’t just “train away” the differences.

Common Symptoms of ADD/ADHD

Attention

Let’s start with the “obvious” one. People with ADD/ADHD, as the name suggests, have a hard time maintaining attention, or focus. Research suggests this has to do with differences in how the neurochemical systems that reinforce focus function. People with this trait literally cannot focus the same way neurotypical people can.

The framing of autonomic versus conscious is useful here. For the neurodivergent person, staying “on task,” requires constant conscious effort. To illustrate this, consider the experience of your brain wandering. This phenomenon can start at any time, and to maintain focus, must be curtailed. This vetting process of assessing applicability is done by some combination of subconscious and conscious thought; for neurotypical people, it is much more subconscious, almost autonomic, whereas for the neurodivergent individual, it is a much more conscious effort.

This conscious effort is, in and of itself, more mentally taxing than the autonomic alternative, but there is another piece as well. When a thought is wandered into, so to speak, if the vetting process is conscious, it means whatever thought was already there has to be set aside so the vetting can happen. This is effectively a task switch, and task switching is additionally expensive.

As a result of these factors, somewhat paradoxically, it can often actually be harder for a neurodiverse person to stay on task for a narrowly defined task than for a larger, more broadly scoped task. The narrow task requires much more of this task switching to vetting mode, whereas the broader task allows more room for wanderings to be relevant, so that the vetting process can be allowed to be less active, and thus less interruptive.

Memory

Next, people with ADD/ADHD tend to have more memory problems than the neurotypical community. These people can often present as absent minded. What this means is that processes and procedures based around memorization and repetition are going to play into the weaknesses of the neurodiverse individual.

One compensatory strategy that can often help affected people is to leverage patterns and broader rules to stand in for collections of facts. As an example, think of learning multiplication. Memorizing multiplication tables can work to allow a person to perform operations, but if you develop a rule, like, “given x*y, add x to itself y times,” you’ve made it possible to replace dozens of individual facts with a single rule in your memory. For someone who has trouble remembering large quantities of facts, this reduction process can be extremely helpful.

A side effect of this preference toward pattern and rule use is that recall can sometimes be slower. Recall of a memorized fact uses different pathways in the brain than does application of a rule. This is demonstrated in studies, but also just in everyday experience; it’s faster to remember something than to work through a process. The counter to this slower recall is often building complex patterns of patterns, so that rather than recalling a string of facts, a single, faster, process can be applied, but this does require that complex pattern to be built first (and maintained).

Hyperfocus

The last symptom we’re going to touch on is hyperfocus. Depending on what expert you listen to, hyperfocus is either the same as or related to flow, the hyper-productive state where the world sort of falls away and a person is totally absorbed in the task at hand.

This can be leveraged to great benefit in a professional setting, but the thing to keep in mind is that interrupts break hyperfocus, and that conscious vetting process we touched on before is an interrupt. The more interrupts are inherent in the process, the less opportunity there is to leverage hyperfocus.

In addition to the interrupt issue, that lack of control of when and what is focused upon is particularly relevant in the context of hyperfocus. A neurodiverse individual cannot really control when or about what a period of hyperfocus occurs. Rather, they try to “ride the wave” when a productively directed period of hyperfocus kicks in, and practice mindfulness to catch and stop diversionary hyperfocus.

Application

Ok, we’ve explored some symptoms and their impacts, but now let’s talk about how these learnings can be applied to maximize the contributions and satisfaction of your neurodiverse team members. First, let’s think about task creation. Try to find ways to orient tasks around subject areas and functional components within the application and codebase, rather than product verticals through multiple systems. This will allow that pattern-based approach to be leveraged, helping to compensate for memory problems and provide fertile ground for productive hyperfocus periods to occur. This will help your neurodiverse employees thrive, but also can refocus people generally to spend more time in a single problem, letting them produce better, more well-considered solutions.

Next, consider planning and assignment. Focus on scheduling and assigning tasks across multiple features, by what is being touched in each task, rather than clumping by product feature and smearing code area across time. This builds on and reinforces the strengths arising from the approach taken to task creation.

Finally, consider delivery. Try to allow more flexibility for delivering tickets in batches than in strict sequence. For a neurodiverse team member, each context switch, from development to testing to merge request and code review, involves costly interrupts. The more those context switches can be batched, the less break in flow they will experience, and the more productive they can be.

Organization-Architecture Alignment

The Fact Cloud Model

Inclusive Management for ADD/ADHD Team Members