Monday Myth: More Visibility Gives You More Control

The Architecture of Control

A modern airliner contains an extraordinary concentration of instrumentation. Airspeed, altitude, attitude, engine parameters, fuel state, weather, navigation, terrain, traffic and hundreds of system conditions continuously flow towards the cockpit. Beyond the aircraft, air traffic controllers observe movements across entire sectors of airspace, airline operations centres monitor fleets distributed across continents, and regulators collect information about incidents, maintenance and operating conditions across an industry. Few productive systems have invested more heavily in making their internal state observable.

Yet aviation reached its remarkable level of safety without concluding that whoever possesses the widest visibility should therefore control the greatest number of variables. An air traffic controller may simultaneously understand the position and trajectory of twenty aircraft better than any individual pilot, but does not select their flap settings. The pilot controls the aircraft but does not determine separation across European airspace. Flight-control computers make corrections faster than any human could, but they do not decide where the aircraft should fly tomorrow. Regulators establish constraints without attempting to fly the aircraft remotely from an office.

The system works partly because these different forms of control remain deliberately separated. They operate at different frequencies, with different information and different responsibilities. A flight-control computer reacts in milliseconds. Pilots respond over seconds and minutes. Air traffic control manages trajectories over minutes and hours. Network operations coordinate fleets over hours and days. Regulators alter the boundaries of the system over years. Higher authority does not imply control of lower-frequency machinery. In many cases, attempting to exercise such control would make the system less safe.

This distinction matters because visibility and control look deceptively similar from above. If seeing something improves the ability to influence it, seeing more appears naturally to offer more control. The inference feels reasonable until the controller starts telling the pilot how to configure the aircraft because a particular flap setting produced excellent results at Heathrow last year.

When the Control Tower Enters the Cockpit

Organisations rarely make the mistake quite so theatrically. They begin with legitimate strategic objectives. Reduce customer onboarding from six weeks to one. Improve reliability. Enter a new market. Reduce the economic cost of operating the platform. Increase the rate at which customer problems can move from discovery to production. These objectives describe desired changes in the state of the system and establish direction without pretending that every necessary decision can already be known.

Then something subtle happens. The objective becomes a programme. The programme becomes initiatives. Initiatives acquire milestones. Milestones become features. Features enter quarterly roadmaps. The roadmap reaches three quarters into a future nobody has yet observed. Meanwhile engineering practices become standardised, particular tools become mandatory, teams acquire delivery targets, dashboards compare throughput and somebody eventually discovers that the organisation can count stories per sprint.

Each individual step promises additional visibility. Collectively, however, they change the control architecture. Decisions that once occurred close to the information required to make them migrate upwards, while increasingly detailed representations of reality travel in the opposite direction. Senior management can now see more of the machinery, but seeing more creates an irresistible temptation to operate more of it.

The distinction between strategy and execution begins to disappear. A strategic objective defines a destination and meaningful constraints. Execution continuously discovers the route through contact with reality. When leadership specifies the destination, the route, the sequence, the vehicle, the engineering practices and the instruments that must appear on the dashboard, it has not created unusually strong alignment. It has collapsed several control loops into one.

The organisation then needs even greater visibility because centralised decisions require centralised information. More reporting becomes necessary. Jira hygiene suddenly acquires executive significance. Estimates become commitments because portfolio planning depends upon them. Dependencies require programme management because local decisions can no longer absorb them. Standardisation expands because centrally coordinating heterogeneous approaches proves difficult. What started as an attempt to obtain control progressively creates the coordination machinery required to sustain central control.

The Waterfall That Learned Scrum

Planning itself does not create this pathology. Aviation plans obsessively. Airlines construct schedules months ahead, pilots prepare routes before departure, airports forecast traffic and manufacturers plan production years into the future. Serious engineering systems plan precisely because the future contains uncertainty.

The important distinction concerns what happens when observation contradicts prediction.

A flight plan represents an intended trajectory through conditions understood at departure. Weather develops. Traffic changes. Equipment fails. Winds differ from forecasts. The plan retains value because the system continuously compares prediction with observation and corrects accordingly. Nobody accuses the atmosphere of failing to respect the quarterly roadmap.

Many supposedly agile organisations have preserved the opposite architecture. They run two-week sprints, maintain product backlogs, employ Product Managers, practise DevOps, deploy continuously, define OKRs and perhaps celebrate impressive DORA metrics. Meanwhile scope and sequence remain substantially predetermined several quarters ahead. Teams receive initiatives decomposed elsewhere, progress gets measured against completion of that decomposition, and discoveries made during execution struggle to alter commitments already embedded in budgets and executive expectations.

