Signal, noise and the limits of attention

When I was running Biketrax, I once noticed that a colleague had accumulated more than a hundred unread Odoo notifications. My immediate response was not especially sophisticated: “Christ!” I showed them the mark all as read function, cleared the backlog and suggested that they begin again.

For a short while, this worked. Within a few weeks, however, the notifications had accumulated again and were once more being largely ignored.

The obvious interpretation was that the colleague needed to manage their messages more carefully. There was some truth in that. The notifications were not administrative trivia: customers were responding to workshop quotations, hire bikes required preparation, and components needed for repairs were arriving late. Customer messages were among them, and customer contact is precisely the sort of information a small operational business cannot afford to lose.

Yet the recurrence of the problem made the individual explanation increasingly unsatisfactory. I had exposed somebody to a volume of information that they were unable to curate reliably for themselves. The software was functioning as designed, and much of the information it produced was genuinely useful, but the resulting communication system was not functioning reliably.

That distinction has stayed with me because it points to a broader management problem. One of the less intuitive things I have learned from managing people is that exceeding somebody's bandwidth does not normally produce a proportional reduction in performance. If someone has capacity for ten things and we give them eleven, we should not assume that ten will continue to be completed perfectly while the eleventh waits patiently. Beyond a certain point, prioritisation itself begins to fail. The queue becomes difficult to interpret, important work competes with routine work, and eventually an apparently manageable increase in demand can produce a disproportionate reduction in useful output.

Information therefore has to be considered not only in terms of its accuracy or availability, but also in relation to the finite attention of the person expected to use it.

Signal is relational

I have often explained this to junior consultants using the language of signal and noise, partly because my original frame of reference comes from music. In a musical mix, clarity is not achieved by making every important element louder. It depends upon space, dynamics and segregation. Different sounds occupy different parts of the available spectrum and assume different levels of prominence at different moments. Impact itself is a scarce resource: if everything is emphasised continuously, the listener adapts and emphasis ceases to function as emphasis.

Business information behaves in much the same way.

An urgent notification derives some of its meaning from the fact that other notifications are not urgent. An exception becomes visible because there is an established conception of normality against which it can be perceived. A summary is useful because it suppresses detail that is unnecessary for a particular purpose, while preserving a route back to that detail when investigation requires it.

This means that signal and noise cannot be treated as intrinsic properties of information. Their distinction depends upon context, the person receiving the information and the decision they are trying to make.

A finance director considering short-term cash exposure may need an aggregated view of overdue receipts and forthcoming commitments. Someone investigating one disputed invoice may require correspondence, transaction history and amendments in considerable detail. The information that would obscure the first task may be indispensable to the second. Neither representation is more truthful in the abstract; each is useful to the extent that it supports the question being asked.

That seems obvious, but contemporary business systems make it unusually easy to forget. We have become very good at producing information. Dashboards can be created cheaply, notifications generated automatically and data segmented into progressively more detailed views. The technical question — can we show this? — is consequently much easier to answer than the managerial one: what will somebody reasonably be able to conclude from seeing it?

The distinction matters because a technically correct representation can still support a poor decision.

Measurement without explanation

I encountered a different form of the same problem when a client requested a daily sales-order margin dashboard. Producing the figure itself was relatively straightforward. The difficulty was that the figure was intended to function as a KPI while much of the context necessary to explain its movement was not being recorded.

A particular day's performance might plausibly have been influenced by weather, a significant sporting event, changes in customer mix, product mix or circumstances peculiar to that business. Another organisation would have a different set of relevant influences, some obvious and some considerably harder to identify. The point is not that any of those factors necessarily explained a particular movement, but that the available data could not establish whether they did.

The dashboard was therefore capable of measuring a change more confidently than the business was capable of explaining it.

That is an important epistemic distinction. Observation and explanation are different activities. A report can tell us that today's margin differs substantially from yesterday's without telling us why, and the fact that a number is calculated correctly does not confer explanatory authority upon it.

The difficulty becomes greater when that measure sits alongside other objectives. In this case, margin existed in obvious tension with revenue. Increasing revenue can reduce margin under some circumstances; protecting margin too aggressively can constrain revenue. Similar tensions exist throughout operational businesses. Greater stock availability may increase working-capital requirements. Higher utilisation can reduce spare capacity and resilience. Faster fulfilment may require additional cost.

A KPI is therefore never entirely neutral. Selecting a measure gives it organisational prominence, and prominence affects behaviour.

People are often described as “gaming” KPIs as though the principal problem lies in their willingness to optimise what is measured. I think that interpretation is incomplete. People inevitably learn the rules of the systems within which they work. If the rules reward the behaviour the organisation genuinely wants, optimisation is not a defect; it is precisely the intended result.

The problem arises when the proxy and the desired outcome diverge. If a salesperson can maximise their apparent performance by selling work that is commercially unattractive, then the weakness lies at least partly in the measure. If a workshop can improve its reported efficiency by delaying awkward jobs beyond the reporting period, the dashboard has created an incentive that differs from the operational objective.

