In a neighbourhood committee, each meeting agenda began to be prepared with a tool that grouped suggestions and proposed an order. The change seemed useful: there were fewer scattered emails and more time for discussion. After three sessions, a resident pointed out something nobody had examined. Topics submitted through long web forms almost always appeared at the top; questions raised at the front desk, by telephone, or in an assembly rarely reached the priorities. The tool had not forbidden those questions. It had silently decided which voices deserved to arrive at the table first.
When people talk about technology and power, it is easy to picture a dramatic decision: a machine denying a right, a platform excluding someone, or an authority hiding its criterion. Power also lives in small operations. It lives in who defines the categories of a list, which source is treated as reliable, the threshold that makes a request urgent, and the screen that shows one option before another. Ordering is not neutral when the order determines what is heard, what is postponed, and what receives no answer.
Making the context clear#
The first question should not be whether a tool “rules” over people. There are almost always people somewhere in the chain. The question is who can intervene at each point and with what knowledge. A resident may be able to submit a request but not know which words will make the system group it. Staff may see the result but lack permission to change the order. The person who bought the software may adjust a setting yet never attend the meeting where its effect is felt. Power is distributed unevenly across those small gestures.
The first question should not be whether a tool “rules” over people. There are almost always people somewhere in the chain.
Making that distribution visible begins by naming the decisions hidden inside a recommendation. Which inputs does it use, which inputs are absent, what criterion turns an issue into a priority, who reviews the cases left out, and which person can stop a rule when it causes harm? These questions do not require everyone to code. They require an organisation to acknowledge that configuration is a form of public or community decision, not a purely technical task to be handed over without discussion.
What changes in practice#
At the committee, the first adjustment was not a new model. It was three equivalent entry points: a web form, a phone call, and a sheet at the civic centre. One person gathered topics without erasing their source, and the agenda showed how many proposals came through each route. The measure revealed that the problem was not a lack of interest among people who did not use the web. It was that the channel most convenient for the system had been mistaken for the channel available to everyone. Making that difference visible changed the conversation about efficiency.
The possibility of veto is another piece of power that is often poorly defined. A veto does not mean that one person can block everything because of a preference. It means there is clear authority to pause a rule when it affects a right, creates a risk, or cannot be explained honestly. To work, it needs a name, conditions, and protection from retaliation. If a worker knows they can point out exclusion but fears being treated as resistant to change, the veto exists only in a manual. The organisation has to show through its conduct that noticing a limit is part of the work, not disloyalty.
Deciding with information#
It also matters who participates before a tool begins to rank. Inviting affected people at the end, when only colours or notice wording remain to be chosen, does not redistribute power. Useful participation takes place while sources, thresholds, and non-digital alternatives can still be discussed. There is no need for an endless assembly over every adjustment. Small groups, bounded trials, and prepared cases can work. The condition is that observations receive a visible answer: what changed, what did not change, and why.
A support group for older people tested a reminder system. At first, people with a history of digital appointments received more messages because the system read activity as a sign of interest. The group asked to examine that assumption. It found that several people preferred telephone or a visit because they shared a device, not because they rejected the service. The correction was simple: contact preference was asked explicitly and reviewed every six months. The important point was not the new variable. It was that someone had the standing to question what “interest” meant.
Reviewing and adjusting#
Records can support this conversation if they are not used as an excuse to watch the people who object. A monthly report can show how many decisions were changed by human review, which channels were underrepresented, which exceptions repeat, and how long an appeal takes. These data do not replace testimony, but they keep problems from remaining isolated impressions. They can also show whether correction authority is used by several people or whether it actually depends on one informal figure who understands the system better than anyone else.
Useful transparency does not mean publishing every line of code or delivering a chart nobody can interpret. It means explaining where relevant decisions are made and how a person can intervene. A community agenda can state which factors rank proposals, which routes are accepted, when the rule is reviewed, and whom to contact to question it. This explanation gives people something more valuable than a promise of neutrality: a route for checking whether power is operating in a justifiable way.
There is a temptation to present automatic ordering as a way to avoid conflict. If the tool decides, it appears that nobody has chosen between difficult requests. But conflict does not disappear; it moves into less visible parameters and, often, onto people with less time or language to contest them. Acknowledging disagreement can be more uncomfortable, but it is more honest. It allows a group to decide which cost it accepts, who deserves an explanation, and when a general rule needs to give way to a particular conversation.
One simple practice can distribute this power more fairly: before activating a rule, write an authority sheet. It should state who proposes the criterion, who approves it, who can modify it, who can pause it, which evidence will be reviewed, and when it will be discussed again. Adding a complaint route and response timeframe turns the sheet into more than paperwork. It turns technical configuration into a checkable commitment. If a name is missing, a responsibility is probably missing too, waiting for somebody to assume it when trouble arrives.
The power that orders a table does not become fair because it is hidden inside an elegant interface. It becomes more responsible when its rules, sources, and limits can be questioned by people living with their effects. The resident at the committee did not ask for every technological aid to be abandoned. She asked that the agenda stop confusing ease of capture with importance. Listening opened a concrete possibility: use a tool to organise without allowing the tool to decide in advance who counts as someone worth organising for.
To begin, choose a list, queue, or agenda that already influences a service. For one week, note which voices enter through each channel, which rule orders them, and who can change that rule. Then ask three people who do not use the main channel how they would raise an important issue. If the answer depends on knowing someone, mastering a form, or insisting repeatedly, the problem is not only interface design. It is power. The next step is small and verifiable: name an equivalent route, a person with pause authority, and a date for checking whether the order still represents the people it should hear.