Waterfall did not disappear. It changed clothes.

The original waterfall made its assumptions visible through phases and documents. Its contemporary descendant distributes agile ceremonies throughout the organisation while retaining a fundamentally open-loop assumption at the top: that enough analysis performed early enough can describe the sequence of work required to reach a distant outcome. The iteration occurs inside the execution machinery, while the trajectory itself remains strangely resistant to evidence.

The most revealing moment arrives when teams discover something that invalidates part of the plan. Instead of treating the discovery as new information about the system, the organisation treats it as a delivery problem. Reality has become a deviation from the roadmap.

The Missing Flight Hours

This raises a harder question. Intelligent people construct these systems. Most executives do not wake up hoping to create bureaucracy, exhaust engineers or turn Jira into an instrument of corporate surveillance. Many sincerely believe they are improving execution. Why, then, does strategic leadership so easily descend into operating the machinery?

Aviation offers another clue. Flight hours matter for reasons that extend far beyond practising the mechanical operation of an aircraft. An experienced pilot has encountered more states of the system and, perhaps more importantly, more transitions between those states. Weather that looked harmless and subsequently deteriorated. Approaches that remained technically possible but gradually became unstable. Instrument readings that individually appeared unremarkable but together formed an uncomfortable pattern. Decisions that initially seemed conservative and later proved essential.

Experience gradually produces something manuals cannot fully encode: judgement under incomplete information.

The same transition should occur as technical leaders move through levels of responsibility. An engineer primarily encounters code and systems. A senior engineer increasingly sees boundaries, interactions and failure modes. A manager encounters teams and delivery systems. A director must perceive flows of work, dependencies, capabilities, incentives and constraints across teams. A CTO eventually confronts an economic and technical system in which architecture, people, capital, customers, risk, time and organisational structure continuously influence one another.

The object of work changes at each altitude. Knowledge accumulated at the previous altitude remains valuable, but no longer sufficient.

Our industry has become extraordinarily effective at accelerating access to knowledge. Careers move quickly. Information moves even faster. Books compress decades of experience into hundreds of pages. Conferences distribute practices developed elsewhere. Social networks circulate the visible habits of successful companies. Frameworks package complicated organisational ideas into portable vocabulary. The modern technology leader can encounter more management concepts before forty than previous generations might have encountered during an entire career.

Exposure to information and exposure to consequences do not compress at the same rate.

You cannot completely accelerate the experience of designing an organisational structure, watching its unintended incentives emerge eighteen months later, discovering that your original explanation was wrong and carrying the corrected mental model into the next organisation. You cannot download the memory of introducing a sensible metric and watching rational people optimise themselves into absurdity around it. A postmortem can explain why an architecture failed, but reading fifty postmortems does not perfectly reproduce having defended the architecture, watched it fail and eventually understood which assumption you should have challenged three years earlier.

Flight hours contain consequences.

The Comfort of Familiar Instruments

This matters when people reach strategic altitude before they have encountered enough different system states to construct the broader picture their new role requires. The problem does not depend reliably on age. Some people accumulate unusually diverse experience quickly. Others repeat essentially the same year for decades. The important variable concerns the richness of exposure and the degree to which someone has lived with the consequences of decisions long enough to revise their mental models.

Without that accumulated judgement, uncertainty at strategic altitude can feel profoundly uncomfortable. The leader knows software development. They know Jira. They know Scrum. They know cloud platforms, architecture reviews, story points, deployment metrics and engineering tools. They may know exactly how a celebrated technology company organised its teams, or how their previous employer ran quarterly planning.

These controls feel reassuring because they remain concrete.

Reducing the economic cost of changing a product requires understanding a system. Mandating a tool requires purchasing licences. Building an organisation capable of adapting rapidly requires reasoning about architecture, incentives, knowledge flows and decision boundaries. Requiring eight stories per sprint produces a number by Friday.

The shortcut does not remove complexity. It converts complexity into instructions.

This explains why importing practices from successful organisations remains so seductive. A practice carries visible evidence of success without carrying the complete system that produced it. The organisational structure, market position, engineering maturity, architecture, capital constraints and historical accidents surrounding the practice disappear during transportation. What remains is something wonderfully easy to mandate.

The control tower has found another switch.

Measuring Wheelspin

