Regulators

This diagram from Ashby’s An Introduction to Cybernetics has been on my mind a lot lately.

Small models in cybernetics have a habit of, at first blush, presenting as completely opaque. This one, which is part of a discussion about regulators, probably does not escape that fate. But these models can also have a knack for getting more interesting the more you think about them. Or at least I often find them rewarding objects of contemplation. Here are a few notes on this one, which I find particularly good.

A disturbance, D, crashes into an existing structure, T. It is the role of the regulator, R, to keep the essential outcome, E, within an acceptable range. One everyday example might be a cold snap (D) affecting a house (T), and the wood stove (R) preserving a livable internal temperature (E). Consider, also, a wave (D) crashing onto a boat (T), where pumps (R) drain water to keep the boat afloat (E).

Put more formally, D is a set of possible disturbances, R a set of possible responses, and E a set of outcomes. T is a table assigning an outcome to every possible pairing of disturbance and response:

T(d, r) = e

Within E is a smaller set, η, containing the outcomes we consider acceptable. A regulator implements a rule f: D → R, and succeeds when

T(d, f(d)) ∈ η for every d ∈ D.

Ashby really enjoys jamming information like this into formulae. Anyway, if we rotate this configuration a little bit, we can spot a few observations that easily follow.

When planning for future disturbances, there is a difference between modifying the existing structure—for the house, adding insulation—and modifying the regulator—getting a bigger wood stove. There is also the possibility that the existing structure—a tent, perhaps—is so ill-suited to the disturbance that there is no amount of regulation that could preserve E. Lastly, there are probably some disturbances—a cold spell at zero Kelvin—that overwhelm any reasonable structure T.

We have cut a slight corner in our example above by referring to the wood stove as R. More precisely, the stove is an actuator—the effector side of R—and therefore only one part of the regulator. The linkage between the drop in temperature and the lighting of the stove is not automatic; it requires a human operator. The regulator is more accurately understood as the larger arrangement that includes a thermometer, a user capable of reading it, some knowledge of how the house responds to heat, and the stove itself. This is one way to think about the arrow from D to R: information must travel from the disturbance—or from its effects—to whatever selects the response.

It is hard for my mind not to return to the T I spend most of my time looking at: the software project. Delivering a sufficiently accurate program with a group of engineers is usefully modeled in this way. A software project can endure a cornucopia of disturbances: requirement changes; personnel churn; broken dependencies; shifts in resource allocation. These meet the project’s existing structure: some combination of technical architecture, team structure, dependency graphs, rituals, and accumulated technical debt. To keep E within its acceptable range—correctness, acceptable delivery time, appropriate cost, sufficient team morale—a large part of the tech lead’s life is spent fidgeting with R. Can we defer the work? Reduce scope? Push a deadline? Play Jenga?

Ashby is a helpful reminder that it is good to keep T as robust as possible: gradual investments in the core structure can help insulate E from inevitable disturbances, whether technical or organizational. He is also a reminder that sometimes E cannot be saved: it is better to cut losses if a good outcome becomes impossible given upstream changes than to run a Light Brigade charge into infinite product requirements.

But most helpfully, he clarifies the two-pronged role of the tech lead. Yes, R is important. It is useful to have a variety of techniques up your sleeve to help the team be resilient to changes in context. But it is equally important to ingest sufficient information about the disturbances to know which to choose at a point in time. In my experience, managers tend to focus on the former, treating experience as a repository of accumulated tricks. A repertoire matters, but keeping a project on track is as much a game of listening as it is of maneuvering. We neglect the D-to-R arrow at our own peril...