A pull request may be waiting for review. A developer may be looking for a decision buried in a chat thread. QA may be missing information that should have arrived with the ticket. A release may be delayed because nobody is certain who owns the next step.

Each delay can look like a separate problem.

But when these patterns repeat, the team may be dealing with something broader: workflow friction.

Workflow friction is the cumulative resistance that makes a process harder, slower or more mentally demanding than it needs to be. It can exist even when every tool is functioning correctly and every person is doing their job.

For engineering teams trying to improve software delivery, this distinction matters. The most effective improvement may not be a faster tool, a new automation or another productivity metric. It may be removing an unnecessary step or making the existing process easier to understand.

This article explores how to identify workflow bottlenecks, investigate the friction behind them and improve the process without simply adding more software.

Why software delivery bottlenecks are difficult to identify

A traditional bottleneck is often described as the point that limits throughput.

For example, if a team produces more pull requests than reviewers can process, code review may become a queue.

That is useful to know—but it does not explain every source of delay.

A workflow can lose time through:

• Waiting for information.
• Repeated handoffs between people or teams.
• Unclear ownership.
• Manual updates across multiple tools.
• Context switching and interruptions.
• Rework caused by incomplete requirements.
• Unnecessary approvals.
• Decisions that have no clear owner.

These problems can occur before or after the visible bottleneck.

A team might increase code review capacity, only to discover that testing is now the limiting stage. It might automate ticket creation, while leaving the underlying requirements incomplete. It might introduce a dashboard that improves visibility but creates another place for developers to check.

Local improvements do not always improve the complete workflow.

The better question is:

Where does work lose momentum, and what causes that loss of momentum?

Start by mapping the actual workflow

Before changing a process, understand how it really operates.

Documentation often describes the intended workflow. The real workflow may include additional steps, exceptions and workarounds that have become normal.

Consider a simplified software delivery process:

Feature request
     ↓
Requirements clarification
     ↓
Development
     ↓
Code review
     ↓
Testing
     ↓
Release
     ↓
Feedback

This diagram is a starting point, not a complete description.

In practice, a feature may move backwards when requirements are unclear. A pull request may wait for a reviewer. A test environment may be unavailable. A release may require a manual update in another system.

To understand the workflow, map:

1. The trigger that starts the work.
2. Each stage the work passes through.
3. The person or team responsible at each stage.
4. The information needed to continue.
5. The decisions that must be made.
6. The conditions that cause work to wait or return to an earlier stage.
7. The outcome that defines completion.

The goal is not to produce a perfect diagram. It is to make the process observable.

Five sources of workflow bottlenecks

A useful workflow investigation looks beyond queue length and considers the different kinds of friction that affect progress.

1. Handoff friction

A handoff occurs when responsibility or information moves from one person, team or system to another.

Examples include:

• Development handing work to QA.
• A product manager passing requirements to engineering.
• An incident response team transferring ownership.
• A developer waiting for an infrastructure change.
• A release manager coordinating several teams.

Handoffs create risk when the receiving person lacks the information needed to continue.

A common symptom is a sequence of clarification messages:

“Which environment is this for?”

“Is this the latest specification?”

“Who approved the change?”

“Are there any known exceptions?”

Each question may be reasonable in isolation. Repeated across a workflow, however, they create delay and interrupt other work.

How to investigate it

For a sample of completed work, record:

• When the handoff occurred.
• When the receiving person could begin.
• What information was missing.
• Whether ownership was clear.
• Whether the work had to be returned.

Do not assume that every handoff is waste. Some handoffs are necessary for quality, safety or separation of responsibilities. The objective is to improve the ones that create avoidable friction.

2. Information friction

Information friction occurs when people cannot easily find, understand or trust the information needed to make progress.

In software teams, this may involve:

• Documentation spread across several locations.
• Conflicting versions of a specification.
• Decisions recorded only in chat.
• Missing acceptance criteria.
• Unclear ownership of technical documentation.
• Inconsistent naming across tools.