Counting stories per sprint looks ridiculous when examined closely, but its deeper problem has little to do with whether stories have consistent sizes. It confuses actuator movement with system displacement.

A car travelling along a road converts wheel rotation into movement because traction connects the actuator to the environment. Put the same car on ice and the relationship collapses. The engine can produce enormous power. The wheels can achieve spectacular rotational velocity. The dashboard can report impressive numbers. The vehicle may barely move.

Productive organisations contain the same distinction. Stories completed, tickets closed, pull requests merged, lines generated, deployments performed and hours consumed describe activity inside the machinery. Under suitable conditions some correlate with progress. None constitutes progress independently of the system connecting that activity to an economic or customer outcome.

Once management confuses the two, incentives complete the transformation. Teams learn what the instrumentation rewards. Stories become smaller when story counts matter. Tickets multiply when ticket completion matters. Deployments proliferate when deployment frequency becomes a target rather than an observation. People rarely need to manipulate the system maliciously. They merely respond rationally to the control signals they receive.

The dashboard improves while the underlying system quietly changes shape around it.

More Horsepower

Artificial intelligence now enters this already complicated control system, carrying an extraordinary promise: acceleration.

The promise contains substantial truth. AI can reduce the cost of producing code, tests, specifications, analysis, documentation and countless other artefacts involved in software development. It can shorten feedback loops when used close to the problem, broaden access to knowledge and remove genuinely wasteful mechanical work. Nothing about the technology requires the outcome to become pathological.

But adding power does not determine direction.

A racing car entering a corner with the wrong steering angle does not recover its trajectory merely because the engine develops another two hundred horsepower. Additional power can instead become heat, tyre wear and smoke. The wheels move faster. The car does not necessarily approach its destination faster.

Organisations already measuring activity rather than outcomes can use AI to produce dramatically more activity. More code arrives for review. More specifications appear. More tickets can be decomposed. More tests can be generated. More reports can summarise the resulting work. Management observes increasing throughput and concludes that the organisation has accelerated, even while engineers absorb growing volumes of generated artefacts, coordination expands and the distance between production and useful outcomes remains stubbornly unchanged.

The tyres spin faster.

This creates a particularly unpleasant feedback loop. Weak understanding of the system encourages intervention at execution level. Intervention reduces local authority and increases coordination requirements. Coordination generates additional reporting. Additional reporting creates greater apparent visibility. Greater visibility increases confidence in central intervention. AI lowers the cost of producing both the work and the representations of the work, increasing the gain of the entire loop.

The organisation burns more energy while becoming increasingly convinced that the smoke proves the engine works.

Seeing More, Touching Less

Aviation never solved this problem by choosing autonomy instead of control. Aircraft do not operate through trust exercises. Aviation exercises extraordinary control, but distributes that control according to information locality, response time, responsibility and abstraction.

The flight computer controls what demands reaction faster than humans can provide. The pilot controls what requires immediate understanding of the aircraft and its environment. Air traffic control manages interactions no individual cockpit can perceive. Network operations coordinate resources across the fleet. Regulators establish boundaries that individual operators cannot credibly define for themselves.

Each level sees something the others cannot. Each level also refrains from controlling things another level can control better.

Perhaps this explains one of the stranger properties of genuine seniority. Greater responsibility should produce greater access to reality while progressively changing the altitude of intervention. A CTO may investigate an incident deeply without selecting the team's deployment process. A director may understand delivery data without converting throughput into quotas. An executive may understand architectural constraints without prescribing the library that engineers must adopt next Tuesday.

Observation and intervention remain different acts.

The discipline required at senior levels may therefore involve learning to see increasingly large portions of the system while resisting the reassuring temptation to touch every visible control. That restraint does not come naturally from hierarchy. It emerges from having seen enough systems react badly when someone pulled the wrong lever.

Modern executive cockpits now contain instrumentation previous generations could scarcely imagine. Jira can expose every story. Source-control systems reveal every change. Observability platforms expose the behaviour of production systems in extraordinary detail. Financial tooling can attribute expenditure almost continuously. AI can ingest much of this information and produce an executive interpretation before the first meeting of the morning.

Never has someone sitting so far from the machinery potentially possessed so much visibility into its operation. We have spent decades improving the instruments, shortening the reporting delays and increasing the resolution with which organisations can observe themselves.

Aviation would probably recognise the achievement. It has spent a century improving instrumentation too.

It might find something else rather more difficult to understand: while making the cockpit more sophisticated than ever, we also started wondering how many flight hours were really necessary before someone could occupy the captain's seat.