top of page

Cross-Functional Workflow: Why Work Gets Stuck Between Departments

Writer: Dawnnitta DezaRay
Dawnnitta DezaRay
Sep 14
4 min read

Updated: Sep 18


When work stalls, leaders usually look for the department causing the delay.

Procurement is waiting.

Engineering hasn't released the information.

Finance hasn't approved it.

Operations hasn't finalized the plan.

Sometimes one of those departments really is the problem.

But often the delay sits somewhere else entirely.

It sits between them.

That distinction matters because a company can have capable leaders, strong departments and clear internal procedures while still struggling to move work from one function to the next.

The departments may be performing exactly as designed.

The cross-functional workflow may not be.


The first sign: everyone has a reasonable explanation

Cross-functional problems are difficult because there is not always an obvious failure.

Procurement did not receive a complete request.

Engineering was waiting on field information.

Operations believed the information had already been provided.

Each explanation may be accurate.

Leadership still has delayed work.

That is the signal.

When several functions can explain why they are not responsible for the delay, look at the handoff between them.

The problem may not be poor performance.

It may be an unresolved dependency.


Departments manage their piece. Leaders have to see the whole flow.

Specialization creates necessary boundaries.

Finance manages exposure.

Procurement manages commitments.

Engineering manages technical integrity.

Operations manages execution.

Quality manages requirements.

Each function should protect what it is responsible for.

The problem begins when no one is watching what happens to the work as it crosses those boundaries.

A department can improve its turnaround time and still create a downstream delay.

Another can meet every internal service target while the overall process continues to slow.

This is how organizations end up with well-run departments connected by a poorly run process.

That is not a departmental performance problem.

It is an end-to-end execution problem.


Status tells you where the work is. Waiting tells you why it stopped.

When leaders ask:

“Where are we on this?”

they usually get activity updates.

Engineering is reviewing it.

Procurement has it.

Finance is working through the request.

Operations is coordinating.

Those answers tell you where the work currently sits.

They do not tell you what is preventing movement.

A better question is:

What are you waiting for?

That question exposes the dependency.

If Procurement is waiting for Engineering, what does Procurement need?

If Engineering is waiting for Operations, what does Engineering need?

If Operations believes its part is complete, where did that understanding break?

Follow the waiting and you usually find the real constraint.

The department holding the work is not always the department that caused it to stop.


Cross-Functional Workflow Creates an Ownership Gap

Org charts are good at showing reporting relationships.

They are much less useful for showing how work actually moves.

A manager may depend on someone in another function who depends on someone in a third.

No one reports to one another.

All three are responsible for some part of the same outcome.

That is where ownership becomes less obvious.

Each manager can manage their department.

Each team can complete its assigned task.

Yet no one may own the movement of the work from beginning to end.

That is the gap leaders need to look for.

The moment work crosses a functional boundary, ask:

Who owns the next move?

Not who owns the department.

Not who owns the task.

Who owns moving the work forward?

If the answer changes depending on who you ask, the delay is already built into the process.


“I thought they had it” is an operating signal

One phrase should immediately get a leader's attention:

“I thought they were handling it.”

Usually that sentence is not evidence of laziness.

It is evidence that ownership became unclear at the handoff.

One team believed its responsibility ended when it sent the information.

The next believed its responsibility began only after something else happened.

The work changed hands.

Ownership did not.

That is where small assumptions turn into long delays.

By the time leadership sees the issue, the organization may already have spent days following up, copying more people, clarifying expectations and scheduling meetings to reconstruct what should have happened automatically.

The useful question is not:

“Who dropped the ball?”

It is:

At what point did we stop knowing who had it?


More visibility will not fix unclear movement

Organizations have more visibility than ever.

Dashboards show status.

Workflow systems assign tasks.

AI can summarize updates and flag overdue work.

Those tools are useful.

But they do not resolve an unclear dependency.

A system can tell you that Procurement has had a request for three days.

It cannot fix the fact that Procurement is waiting for information nobody knew it needed.

AI can identify the delay faster.

It cannot assign authority that the organization never defined.

Technology can make a broken process easier to see.

It does not automatically make the process better.


What leaders should look for

When work repeatedly stalls between departments, stop asking only which function has the item.

Look for the pattern underneath it.

Where does work repeatedly wait for information?

Where does ownership become unclear after a handoff?

Where do people rely on follow-up instead of a defined next step?

Where does the same dependency create recurring meetings, escalations or status checks?

And where can every department reasonably say, “We did our part,” while the outcome still arrived late?

Those are not isolated communication problems.

They are signs that the organization has not fully designed how work moves across its boundaries.

Departments manage pieces of work.

Leadership has to manage the movement between them.

And when execution keeps slowing down despite capable teams, that is often where the real problem is.

 
 
 

Comments


bottom of page