The visible symptom may be a developer asking a colleague for help. The underlying issue may be that the process depends on a person remembering where information lives.

How to investigate it

Follow a real task and note every point where someone searches for information.

Ask:

• Was the information already available?
• Was it discoverable?
• Was it current?
• Was its source of truth clear?
• Did the person need to ask someone else?

This can reveal opportunities to improve information structure before buying another documentation or collaboration tool.

3. Context-switching friction

Context switching is not simply moving between applications.

The more significant cost is often the work required to reconstruct the mental context of the task: the goal, assumptions, decisions, relevant evidence and next action.

A developer interrupted during a complex investigation may need to reread code, reconstruct the reasoning and rediscover the state of the problem.

This recovery effort is rarely visible in a task tracker.

Context switching can be triggered by:

• Frequent notifications.
• Meetings that interrupt focused work.
• Unplanned requests.
• Fragmented information.
• Multiple communication channels.
• Unclear priorities.

The solution is not necessarily to eliminate every interruption. Some communication is essential.

Instead, investigate whether interruptions are frequent, poorly timed or caused by a workflow that makes information difficult to access.

For a deeper explanation, see Why Does Context Switching Hurt?.

4. Decision friction

A workflow can slow down even when the information and tools are available.

The missing element may be a decision.

Examples include:

• Nobody knows who can approve a change.
• A routine issue is escalated unnecessarily.
• Several people assume someone else owns the decision.
• Teams wait for a meeting to resolve a question.
• The approval process is more complex than the risk requires.

Decision friction is especially difficult to identify because the process may appear to be waiting for a person rather than waiting for a decision.

How to investigate it

For recurring decisions, identify:

• Who owns the decision?
• What information is required?
• What is the expected response time?
• Which decisions genuinely require escalation?
• What happens when the owner is unavailable?

Clarifying decision ownership can sometimes improve flow more effectively than adding another status dashboard.

5. Tool and operational friction

Tools can create friction when they do not fit the workflow.

Examples include:

• Copying information between systems.
• Re-entering the same data.
• Maintaining manual workarounds.
• Updating several tools to represent one change.
• Using a tool that makes a routine action unnecessarily difficult.

The important distinction is between a tool problem and a process problem.

If a team repeatedly copies data because two systems have no integration, automation may help. If the team collects the same data twice because the process itself is poorly designed, removing the duplicate step may be better.

Before changing tools, understand why the work exists.

A practical workflow bottleneck audit

A workflow audit does not need to begin as a large transformation project.

Start with one recurring process and a small number of real examples.

Step 1: Choose a workflow with a clear outcome

Examples include:

• Pull request review and merge.
• Bug report to resolution.
• Development to QA handoff.
• Release preparation.
• Incident response.
• Developer onboarding.

Choose a process that occurs often enough to reveal patterns.

Step 2: Observe the process as it happens

Do not rely exclusively on interviews or assumptions.

Follow several examples from beginning to end. Record the actual sequence of actions, including workarounds and exceptions.

A simple observation log can look like this:

These are hypotheses. The evidence should determine whether the suspected cause is correct.

Step 3: Separate waiting time from active work

A task may take four days to complete but require only a few hours of active effort.

The remaining time may be spent waiting for:

• A review.
• A decision.
• A test environment.
• Missing information.
• Another team.
• A scheduled release window.

This distinction is important because reducing active work does not necessarily reduce total delivery time.

For example, making development faster may have little effect if the completed work then waits several days for review.

Step 4: Look for repeated patterns

A single unusual event may not justify changing a workflow.

Look for recurring patterns across several examples.

A useful observation should describe:

• What happened.
• Where it happened.
• How often it occurred.
• What consequence it had.
• How confident the team is about the cause.
• What should be investigated next.

Avoid jumping directly from “this feels slow” to “we need a new tool.”

Step 5: Prioritise by impact

Not every friction point deserves immediate attention.

A practical prioritisation model considers:

• Frequency: How often does it happen?
• Impact: How much does it affect the workflow?
• Reach: How many people or stages are affected?
• Risk: Does it create quality, security or reliability concerns?
• Confidence: Is the cause supported by evidence?
• Effort: How difficult is the improvement?

A minor annoyance repeated hundreds of times may matter more than a dramatic issue that happens once a year.

Also consider displacement. A change may improve one stage while transferring the work to another person or team.

For a more detailed audit method, see How to Audit a Workflow.

Should you automate the bottleneck?

Automation is often proposed as the answer to slow processes.

It can be valuable, especially for predictable and repetitive work. But automation does not automatically remove workflow friction.

If the process contains unnecessary steps, unclear decisions or unstable rules, automation may make the problem harder to see and more expensive to maintain.

A useful sequence is:

Remove → Simplify → Standardise → Automate

Remove

Eliminate steps that do not create meaningful value or reduce necessary risk.

Simplify

Make the remaining process easier to understand and execute.

Standardise

Define the stable parts of the workflow so that people can follow them consistently.

Automate

Automate the predictable path where it reduces effort, errors or delay.

For example, automating a repeated data transfer may be sensible. But if the data is collected unnecessarily, removing the collection step may be a better solution.

Before automating, ask:

• Is the workflow valuable?
• Are the inputs known and reliable?
• Are the rules stable?
• Can exceptions be handled?
• Can the result be observed?
• Who will maintain the automation?
• What happens if it fails?

The objective is not to automate as much as possible. It is to make the workflow better.

See Should I Automate This? A Practical Automation Decision Guide.

Measure the whole workflow, not just one stage

A bottleneck investigation needs measurements, but the choice of metric matters.

A team may reduce code review time while increasing the queue in testing. It may close more tickets while increasing rework. It may ship more changes while creating more incidents.

A local metric can improve while the complete workflow becomes less effective.

Consider a broader set of indicators:

These measurements should support better decisions rather than become targets that encourage undesirable behaviour.

Productivity is one useful signal, but it should not be treated as the definition of a healthy workflow.

For more on this distinction, see Is Productivity Actually the Right Metric?.

A small improvement can be more valuable than a large tool change

Once a bottleneck is understood, start with a focused intervention.

For example:

Observation: QA repeatedly asks developers for missing test information.

Evidence: Several recent tickets were returned because the environment, expected behaviour or acceptance criteria were unclear.

Possible intervention: Add a small set of required fields to the handoff.

Measurement: Compare clarification requests and time-to-start before and after the change.

This is a better experiment than replacing the entire ticketing system without knowing whether the system is responsible.

A good improvement should have:

• A clear problem statement.
• Evidence supporting the cause.
• A limited intervention.
• A measurable expected outcome.
• A way to check for unintended consequences.

If the change does not improve the workflow, revisit the diagnosis.

The broader concept: workflow friction

Bottlenecks are often visible at a particular stage. Workflow friction is broader.

It includes the small obstacles, delays, interruptions, decisions, handoffs and workarounds that make the complete process harder than it needs to be.

A workflow can be functioning and still be expensive in time, attention and coordination.

At Clunky, I have been developing a broader framework for understanding this problem, including the Workflow Friction Iceberg™, Workflow Friction Pyramid™, Friction Loop™ and a practical approach to identifying and reducing hidden friction.

The central idea is to examine the complete journey rather than optimise isolated tasks.

Start with the flagship guide:

What Is Workflow Friction? Causes, Costs & How to Reduce It

The related guides explore context switching, workflow audits, automation decisions and productivity measurement in more detail.

Final thought

When software delivery feels slow, the instinct is often to increase capacity, add a tool or automate a task.

Those may be the right decisions—but only after understanding the process.

Map the workflow. Observe where work waits. Find the repeated friction. Test the cause. Improve one part of the journey and measure the result.

The most useful optimisation is not always making a task faster.

Sometimes it is making the task unnecessary, making the handoff clearer or making the next step obvious.

Don't optimise the task in isolation. Improve the workflow that connects it to the outcome.