Background

People are a big part of operating any large system. We are all used to automating repetitive tasks in our environments with scripts, but there is comparatively little to help support the people side of sustaining systems.

A great deal of work in operations comes in the form of mission critical events—major upgrades, database migrations, hardware refreshes, incident responses—activities which are complex, involve many interdependent systems, depend on people both internal and external to the team carrying them out, and which are only allowed to disrupt the underlying services minimally, if at all. These events are conducted under time pressure with incomplete information, and the consequences of getting them wrong are significant.

Doing such work well requires planning. The usual options—Word documents, wiki pages, ISO 9000 style quality binders—are either too unstructured, too hard to keep consistent, or too bureaucratic to actually be used. What is needed is a way to write down a procedure in a form that is both flexible and easy to use and clear enough that a team can coordinate their actions against it in real time.

In earlier work on this problem, procedures were described using a rigid hierarchical style. A procedure was grouped into sections; each section contained a sequence of steps carried out in order; within each step, one or more named people performed individual tasks concurrently. Progress waited on every task in the current step being complete before moving to the next.

This worked well. The consistent nomenclature meant any piece of work in a procedure could be given a fully-qualified name. "Section III, Step 2, Fozzie's Task d", for example. People on a conference bridge, in a datacenter, or working remotely could share a common sense of exactly where they were. The hierarchy defined what could happen concurrently and what had to happen in sequence, and that is the essence of the plan being followed.

The fixed four-level structure was found wanting when we tried to articulate the detail within a task, or when we needed to aggregate procedures at larger scales.

The first problem was depth. When a single person needed to carry out many small actions as part of one task, there was nowhere to put them. A fifth level was considered; detail, perhaps. But why did we need a name for this level at all?

The second problem was composition. A senior manager looking at a change event might consider there are four things to do. The engineer assigned the third of them knows that her piece alone requires eight steps of her own. Both are right. Different levels of an organization consider different magnitudes of action to be "a step". The rigid hierarchy had no way to accommodate this.

Grappling with how to represent work at different scales led to the realization that the structure of work at all such scales is the same. A step is a unit that activates, depends on zero or more children, performs a task, and durably records that it has been done. That same unit, recursively composed, is enough to describe both the four-point executive summary and the thousand-step implementation plan. The unit is scale-independent and fractal; the rigid four-level hierarchy collapses into a single recursive definition.

This is the idea behind Technique. The language is a way to write down procedures—from a short checklist to a large engineering process—using one consistent structure. Because that structure is the same at every scale, the same language describes the work of an individual, a team, and an organization.

The theoretical basis of the language is developed in the "Turtles" paper, which defines the Fundamental Unit of Procedure, analyses the complexity of procedures, and establishes a scale-independent unit to measure this complexity called the turtle, symbol p.