The relevant design question is therefore not simply whether a metric can be measured accurately. It is whether improving that metric is likely to move the business in the direction intended, and what other behaviours might arise as people respond to it.

This is one reason I am reluctant to treat dashboards as passive representations of a business. Once people understand that a measure matters, the dashboard becomes part of the management system itself.

Context, expertise and organisational knowledge

The interpretive problem also helps explain why experienced people can derive meaning from information that appears unremarkable to someone else. Experience provides a frame of reference. It establishes expectations about what normal looks like, which patterns tend to recur and which deviations warrant investigation.

Much of this contextual knowledge is tacit. An experienced manager may look at a set of figures and ask a better question than an inexperienced one, even though both people can see exactly the same dashboard. The difference lies not in the data presented to them, but in the context they bring to it.

Business systems can easily create the impression that this contextual knowledge has somehow been captured simply because the underlying transactions have been recorded. Often it has not. The system may know that margin fell on a particular day without knowing whether the cause was pricing, customer behaviour, product mix, timing, an exceptional commercial decision or something outside the system altogether.

That does not make the data unhelpful. It does mean that we should understand the boundary of what it can support.

The notification problem at Biketrax raises a related question: at what point can an organisation reasonably say that it knows something?

Technical delivery is plainly insufficient. A message can exist in somebody's inbox without receiving their attention. Reading moves us further, but even information that has been read may be misunderstood, forgotten or regarded as somebody else's responsibility. Understanding seems closer to organisational knowledge, yet from an operational perspective it can still be inadequate if no consequence follows.

A customer request that everybody understands but nobody acts upon remains an unresolved customer request. A delayed component that has been correctly identified but assigned to somebody without the authority to change the plan remains a constraint. Information can therefore pass successfully through a technical system while failing to produce an organisational response.

This is where information design begins to overlap with organisational design. The recipient needs sufficient evidence to understand the situation, but understanding must connect to responsibility, authority and some viable route to action. Software can make those relationships explicit and support them consistently. It cannot manufacture them where the business itself has never decided what they should be.

The danger of a quiet system

There is an important qualification to the pursuit of signal-to-noise. Curation is valuable, but an organisation can also become too successful at suppressing information that does not fit its preferred model.

An inconvenient observation is not noise merely because it interrupts an otherwise reassuring report. A customer complaint is not noise because it represents an exception. Nor is an undocumented workaround irrelevant because the formal process says that it should not be necessary.

In practice, people are remarkably adept at compensating for imperfect systems. They remember undocumented dependencies, maintain private spreadsheets, chase colleagues manually and learn which formal procedures require additional intervention to work reliably. Their competence can allow a weak process to produce apparently satisfactory outcomes.

This creates a subtle measurement problem. A system may appear healthy precisely because capable people are absorbing its deficiencies.

The smoothness of an operation therefore tells us something about the outcome, but not necessarily about the mechanism producing it. If the human effort required to sustain that outcome remains invisible, a dashboard can represent the observable result accurately while simultaneously concealing an important operational dependency.

This is why I do not regard reducing the volume of information as an objective in itself. A cleaner dashboard is useful only if it makes the relevant situation easier to understand. Fewer alerts are helpful only if the filtering does not remove information that matters. The purpose of curation is not to make a business appear orderly; it is to improve the relationship between evidence, attention and judgement.

The distinction is important because comfort and clarity are not the same thing. A well-designed management system must retain some means by which reality can contradict the model used to describe it.

Designing for finite attention

Looking back, teaching my colleague to clear more than a hundred notifications was a reasonable immediate response but a poor systemic one. I had removed the accumulated symptom while leaving intact the environment that produced it.

The more useful questions concerned the structure of the information itself. Which events genuinely required that person's attention? Which were informative but not actionable? Which represented obligations? Which belonged to somebody else? How should urgency be expressed, and what should happen when an important matter remained unresolved?

These are not principally questions about Odoo, dashboards or notification settings. They are questions about how the business intends information to become action.

That distinction is central to how we approach systems work at Polyphony. Software implementation begins too late if the first question is which feature should be configured. Before that comes an examination of the operating problem: what the business is trying to perceive, which decisions depend upon it, what evidence those decisions require, who has responsibility for the consequence and what authority they need in order to act.

The technology matters because it can make those relationships easier or harder to sustain. It can reduce the cost of coordination, preserve useful context and make exceptions visible. Equally, it can generate such a volume of technically valid information that the people using it become less capable of distinguishing what matters.

That is the paradox I missed when I first encountered the notification backlog. Every individual message could be useful and the aggregate could still be unusable.

A hundred useful notifications are not necessarily a hundred useful pieces of information. Once attention, context and responsibility are taken into account, they may amount operationally to almost none.

Understanding that distinction is where the more interesting systems work begins.