People

Shall vs Should: Pick One Mandatory Word for Your Procedures

The modal verbs in a procedure change what people do on the floor. Many readers take "should" as optional, and every major drafting standard backs them up. ISO's own house style warns that the differences between these words do not translate easily. Write each requirement with one mandatory word, keep recommendations in a separate labeled block, define both words once, and test the procedure with the people who will use it.

Picture one sheet read two ways

Here is a hypothetical. A plant rolls out new standard work for a fastening station across three shifts. The sheet says operators "should verify torque with the calibrated wrench after every tenth assembly."

Day shift, trained by the engineer who wrote the sheet, checks every tenth unit. Night shift reads a translated copy and checks when the line slows down.

Both crews believe they follow the standard. Under the definitions below, both of them do.

Figure 1. The article's hypothetical torque check: day shift checks every tenth assembly, night shift checks when the line slows, and both follow a step written with "should." Source: Webineering Group (hypothetical example).
Figure 1. The article's hypothetical torque check: day shift checks every tenth assembly, night shift checks when the line slows, and both follow a step written with "should." Source: Webineering Group (hypothetical example).

Culture gets the blame when the document is unclear

When standard work fails to stick, the usual advice is more training, more audits and more leadership attention. When the rollout crosses borders, the explanation often shifts to national culture.

Planet Lean, the online magazine of the Lean Global Network, published a counterargument in October 2014. In "National cultures don't matter when lean is in the picture," researcher Torbjørn Netland drew on his experience across 45 Volvo Group plants. He concluded that "organizational lean culture trumps national culture any time."

Academic work on lean transfer reads less tidily. Angelika Zimmermann and Marc Bollbach studied a German automotive supplier's plants in China. In Asian Business & Management in 2015, they reported that "certain cognitive dispositions and behaviours of Chinese employees acted as barriers to the transfer of the firm's Lean production system."

Their abstract traces those barriers to the Chinese institutional and cultural context without listing them one by one. This article does not attempt a list.

Both sides talk about people and leadership. Neither puts much weight on the document the people were handed, and that gap is where the common advice breaks.

Drafting standards already define these words

Standards bodies settled the meaning of these verbs long ago. Their definitions differ on "shall" and "must," and they agree on "should."

WordISO/IEC Directives, Part 2 (ninth edition, 2021)IETF RFC 2119 (1997)Federal Plain Language Guidelines (2011)
shallRequirement (Table 3)Same as MUSTAvoid: "imprecise," can signal obligation or prediction
mustExternal constraint from outside the document (Table 7)Absolute requirementObligation
shouldRecommendation (Table 4)Recommended; valid reasons to skip may existRecommendation
mayPermission (Table 5)Truly optionalDiscretionary action
canPossibility or capability (Table 6)Not definedNot addressed

The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) state that "the verbal forms shown in Table 3 shall be used to express requirements," and Table 3 leads with "shall." A requirement, in their definition, carries criteria "from which no deviation is permitted if conformance with the document is to be claimed."

A recommendation gets a looser definition: "a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others." That is the meaning a careful reader brings to "should."

The Directives keep "must" for constraints that come from outside the document, such as a law. Their Table 7 tells drafters: "Do not use 'must' as an alternative for 'shall'."

The Internet Engineering Task Force (IETF) says the same thing about "should" in protocol language. Scott Bradner's RFC 2119 from 1997 says SHOULD means "there may exist valid reasons in particular circumstances to ignore a particular item." Barry Leiba's RFC 8174 in 2017 added that only the uppercase forms carry those special meanings.

U.S. federal plain-language writers chose a different mandatory word. The Federal Plain Language Guidelines, revised in 2011, say "must" is "the clearest way to convey to your audience that they have to do something." They call "shall" "imprecise" because it can signal an obligation or a prediction.

Second-language readers widen the gap

In everyday English, "should" covers everything from friendly advice to a firm duty. The Office of the Federal Register's clear-writing guidance for regulation drafters captures that range: "should" "infers obligation, but not absolute necessity."

Native speakers resolve the ambiguity from tone and context, which a written procedure strips away. A reader working in a second language has less context to lean on.

