Control is your new bottleneck
How control constrains your productivity and increases your time to market
The Theory of Control explains software development through the lens of control. People, the CEO, CMO, CTO, product managers want to control what is being built, how it is being built and when it is built by a developer - and in what order. They want to control software development in a company, they want to control the work of the developer.
To understand control in our company, we can map this out with control mapping. We draw up our process and order the process steps on the Y-axis depending on how high up the control is (team leads vs. C-Suite). The items that are mainly work, those that are mainly controlled instead of controlling, often end up at the bottom. In the example this is Developing. There is a more detailed introduction to control mapping and the Theory of Control in “Introduction to Theory of Control”. You might think, “Hey, we do work in backlog planning”. No. You create more control, tickets are control, the order is control. Control can be work in a personal sense, but isn’t work in the end-product sense (also see Muda in Lean).
If a designer designs a mock form for the developer to follow, that is control not work. If the designer draws a logo for the developer to use, that’s work.
In this simple example we can see that the control elements constraint the work. Sprint Planning constraints Developing. As can be seen, the work (Developing) then depends on the control (Sprint Planning) by which it is controlled.
Without the control, the developer would work on what they think is the right thing, work the way they think is the right way, and spend as much time as they think is needed.
Goldratt wrote a book “The Goal” about the “Theory of Constraints” (not to be confused with Theory of Control!) Writing the book as a novel, he shows and explains how production in a factory is defined by constraints, by bottlenecks.
How does the Theory of Control relate to the Theory of Constraints laid out in “The Goal” ? In the Theory of Constraints, constraining elements limit the flow of production items through the system. A bottleneck might be a special machine, or a slow machine, or some inspection. In software development this might be a designer or a DBA or QA. The direct impact is on the items and item flow. One machine, a constraint, does not limit other machines in their work, only by reducing their input or keep them waiting. Contrary to that, in the Theory of Control, control elements determine (control) other elements (work). A Sprint Planning activity determines the following Developing work element, not the items that flow through Sprint Planning, like it would in the Theory of Constraints. In the Control Theory control elements might have dependencies between each other. A Sprint Planning control element depends on an OKR Process control element, not only because it waits for the items, but also because it is controlled by the OKR Process.
When we combine these two theories, the constraints and the control, we can see how controls are constraints and act as bottlenecks.
In a small startup the developer is working on a feature, finishes it and then asks the founder (CEO), if the work is ok (control) or finished (control) and what to work on next (control). The developers work depends on the CEO for control.
The CEO is a very busy women and works on many things. She talks to customers, works with marketing, optimizes the sales process, talks to investors about the first investment seed round. She might not be available or have time to check (control) the work a developer finished or think about what the developer should build next.
She has become the bottleneck on developer productivity. The developer spends time on waiting for control. Sure, the developer can work on other things (secondary features, refactoring, gold plating, new libraries, framework migrations, Reddit), so you will never see him idle, but those other things are not as important as the primary features and are just filler for the free time.
It does not get much better if we add a product manager. The product manager can decide (control) some things, but not others. He might need to go to the CEO and ask her for input (control). One control might depend on another control, and we get a hierarchy of controls.
This becomes even more pronounced when we add more developers.
Now several developers are idle ( = working on less important things) waiting for guidance (control) from the busy CEO. More time is wasted, because more developers are not working on the most important thing, but on the second or third most important thing (XP tries to remedy the situation with an onsite customer, always being at hand, always unblocking).
Control is defined by Duration, Frequency and Scope. The longer (Duration) the CEO takes to make a decision (control), the longer the developer is idle. The smaller the tasks the developer gets, which is equivalent of letting the developer decide less things, the higher the frequency. The developer needs to ask the CEO more often for input (control) and the CEO becomes a larger bottleneck. Last not least control is defined by scope. If the CEO wants to control minute details, like the shade of the color of a button (control), the developer can decide less on his own and needs to ask the CEO again and again.
Making developers more productive leads to a paradox: With higher productivitiy bottlenecks become more pronounced and limiting. Developers get faster and faster at finishing their work. If the level of control by a product manager stays the same, then the developer is limited by that control (Discussion) fraction of work.
This is called Amdahls law and I wrote in more detail about how it impacts developer productivity. The more productive we get, the harder we are limited by control.
Control is your new bottleneck.
There are ways to limit control and adapt. Remove control meetings (Scrum has way too many for example), reduce the scope (deepness) of control and give more freedom (push decisions “down”). Reduce the frequency of control. Find ways of control like architecture guidelines, engineering culture, vision and strategy that are enabling instead of limiting. There is structured control and unstructured control (e.g. ad-hoc project status and repriorization meetings). Unstructured control means your company does not understand its control flow. Get rid of unstructured control to remove a bottleneck. Less control, less bottlenecks.