There is a particular kind of meeting that most people have sat through. The team is called together, a slide appears with a product name on it, and someone explains that from the first of next month everyone will be using it. There is a short pause for questions. The questions are mostly about logistics: where to log in, who to call, whether the old system will still work. Nobody asks whether the tool is right, because the decision has visibly been made.
Now picture a different meeting. The same people are asked what slows them down. Someone describes the double entry between the quote and the order. Someone else describes the spreadsheet they keep because the system does not show what they need. The conversation ends with a short list of problems, and only later does a tool come up as one possible answer. The tool might even turn out to be the same product. The experience of it is entirely different.
Two ways of arriving at the same software
The difference between being asked and being assigned is easy to dismiss as a matter of manners. It is more than that. It decides whether the people who will use the tool every day have any say in the thing that will shape their working hours.
The UK Health and Safety Executive's Management Standards for work-related stress include a standard on change. It states that organisations should give people timely, well-explained reasons for proposed changes, consult them adequately, and offer genuine opportunities to shape proposals. It adds that staff should understand the likely effect on their jobs, receive training where needed, and know the timetable. The standard covers changes large or small, and a new piece of software for a team is certainly one of those.
The same set of standards describes control as having a say in the way work is done. A tool that dictates the order of steps, the fields to complete and the wording of a message is, in effect, a decision about how work is done. If the people doing the work were not part of that decision, then a small amount of control has moved from them to the tool, and from the tool to whoever chose it.
Why being asked changes the outcome
There is a practical argument and a human one, and they point the same way.
The practical argument is that people who do the work know things that the person choosing the tool does not. The GOV.UK Service Manual makes this point about public services: teams should always start by learning about the people who will use the service, and research should continue through every phase of development. It describes useful evidence as including interviews, observation and conversations with staff who support users, and it advises treating opinions that do not come from users as assumptions to test. The same discipline applies inside a business. The accounts clerk who knows that supplier names are spelled four different ways is a source of requirements that no brochure can supply.
The human argument is about dignity. To be asked is to be treated as someone whose experience is evidence. To be assigned a tool is, at best, to be treated as a user to be trained. Mellorca regards this as a reasoned inference, not a measured result: it is plausible that people who are consulted feel more respected, but the effect will vary by person and by workplace.
An illustrative example
Consider an illustrative case, not a real one: a regional engineering services company in KwaZulu-Natal with about forty staff. The owner is frustrated that site supervisors submit job cards late, and decides to introduce a mobile app so that cards can be completed on the day. A supplier is chosen after a demonstration, a launch date is set, and supervisors are told in a team meeting.
The supervisors have concerns they do not raise. The app requires a data connection that is patchy on some sites. It asks for fields that matter to the office but not to the work. Several supervisors already keep their own notes because they find the paper card too rigid. Within a month, most are completing the app at the end of the week from their notes, which is what they used to do with paper. The cards are no more timely and the owner concludes that the supervisors are resisting change.
Imagine the alternative. Before choosing anything, the owner spends an hour with three supervisors on site, watching how cards actually get completed. They discover that the delay comes from waiting for a customer signature and from awkward sites without signal. The eventual solution might be an app that works offline, or a shorter card, or a change to when signatures are collected. The supervisors helped to define the problem, so the answer has their fingerprints on it. This is a thought experiment; it does not show that consultation always works.
What could realistically change
- Start with the problem, not the product. Ask people what slows them down before any tool is mentioned. Mellorca's guide to questions worth asking before buying is in before you buy another tool, ask these questions.
- Watch the work. A short observation session often says more than a survey. The Service Manual's emphasis on observation, not only opinion, is a useful model.
- Include the sceptics. People who dislike the current tool, and people who work around it, usually understand its weak points best.
- Test before committing. A small trial with a few real users turns assumptions into evidence and gives people something concrete to react to.
- Explain the reasons and the timetable. Even where the decision is firm, the Change standard's emphasis on well-explained reasons and clear timing applies. Being told why, and when, is better than being told only what.
- Be honest about what is fixed. If a tool is a legal or customer requirement, say so. Pretending to consult on a decision that has been made is worse than not asking.
Mellorca has also looked at the consequences of the opposite approach in when a tool rollout takes choices away, and at the adoption side in why CRM adoption problems are often workflow problems.
What changes first, and the business outcome
The first change is that fewer assumptions are carried into the rollout. The tool is more likely to fit the work, because the people who know the work helped to describe it. Adoption can follow more easily, because people are not asked to defend a decision they did not take.
The business outcome may be fewer workarounds and less of the quiet duplication that appears when a tool does not fit. That is a plausible expectation, not a measured one, and it depends on how well the consultation was done.
The human dividend
The dividend is autonomy, and with it a measure of dignity: a say in the tools that structure the working day. People who are asked also tend to understand a tool better, because they have thought about what it is meant to do. That can reduce the helplessness of not knowing why a screen behaves as it does.
The trade-offs
Being asked takes time, and the time is real. A decision that might have taken a week can take two months. Some businesses cannot afford that, or face a deadline set by a customer, a regulator or a failing system.
Consultation can raise expectations. People who offer opinions may reasonably expect them to be used. If the final choice ignores the input, the damage can be greater than if no one had been asked.
Not everyone wants to be involved. Some people would prefer to be told what to do and to get on with their work. Consultation should be an invitation, not a duty, and the quiet voices need ways to be heard without being put on the spot.
Finally, the loudest voice is not always the best guide. A tool designed for the preferences of one confident team member may not serve the others. Observation and trials help to balance opinion against evidence.
Why it matters
The World Health Organization's guidance on mental health at work lists involving workers in decisions among the ways of creating an enabling environment. That is general background and it does not say anything about software in particular. Mellorca's narrower hypothesis is that the manner in which a tool arrives shapes how it is received, and that being asked is a small, practical way of acknowledging that the people doing the work know something worth hearing.
The tool may be identical either way. What differs is whether the people who will live with it feel it was done with them or to them.
Sources and further reading
- Management Standards - Change - HSE (last verified 10 October 2026)
- Learning about users and their needs (last verified 10 October 2026)
- Mental health at work (last verified 10 October 2026)
- Management Standards - Control - HSE (last verified 10 October 2026)
Related Mellorca reading
- What a Week Without Firefighting Would Feel Like
- What Autonomy Looks Like When Systems Hold the Routine
- Why Standardisation Can Free or Confine