Translation adds a decision point. ISO's house style notes that "shall," "must" and "need to" are often used interchangeably in English, and that "the subtle differences in meaning are not easily translated into other languages."

When the target language has separate words for advice and for duty, the translator has to pick one. This article found no controlled study that measures how often that choice goes wrong in shop-floor procedures. Treat the translation risk as reasoned from how languages work, backed by ISO's own warning.

Aerospace maintenance writing built a standard around this problem. Simplified Technical English (ASD-STE100), maintained by the AeroSpace, Security and Defence Industries Association of Europe (ASD), limits writers to an approved dictionary in which each word has one meaning.

Issue 9, dated 15 January 2025, is the release in which, as its maintenance group puts it, "in 2025 it became an international standard." It has 53 writing rules and a dictionary of about 900 approved words. It caps procedural sentences at 20 words and descriptive sentences at 25.

Procedure wording is the factor both sides can control

Netland's argument holds up on its own evidence: a strong production system can travel across national borders. He also reports "some agreement" in the literature that collectivistic cultures with high power distance "have advantages when it comes to implementing standardization and discipline." That concedes national context shapes how standards land.

The China findings show the system has to arrive in a form people read the same way. A step that a careful reader can take as optional makes skipping it easy to defend, in any country.

Nobody can prove from these studies that wording caused the barriers, and this article makes no such claim. The position here is simpler. Whichever side of the culture debate you favor, the document is the one factor you fully control this week.

Rewrite the procedure in six steps

  1. Choose one mandatory word and define it at the top: "In this procedure, 'must' marks a requirement. Skipping a 'must' step is a deviation that needs supervisor approval."
  2. Read every "should" in the step list and decide whether it is a requirement or a recommendation. Rewrite requirements with the mandatory word.
  3. Move every recommendation into a labeled box titled "Recommended practice," below the steps.
  4. Use "may" only for real choices, and remove "can" from instructions.
  5. Write one action per step, in 20 words or fewer, borrowing the Simplified Technical English limit for procedural sentences.
  6. Give translators a glossary that fixes one target-language word for "must" and another for "recommended."
Figure 2. A procedure page before the rewrite, with "should," "must," "shall" and "can" mixed in the steps, and after it, with "must" defined at the top, every step using it, and recommendations in a separate box. Source: Webineering Group, word meanings from ISO/IEC Directives Part 2 (2021).
Figure 2. A procedure page before the rewrite, with "should," "must," "shall" and "can" mixed in the steps, and after it, with "must" defined at the top, every step using it, and recommendations in a separate box. Source: Webineering Group, word meanings from ISO/IEC Directives Part 2 (2021).

Then test the result. Ask three operators, including one who reads the translated copy, to mark each step "required" or "optional." Any step where they disagree gets rewritten before rollout.

Two conditions call for a different choice

Documents governed by an outside convention. If your procedure implements an ISO standard or a customer specification written with "shall," keep "shall" so the two documents match. Define it once, and still keep recommendations separate.

Guidance written to build judgment. Troubleshooting guides and training notes often describe options for an experienced reader. "Should" fits there, as long as the document is labeled as guidance and kept apart from controlled procedures.

Start on Monday with these steps

  • Search your three most-used procedures for "should" and count each one.
  • Mark each "should" as a requirement or a recommendation with the process owner.
  • Add a one-line definition of your mandatory word to the procedure template.
  • Move recommendations into a labeled box on the next revision.
  • Run the required-or-optional test with three operators on one procedure.
  • Send translators a two-word glossary before the next translated release.

A site assessment reads your procedures as operators do

Webineering's fixed-fee site assessment reviews floor processes, records and reports, which can include the procedures and work instructions on your lines. You receive a written findings report that sets out what we observed and recommends specific fixes. Get in touch to schedule one.

Site assessment

Want to see where your own line stands?

An evidence-backed report on where real value lies, from the people who stay through implementation.

About the authors

Anthony Occidentale

Alex LaDouceur

Founder

Alex has led Webineering since it started in 2022. At DuPont's Circleville plant he held senior engineering and engineering management roles on the $250 million Kapton and Pyralux expansion, a continuous web line taken from design to qualified production. At Schlumberger he was responsible for assembly, test and refurbishment across deepwater completions product lines.

Keep reading

All articles