The Quiet Person in Your Process Workshop Isn’t Disengaged

There’s a moment in most process workshops where you notice someone hasn’t spoken.

40 minutes in, everyone else has contributed, they haven’t said a word.

The easy read is that they’re not interested.

Usually that’s wrong.

More often they’re managing something you can’t see from the front of the room.

😬 Why people go quiet

A few reasons come up repeatedly.

  • They don’t actually know the answer, despite it being nominally their area
  • They know their bit, nothing either side of it, so any question feels like a trap
  • Their manager is in the room, so being wrong out loud carries a cost
  • They’ve been doing it a certain way for years, suspecting it isn’t the approved way
  • The process on the wall makes their role look small, which is uncomfortable to have documented
  • They’re new enough that admitting confusion feels risky

None of those are apathy.

They’re all about exposure.

A process workshop, from the wrong seat, feels like a test with an audience.

That’s a reasonable thing to stay quiet through.

🔎 Why it matters for the map

This isn’t a pastoral concern, it’s an accuracy problem.

The people most reluctant to speak are frequently the ones handling the exceptions.

The person who processes the odd cases nobody else understands.

The one who built a workaround because the system can’t do something.

The one covering a step that was never formally assigned to anyone.

Lose their input, then your map covers the happy path only.

Which means the future state design fails on contact with the 8% of cases consuming most of the effort.

🤝 Reduce the exposure before the session

The best fixes happen before anyone walks in.

Ask for written input first.

Email each person, asking them to describe their part in plain writing, as if explaining it to a new starter.

10 minutes at their desk, no audience.

People are markedly more honest in private text than in a room.

Turn up with a draft.

Never a blank wall.

Correcting something is easier than producing it, especially for someone unsure of themselves.

Make the draft visibly rough, so correcting it feels helpful rather than critical.

Keep the group to 6 or 8.

Beyond that, quiet people disappear entirely.

Think about who’s in the room together.

A supervisor sitting next to their team changes what gets said.

Sometimes 2 smaller sessions produce far better material than 1 combined one.

🗣️ Lower the stakes in the room

Say the awkward thing at the start, before anyone has to think it.

Something like this.

“Nobody here knows this whole process, that’s normal, that’s why there are 7 of us in the room.”

Or plainly: “I’m not auditing anyone, I’m writing down what actually happens.”

Most people visibly relax once that’s out loud.

A few other things that help.

  • Ask about the last real case someone handled, not the standard version
  • Frame questions as your confusion, not their gap
  • Normalise workarounds by mentioning you expect to find some
  • Never ask someone to explain a step you know isn’t theirs
  • Let silence sit, because rushing to fill it stops the slow thinker contributing

That fourth one matters more than it sounds.

Asking someone to speak on something outside their area, in front of colleagues, guarantees they stay quiet for the rest of the session.

🚪 Follow up individually, always

This is the single highest value habit in process work.

After every workshop, book 15 minutes with anyone who said little.

No agenda, no group, no manager.

Ask what they’d add now that they’ve seen the draft.

The answers are often the most useful material from the entire exercise.

The exception nobody mentioned.

The step that only works because they check something manually every Friday.

The bit of the map that’s plainly wrong, which they weren’t going to correct in front of 7 people.

Book it in the room, before everyone leaves.

Chasing later gets ignored.

⚖️ When someone genuinely doesn’t know

Sometimes the reluctance is exactly what it looks like.

The person nominated as the expert isn’t.

Handle that carefully, because embarrassing them creates an enemy for the rest of the program.

What works.

  • Thank them, then ask who else touches this work day to day
  • Go to that person separately, without making a point of it
  • Never report back that the nominated SME couldn’t answer
  • Include them in the review anyway, so their standing is intact

You’ll need them again in 3 months.

Costing them face over 1 workshop isn’t worth it.

✅ The short version

Reluctance in a process workshop is nearly always about risk, not attitude.

Reduce the risk, then the information arrives.

Written input first, a rough draft on the wall, small groups, plus a private 15 minutes afterwards.

That’s most of the job.


About the author

Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.

His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.

He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.

alisodigital.com

Read More

Related Posts

The Quiet Person in Your Process Workshop Isn’t Disengaged

There’s a moment in most process workshops where you notice someone hasn’t spoken. 40 minutes in, everyone else has contributed, they haven’t said a word. The easy read is that they’re not interested. Usually that’s wrong. More often they’re managing something you can’t see from the front of the room.

Yes, AI Helped Write This. I’ve Been a Technical Writer for 20 Years.

Let’s get the objection out of the way first. Yes, AI helped produce this article. I’ve been a technical writer on and off for nearly 20 years. Government, healthcare, finance, aviation, telecommunications. I use these tools daily. I use them deliberately, without guilt. The argument against doing so doesn’t hold

The Time AI Gives Back to a Technical Writer

Every technical writing job has a set of tasks that sit between you, the actual writing. Building an outline. Working out what’s missing from a documentation set. Putting together an example so a concept lands. Editing the same document for the fifth time. None of that is the hard part

4 Things AI Genuinely Does Well in Technical Writing

There’s a lot of noise about AI in documentation work. Some of it oversells what the tools do, some of it dismisses them entirely. The reality sits in the middle, which is less interesting to write about, though more useful. After a couple of years using these tools daily across