Map the real workflow before changing it

The first concrete responsibility of a forward-deployed engineer (FDE) is discovery. In this talk, an FDE is embedded with a customer and learns how work actually moves through the organization before proposing an AI system.

The key word is actually. A process document usually describes the intended or “golden” path. Real work also includes handoffs, decisions, delays, missing information, and exceptions. Those details are part of the workflow too. If an agent is designed from the document alone, it may automate an idealized process that does not match the company’s daily operation.

Start with a manageable slice of the enterprise

An FDE does not begin by trying to model the entire company at once. The engagement narrows a large enterprise to one department. Within that department, the FDE interviews the leads for several connected finance processes, including:

• AP
• AR
• card reconciliation
• banking
• billing
• FP&A

These labels are used in the talk as source terminology. The important point is not the expansion of each abbreviation. It is that the FDE examines several related processes rather than automating one isolated task.

This narrower scope makes the investigation practical while still revealing dependencies. A task that looks local may depend on another team’s records, approval, or decision. Mapping several neighboring processes helps expose those connections.

Ask about the normal path and the failure path

For each process, the FDE asks two different questions:

1. What happens when everything follows the expected path?
2. What do people do when that path breaks?

The second question is often more revealing. It uncovers the informal knowledge held by process leads and individual employees. It can show who takes ownership when a record is incomplete, who knows how to resolve a mismatch, and where work waits for another person.

So workflow mapping is more than copying a sequence of boxes from a procedure manual. It is the work of eliciting and checking:

people → decisions → handoffs → dependencies → exceptions

That map describes the lived process, not only the process that the organization wishes it followed.

The Sarah–Chris example: a hidden handoff creates delay

The speaker illustrates this with an accounts-payable situation. When a purchase order and an invoice do not reconcile, Sarah passes the problem to Chris. Chris then spends four days reconciling the two records.

The visible task may sound simple: compare the purchase order with the invoice. The operational reality is larger:

1. A mismatch appears.
2. The normal path no longer applies.
3. Someone must recognize that the case needs special handling.
4. Sarah must know that Chris owns, or can resolve, this kind of problem.
5. Chris spends several days investigating and reconciling it.

The documentation for the normal path may not mention Sarah, Chris, or the four-day delay. Yet these facts affect the cost, timing, and ownership of the process. They also affect any future agent. An agent that only knows the happy path might not know when to stop, whom to involve, or what information is needed to resolve the mismatch.

The talk presents this as an illustrative client reality, not as a universal description of every finance department or as an independently verified case study.

Why embedded discovery matters

The context needed to operate a business is often distributed across people and teams. Some of it is written down. Some of it exists as habits, local rules, and knowledge about exceptions. A process lead may know which apparent mismatch is harmless, which one needs escalation, and which colleague can resolve it. That knowledge may never appear in a clean API input or a single process document.

An embedded FDE can ask follow-up questions while seeing how the pieces fit together. The FDE can discover that:

• an “owner” in the documentation is not the person who handles the real exception;
• a handoff crosses a department boundary;
• a rare-looking exception consumes several days of work; or
• one process cannot be changed safely without considering another process.

These company-specific practices and cross-functional dependencies become the context for the next steps: representing workflows, deciding which steps AI should handle, and deploying agents into the customer’s existing operation.

A useful contrast: golden path versus lived path

Golden-path description	Lived workflow
Shows the expected sequence	Includes what happens when the sequence fails
May name roles in general terms	Reveals the people who really receive and resolve handoffs
Often omits unusual cases	Shows exceptions, workarounds, and delays
Describes what should happen	Explains what employees actually do

The golden path is still useful. It gives the FDE a starting hypothesis. The interviews and investigation test that hypothesis against real work.

Why this comes before automation

Automation design depends on knowing what the process means, not just what its steps are called. Consider two superficially similar instructions:

• “Reconcile the invoice.”
• “When the invoice does not match the purchase order, identify the mismatch, determine who owns the exception, gather the missing context, and decide whether it can proceed.”

The first describes a task name. The second describes decisions, ownership, and exception handling. The second is closer to what an agent would need in order to participate safely and usefully.

This does not mean every exception should be automated. It means the organization must first know that the exception exists and understand its consequences. Only then can it decide whether a step should be automated, supported by a human, or left to a person.

Main takeaway

The FDE’s first job is not to add an AI tool to a visible task. It is to learn the customer’s real workflow at useful depth:

1. choose a department rather than the whole enterprise;
2. interview the leads of connected processes;
3. map both the expected path and the exception path;
4. identify real owners, handoffs, dependencies, and delays; and
5. use that context as the foundation for workflow redesign.

The Sarah-to-Chris handoff makes the central lesson concrete: a process can look short on paper while hiding a four-day delay in the way people actually coordinate. Before changing the workflow around AI, the FDE must first make that hidden workflow visible.

Source boundary: This chapter follows the speaker’s description from approximately 03:30 to 04:54. The AP, AR, and FP&A labels, the Sarah–Chris example, and the broader FDE responsibilities are presented as described in the talk; the chapter does not treat them as a universal enterprise process or a verified case study.