When the instruction stops working: the machine view

Take a person, give them an instruction, tune the incentives, and the result should follow. It often does. Then one day the inquiries get stuck, people walk around the procedure, and rewriting the procedure a third time changes nothing. That moment is a message about the metaphor, not about the wording.

Picture an instruction in three steps: take the inquiry, check the details, pass it on for processing. Everything is described, everything is logical, and it should run by itself. Then the inquiries get stuck, people take short cuts around the procedure, and the manager genuinely cannot understand why, when it is written down in black and white, the team keeps doing something else.

Because the thing in front of them is not a machine. And it is being managed exactly as if it were one.

The oldest image of a company, and the work it does well

The machine is the earliest and most natural picture of an organisation. Take a person, give them an instruction, tune the incentives, and you get a predictable result. The logic is almost mechanical: input, a process governed by clear rules, output. The management style that grows out of it is scientific management, in Taylor’s original sense: task specification, described business processes, norms, standards, a bureaucratic apparatus in the most literal meaning of the word.

The manager here is an architect of process. Not a motivator, not a coach, not a keeper of style, but an engineer who designs a sequence of operations so that the outcome does not depend on the mood of whoever performs it. That is no insult, and it is not a lazy default. It is a working position and often the only appropriate one. A production line, accounting, a document issuing procedure, a safety protocol: wherever repeatability matters more than the individuality of the performer, machine logic runs clean.

The naive part, and where it hides

The mechanism of the metaphor is simple. The organisation is broken down into functional units, each performing its part of the process. Between the units sit clear interfaces: who hands what to whom, and in what form. The manager describes the process once and then expects the description to run without much further involvement.

The naivety is not in the structure. It is in the belief that a person can be reduced to a performer of instructions, that incentive plus procedure guarantees predictable behaviour. From that belief grows a whole layer of management habits. If something does not work, the instruction must be incomplete, so a clause gets added. If a person makes a mistake, the incentive must be weak, so control or the bonus gets increased.

The trouble is that a living person is not a part on a conveyor. They have fatigue, interest, disagreement, their own logic of priorities. When the organisation behaves differently from what the procedure prescribes, the machine-minded manager sees only a process fault and repairs the process. Sometimes that works. More often the fault covers something the procedure does not describe at all: an unmet need, a mismatch of interests, cultural friction. The instruction cannot see any of it by definition, because it was written as though those layers did not exist.

Where the boundary runs

The machine metaphor is strong wherever the task genuinely decomposes into repeatable operations: manufacturing, logistics, document flow, workplace safety. Predictability matters more than creativity there, and a standard saves more money and more lives than betting on each performer’s personal approach.

The boundary runs where uncertainty begins, the kind that demands judgement, agreement or learning. Sales in a shifting market, a client in a non-standard situation, a team building a new product: pure machine logic starts to slip. The instruction describes yesterday’s experience while the situation has already moved. When a manager keeps treating every fault by adding one more clause, the organisation does not become more precise. It becomes heavier, and the people inside it start looking for a way around the system rather than a way to work inside it.

The symptom is easy to recognise. Bureaucracy grows, the instructions swell, and the result stays flat. That is the signal that the problem sits not at the level of process but at the level of motivation, information or style, which means it calls for a different metaphor.

Entering Russia turns the machine image up to full volume

Here the subject stops being general. For a company selling into Russia from another country, the machine image is close to inevitable, and the reason is distance rather than arrogance. An operation several time zones away, working in a language head office does not read and reporting through a spreadsheet, is easiest to picture as a set of processes that already worked at home and now need replicating with local inputs. The site gets translated. The Google Ads structure gets copied into Yandex Direct. The local team receives a specification and a reporting cadence.

Then the environment declines to behave like an input. Yandex Direct has its own match operators, its own auction and its own way of reading a landing page, so a campaign structure lifted from Google arrives already mismatched. Russian is a heavily inflected language, and keyword work here starts from Wordstat and from morphology rather than from a translated keyword list. A meaningful share of the buying conversation lives in Telegram and WhatsApp rather than email, so a sales procedure that counts calls and form submissions quietly undercounts the pipeline. Online advertising carries a statutory labelling requirement with its own identifier and reporting chain, which is a step no home-market procedure has a slot for.

None of that is a process fault. It is an environment with demands of its own. A machine-minded head office files each item as a local deviation, writes a clause for it and waits for compliance to restore the expected output. The clauses accumulate, the local team spends its week on reporting, and the number that was supposed to move does not move.

