The workflow chart is the artifact

The workflow chart is usually the most visible part of the system, which is exactly why it can be misleading.

It shows the official sequence: a request enters, a team reviews it, someone approves it, another team implements it, a tool records status, a handoff happens, and a customer or internal user gets the outcome.

The chart looks like the process.

In workflow-heavy B2B environments, it often only shows the artifact.

I am borrowing that word deliberately. Edgar Schein’s model of organizational culture separates culture into visible artifacts, espoused beliefs and values, and deeper underlying assumptions. The model is usually taught as culture theory, but it maps very cleanly to workflow problems.

Artifacts are the things you can see: the flowchart, the Jira board, the CRM stages, the approval template, the weekly meeting, the compliance checklist, the status language, the dashboard, the escalation path.

Espoused process is what the company says the workflow is: “everything goes through product,” “support owns triage,” “engineering only starts after requirements are complete,” “finance approval happens before vendor work,” “customer success owns implementation.”

Underlying assumptions are the rules people actually follow when the work gets messy.

The real workflow usually lives there.

In a workflow-heavy B2B context, the work may move between technical teams, non-technical teams, people in the field, people in an office, external vendors, client stakeholders, legal or compliance reviewers, and systems that were never designed to cooperate. Some people work from dashboards, email, WhatsApp, Slack, or memory because the official tool does not reflect how the work actually gets done.

Then regulations, contract terms, customer promises, data rules, and legacy tools impose their own constraints on top.

The result is a process that looks simple when drawn, but behaves like a maze when used.

People are not usually careless here; complexity usually crept in quietly. A workaround solved one urgent customer issue, a senior person knew who to ask, a compliance step was added after an incident, a field team created a shortcut because the office process did not match reality, and a vendor needed a different format or a customer required an exception. The team kept moving, the workaround kept working, and eventually it became part of the system without being named.

Implicit workflow becomes canon this way.

The organization keeps saying it has one process, while the real process exists as tribal knowledge. People know how things work, but they cannot always name the steps. They can tell you who to ask, what to avoid, which field matters, which approval can wait, which customer gets an exception, and which tool is technically official but practically useless.

That knowledge is valuable, and it is also fragile.

It sits in the heads of people who have survived the system long enough to know the unwritten rules. New people learn it socially, not structurally. External teams learn it by making mistakes. Founders and operators hear about it only when something breaks badly enough to become visible.

This is why a serious look at a workflow should not start by trusting the chart.

The chart is useful because it shows the artifact layer. It reveals what the organization believes the workflow should be, or at least what someone once needed the workflow to look like. The mistake is treating that chart as the truth.

I have seen the truth sit in the gap between the chart and the work, especially in workflow-heavy B2B environments where people learn the real sequence by surviving it.

For example, take enterprise onboarding. The official process may say that sales closes the deal, customer success collects the requirements, implementation configures the account, product handles gaps, engineering handles blockers, and support takes over after launch.

That sounds clean.

Then a customer arrives with incomplete data, a sales promise that does not match the product, an integration constraint, a security questionnaire, a finance approval delay, and an internal stakeholder who only appears halfway through implementation. The official workflow still exists, but the real workflow becomes a negotiation across roles, tools, assumptions, and deadlines.

The chart says implementation owns the work. The underlying assumption may be that the founder will intervene if the customer is important enough. The chart says product owns gaps. The underlying assumption may be that engineering will solve urgent exceptions directly if the account is strategic. The chart says customer success owns communication. The underlying assumption may be that everyone keeps a side channel open because the official status does not move quickly enough.

Those assumptions may keep the business running.

They may also be the reason the business keeps paying the same coordination tax.

The Schein model is useful because it gives the founder permission to stop treating the visible layer as the whole truth. In his culture work, the artifact is only the observable layer. The deeper question is what people have learned to believe is normal, acceptable, risky, rewarded, or impossible inside the organization.

That matters in workflow diagnosis because people rarely describe their real process as a process. They describe it as common sense: ask Sara before sending that, do not wait for formal approval if the customer is strategic, that field is required but nobody uses it, the system says pending but finance already approved it by email, and escalate this type of request on WhatsApp because the ticket queue is too slow.

None of those sentences looks like architecture.

Together, they become architecture because they define how the work actually moves, who has informal authority, which constraints are treated seriously, and which official rules have become decorative. A workflow chart without that layer can be accurate in the narrow sense and still useless in the operational sense.

The same pattern appears in property maintenance. A tenant raises a request, a building manager reviews it, a vendor is assigned, a quote is approved, the work is completed, and payment is processed.

Simple enough on paper.

Then the technician is on the go, the building manager is handling ten other issues, the vendor uses a different reporting format, finance needs a purchase order, the tenant sends photos through a separate channel, and compliance requires evidence that the work was completed safely. The process is no longer a line; it is a knot, and if nobody names it, the organization keeps optimizing the wrong thing.

The organization redesigns the form when the form was not the issue, adds a status meeting that only compensates for missing state, then buys another tool that becomes an artifact layered on top of the implicit workflow.

The deeper work is to surface the assumptions.

The questions are connected: which official steps are ignored, which unofficial steps are critical, which people act as routers, which tool is treated as the source of truth when the real source lives elsewhere, which exceptions have become normal, and which regulatory or contractual rules shape the workflow without appearing in the chart?

This is where a system-level audit becomes useful. It is more than a process-mapping exercise: it compares artifacts, stated process, and the assumptions underneath, then decides what should become explicit.

Some implicit knowledge should become part of the system.

If a senior operator always knows which customer risk should change the implementation path, that judgment should be captured before it becomes a bottleneck. If a compliance check always changes the sequence, it should be visible in the workflow. If external vendors are using a different format, the system should account for that handoff rather than pretending everyone shares the same operating model.

Some implicit knowledge should be challenged.

If the real assumption is “important customers bypass the workflow,” the business needs to decide whether that is a strategy or a hidden cost. If the real assumption is “engineering will rescue unclear requirements,” the product team needs to decide whether the upstream work is actually complete. If the real assumption is “new people will learn by asking around,” the organization has accepted onboarding drag as normal.

The point is not to flatten all complexity.

Some complexity is real: regulated work has rules, enterprise customers have constraints, field teams operate differently from office teams, technical and non-technical teams do not see the same risk, and external partners need translation. The answer is not to pretend the work should be simple.

The answer is to stop letting complexity remain unnamed.

Once the workflow is named honestly, the team can decide what to simplify, what to govern, what to automate, what to document, what to remove, and what to leave human because judgment is still required.

Drawing a process is different from understanding an operating system: a chart can show the artifact, while a better audit reveals the assumptions underneath it.

The useful question for a founder or operator is not only “what is the workflow?”

It is: what workflow has the organization learned to follow without admitting it?

That is usually where the cost lives.