A team must justify adopting a workflow engine to a sceptical audience who see it as unnecessary complexity. How should the case be made?

The case that works

Start with the failures, not with the technology. Enumerate the specific incidents: the workflow that stopped when a worker was replaced, the duplicate payout from a retry, the customer whose onboarding stalled for three weeks and was found by a support ticket, the hours spent writing state machines and recovery logic in each service.

Then quantify what that costs: engineering hours spent on orchestration and recovery code, incidents attributable to it, and the ones that were customer-visible.

Only then introduce the mechanism, as the thing that removes that class of work.

Why this order

A proposal that starts with the technology invites the reasonable objection that it is a solution looking for a problem. A proposal that starts with a catalogue of real, expensive failures makes the objection difficult, because the alternative on the table is continuing to pay those costs.

What must be stated honestly

• The operational dependency. A new system to run, monitor, upgrade and be paged for.
• The programming model constraints, which are real: determinism requirements in workflow code, and versioning of workflows that are already running when the definition changes.
• The learning cost for every engineer, and the period of reduced productivity.
• The scope. It earns its cost for long-running, numerous, externally-dependent workflows that are expensive to get wrong. A three-step synchronous flow does not need it, and adopting it universally taxes work that never had the problem.

Naming the costs first makes the recommendation credible. Omitting them invites reviewers to hunt for the omission, and they will find it.

The clincher that is usually available

"We are already building this, badly, in five services." Hand-written orchestration of long-running processes exists in most systems that need it, distributed across services, with inconsistent retry semantics and no unified visibility. Showing that the choice is between one deliberate implementation and five accidental ones reframes the complexity argument entirely.

The pilot

Propose one workflow, not a platform migration. A single high-value, currently-painful workflow migrated end to end produces evidence, builds expertise, and makes the second decision easy — or reveals that it was the wrong choice at a fraction of the cost.