What the local practice asks for instead of another clause

Three things, and none of them is a procedure.

Someone local with the authority to decide. Not to escalate, to decide. Russian sales and partner conversations run on agreement reached in the moment, often in a messenger thread, and a person who can only forward the question upward loses the deal while waiting for an answer in another time zone.

Measurement rebuilt for the local funnel before anyone judges the numbers. Yandex Metrica, call tracking and messenger conversations have to be counted, otherwise the conversion rate you are reading is an artefact of the tracking rather than a property of the market. Judging a channel on undercounted data is how a working channel gets switched off.

A regular conversation with the people doing the work. Not a status report against the specification, but a direct question: what is getting in the way, what is missing, what do you disagree with. That is exactly the question a process architect never asks, because the architecture assumes there is nothing to ask about.

Is this task machine-type at all?

If you manage people, the useful question is not “how do I tighten the instruction” but “is this task machine-type in the first place?”

Some operations should indeed be designed once and then enforced with discipline: financial reporting, inquiry handling, quality standards, legal compliance in a market whose rules differ from your own. The process architect belongs there, and the clearer the procedure, the less energy is wasted improvising where improvisation is unwanted.

If you catch yourself rewriting the instruction a third time for the same recurring problem and it keeps coming back, the wording is probably innocent. The person the instruction is written for behaves as a live participant with reasons of their own, not as a part of a mechanism. At that point it is more useful to ask directly what is in the way, what is lacking, what they disagree with, than to edit the clause again.

For a foreign company this is also a budget question. The share of the Russian operation that is genuinely machine-type can be specified from head office and left alone. The rest needs a person in the loop locally, which is a different line in the plan and belongs in the marketing strategy rather than in a procedure document. Deciding which part is which, before the first quarter of numbers arrives, saves a year of clause writing.

The same applies outside work. Trying to regulate a relationship with a list of agreements, who washes the dishes, who gets up when, works exactly as long as shared interest stands behind the list. The moment the list starts replacing the conversation about what each person actually wants, the mechanism creaks. Not because the rules are bad, but because the logic of a part does not suit something alive.

The person on the line steps off anyway

A well designed conveyor is beautiful precisely because it asks the worker for accuracy rather than inspiration. Put a person on that conveyor instead of a part, with their fatigue, their interest and their right to disagree, and at some point they will step off the line. Not because the mechanism broke, but because it was never a mechanism in the first place.

A Russian operation managed from abroad breaks the same way and for the same reason. The procedure travelled, the environment did not, and the people in between were asked to behave like parts. If you need that operation to keep moving between quarterly reviews, the work is closer to ongoing marketing support than to a better specification.

Frequently asked questions

What is the organisation-as-machine metaphor?

It is the oldest and most natural way of picturing a company: input, a process governed by clear rules, output. Work is broken into functional units with defined interfaces between them, the manager acts as an architect of process rather than as a coach or a keeper of style, and predictability is bought by specifying tasks instead of relying on the individuality of whoever performs them. Gareth Morgan describes it as one of several images a manager carries, each of which prescribes a different fix before anyone has looked at the problem.

When is it right to manage something as a machine?

Whenever repeatability matters more than judgement. Accounting, document handling, order fulfilment, safety protocols, quality standards: here a tight procedure saves more money and more lives than a personal approach from each performer, and the clearer the rules, the less energy is wasted improvising where improvisation is not wanted.

How do I know the machine image has stopped fitting?

One symptom is reliable: bureaucracy grows, the instructions swell, and the result does not improve. If you are rewriting the same clause for the third time and the same problem keeps returning, the problem is not in the wording. It sits at the level of motivation, information or working style, which means it needs a different image and a different conversation.

Why does a foreign company running a Russian operation default to this image?

Distance. An operation several time zones away, speaking a language head office does not read and reporting through a spreadsheet, is easiest to picture as a set of processes to replicate: translate the site, copy the Google Ads structure into Yandex Direct, send the specification and the reporting cadence. The local environment then behaves like something that has to be negotiated with, and the procedure has no vocabulary for that.

Sources

Andrey Belokrylov
Andrey Belokrylov

Independent marketing strategist and digital marketer. 10+ years, 100+ projects, from Marriott to small restaurants. I write about how Russian customers decide and how to run Yandex, VK and Avito without wasting the budget. More about me

From reading to doing

Let's look at your project

Send a link. In 30–40 minutes I'll show where the budget leaks, where Russian customers drop off, and what to fix first. Honest, even if we never work together.