Why busy teams still move slowly, and how leaders can diagnose where speed gets lost.
A team can look fast from the outside.
Standups, refinements sessions, planning, and retrospectives happen. Pull requests are merged. Tickets move across the board. People answer messages, join meetings, solve problems, and share updates.
No one looks idle. No one looks careless. Everyone seems to be working.
And still, progress feels slow.
The important feature takes longer than expected. The decision that should have been simple keeps returning. Feedback arrives late. Dependencies appear after the plan was already made. Work moves forward, then comes back as rework. The team is active, but the outcome is delayed.
That is the speed illusion.
It happens when activity creates the impression of speed, but valuable work is still losing time inside the system.
In a previous GC Insights article, I introduced the four dimensions of balanced engineering leadership: value, speed, quality, and sustainable execution.
This article takes a deeper look at speed, especially the illusion that activity always means meaningful movement.
The problem is not always lack of effort. Many teams moving slowly are full of committed people. They care. They are trying. They want to deliver.
But effort alone does not guarantee flow.
A team can be busy inside a slow system.
Speed is often misunderstood
In software engineering, speed matters.
Slow execution has a cost. Opportunities are missed. Feedback arrives too late. Customers wait. Stakeholders lose confidence. Teams lose energy because every step feels heavier than it should.
But speed is often reduced to the wrong question: Are people working fast enough?
That question can be useful in some situations. Performance, ownership, discipline, and accountability matter. But when it becomes the only question, leaders may miss the real source of slowness.
Sometimes the team is not slow because people are avoiding work. The team is slow because progress keeps waiting for clarity, decisions, feedback, dependencies, or quality recovery.
The calendar is full. The board is full. The conversations are frequent.
But the system is full of friction.
Real speed is not the same as pressure, urgency, asking people to attend more meetings, write more updates, or carry more work at the same time.
Real speed is the ability to turn important ideas into working outcomes without unnecessary delay.
That requires more than effort. It requires flow.
Where valuable work loses time
When delivery feels slow, the visible symptom is usually easy to name.
The feature is late. The initiative is blocked. The team is carrying work from one sprint to the next. The roadmap is slipping. The release is harder than expected.
The harder part is diagnosing where speed was actually lost.
It may have been lost before development started, when the team knew what needed to be built but the value was not clear. Without that context, technical decisions become harder, trade-offs become less obvious, and people may optimize for completeness, elegance, or local preference instead of impact.
It may have been lost in the size of the work. When scope carries too many unknowns, the first meaningful step is hard to see. The team tries to move a large block of uncertainty through the system, and progress naturally becomes heavy.
Decisions are another common source of delay. A technical direction keeps returning to discussion. Product trade-offs remain open. Ownership is unclear. The team continues refining, preparing, or debating because no one knows who can make the call.
Dependencies create a different kind of drag. Another team needs to provide input. An approval is required. An environment is not ready. A stakeholder needs to review something. None of these delays may look dramatic in isolation, but together they slow the work down.
Feedback can also arrive too late. The team works for weeks before learning that an assumption was wrong, that a user flow does not work in practice, or that integration is more complex than expected.
And then there is rework. A change may look fast at first, but come back through defects, incidents, unclear acceptance criteria, fragile code, or support interruptions. What looked like speed becomes another form of delay.
This is why speed can be deceptive.
A team may look active while valuable work is quietly losing time in places that are not immediately visible.
The better leadership question
When teams are slow, leaders naturally want movement.
That is understandable. Business problems, customers, and competitors do not wait. Strategy depends on execution.
But asking for more speed without diagnosing friction can create more pressure without creating more progress.
The better question is: Where is valuable work losing time?
That question changes the conversation.
It moves the focus from blame to diagnosis. It helps leaders look beyond individual effort and examine the conditions around the work. It also gives teams a better language for explaining why progress feels heavier than it should.
The goal is not to remove accountability. It is to make accountability more practical.
Once friction is visible, the team can decide what needs to change.
The Speed Friction Scan turns that question into six places to look.
The Speed Friction Scan
When delivery feels slower than it should, one practical habit is to scan for friction before increasing pressure.
It is not about creating another heavy process. The goal is to make the invisible drag visible enough to act on.
Here is a simple scan leaders and teams can use.
- Value friction
Do we know why this work matters?
Value friction appears when the team understands the request but not the outcome behind it.
The ticket may be clear. The business reason may not be.
Signals include vague priorities, weak product context, unclear success criteria, or technical work disconnected from business impact.
A useful leadership question: What should become better because this work is delivered?
That question helps the team connect implementation choices to purpose. It also prevents speed from becoming movement without meaning.
- Scope friction
Is the next meaningful step small enough to move?
Scope friction appears when work is too large, too vague, or too full of unknowns to progress smoothly.
The team may spend a long time refining, estimating, discussing edge cases, or waiting until everything is clear enough to start.
A useful leadership question: What is the smallest meaningful step that would create learning or progress?
This does not mean splitting work into artificial pieces just to move tickets. It means reducing the size of uncertainty so progress can become visible sooner.
- Decision friction
What decision is blocking movement?
Decision friction appears when the work cannot move because a choice has not been made.
The decision may be technical, product-related, organizational, or strategic. The pattern is similar: people keep discussing the topic, but ownership is unclear or the decision keeps being postponed.
A useful leadership question: Who owns this decision, and what information is enough to decide?
Not every decision needs perfect certainty. Some decisions are reversible. Some need stronger validation. Leadership judgment is knowing the difference.
- Dependency friction
What are we waiting on?
Dependency friction appears when progress depends on another person, team, system, vendor, approval, or environment.
Some dependencies are real and unavoidable. Others exist because the organization has designed work in a way that creates unnecessary waiting.
A useful leadership question: Can we remove, reduce, or expose this dependency earlier?
Dependencies do not always disappear, but they should not remain invisible until the team is already stuck.
- Feedback friction
How quickly do we learn whether we are right?
Feedback friction appears when the team discovers important information too late.
The work may be technically complete before users see it. Stakeholders may review it only near the end. Integration issues may appear after assumptions have already shaped the solution.
A useful leadership question: What feedback can we bring closer to the work?
Faster feedback reduces the cost of being wrong. It also helps teams make better decisions while change is still cheap.
- Rework friction
What are we calling speed today that may become rework tomorrow?
Rework friction appears when the team moves quickly in a way that creates future delays.
This can happen through weak acceptance criteria, poor test coverage, unclear ownership, fragile code, rushed reviews, or shortcuts that create incidents later.
A useful leadership question: Are we moving fast, or are we borrowing time from the future?
This is one of the most important speed questions in engineering. Some shortcuts are reasonable trade-offs. Others only move the delay to a more expensive moment.
How to use the scan
The Speed Friction Scan can be used in regular software engineering delivery routines. Planning sessions, retrospectives, pre-mortems, and post-mortems are natural fits.
In refinement, it helps the team check whether the work has enough value clarity, whether the scope is small enough to move, and which dependencies need attention before they become blockers.
In planning, it helps leaders and teams identify where work is likely to wait.
In retrospectives, it gives the team a way to move beyond general statements like “we had too many blockers” and name the specific type of friction that slowed delivery.
It can also improve technical discussions. If a conversation keeps looping, the issue may not be the technical complexity itself. The team may be missing decision ownership, enough information to decide, or clarity on the trade-off that matters most.
In stakeholder conversations, it can help separate team-level delays from system-level delays.
That distinction matters.
When leaders treat every delay as a team performance problem, they may create frustration instead of improvement. When teams treat every delay as someone else’s fault, they may avoid ownership.
The scan helps both sides have a better conversation.
What is within the team’s control? What needs leadership support? What requires stakeholder alignment? What should be simplified, escalated, or decided now instead of discussed again next week?
Speed improves when these questions become part of how the team works.
When diagnosis changes speed
I have seen this pattern in practice.
In one team, improving speed did not start with asking people to work faster. It started with making the system around the work clearer.
We defined value more explicitly. We created a clearer delivery plan. We made expectations visible. When problems appeared, we used the Clarity, Competence, or Courage Diagnostic to understand whether the real issue was unclear direction, missing capability, or an avoided conversation.
We also worked on team identity and ownership.
Over time, the result was not only better throughput. In that context, the team started delivering roughly twice as much in about half the time.
But the most important change was not only the delivery number.
Stakeholder perception changed. Trust increased. Conversations became less about whether the team would deliver and more about what the team could help unlock next. The team’s satisfaction with the work also increased.
That is the part of speed that is easy to underestimate.
When friction goes down, confidence goes up.
Not because people suddenly become committed.
Because their commitment finally creates visible movement.
What slow movement does to teams
Speed is not only a delivery concern.
Slow movement has a human cost.
When work keeps getting stuck for reasons no one names, committed people become frustrated. Engineers are asked to move faster while priorities, decisions, dependencies, or expectations remain unclear. Over time, this can reduce ownership because people stop believing their effort creates movement.
The strategic cost is just as real.
A strategy that cannot move through execution remains an intention. If important work waits too long, the organization learns too slowly. Opportunities pass. Risks grow. Plans become outdated before they become real.
Execution gets heavier too.
The team needs more coordination, more re-planning, more status updates, and more emotional energy to move the same work forward.
This is why speed needs a mature leadership lens.
Speed is not about celebrating busyness.
It is about helping valuable work move with clarity, focus, feedback, and quality.
From pressure to better movement
The speed illusion is attractive because activity is easy to see.
A full calendar looks serious. A full backlog looks important. A full board looks productive.
But engineering leadership cannot stop at what looks active.
A more useful perspective is to ask whether important work is moving through the system in a healthy and meaningful way.
That can lead to practical but uncomfortable choices.
Reducing priorities so the team can focus.
Making decision ownership explicit.
Questioning dependencies that have become normal.
Improving technical quality so the team stops paying for the same problems repeatedly.
Naming when the team does not need more pressure, but less friction.
Strong leaders do not only ask teams to move faster. They help teams see where speed is being lost. Then they improve the system so meaningful work can move with more clarity, trust, and consistency.
People contribute better when the system allows their effort to create movement.
Strategy becomes stronger when important work reaches reality before the opportunity disappears.
Execution becomes healthier when speed comes from flow instead of pressure.
That is the shift behind the speed illusion.
It is not about looking fast.
It is about helping valuable work move while there is still time for it to matter.