Hey Reader,

Your team is putting in the hours.

Sprints are tight. Focus is intense. People are grinding.

But the project isn't accelerating.

It's slowing down.

Velocity is dropping week on week.

Rework is increasing.

Dependencies are piling up.

The team feels stuck.

And your instinct is:

• We need to push harder.
• We need more resources.
• We need better tools.

But I want to challenge that instinct.

Because I've rarely seen a project slow down because the team isn't trying hard enough.
Usually, it's the opposite.

And it's one of the most misdiagnosed problems in delivery.

Most leaders see this and think:

The team isn't delivering.

We need better execution.

But the problem is almost never execution.

It's systems, clarity. and blockers that aren't being cleared.

What's Actually Happening

When a team is working hard and moving slow, it usually means one of four things:

1. Work is poorly defined upfront.

The team doesn't fully understand what they're building.

So they build something.

It gets reviewed.

It doesn't match the expectation.

They rebuild.

It gets reviewed again.

Still not right.

Rework compounds and velocity drops.

This is a definition problem, not an execution problem.

2. Dependencies aren't being managed.

Your team needs input from another team.

That team is slow to respond.

So your team waits.

Or they build assumptions that turn out wrong.

Then they have to rework.

One bottleneck upstream cascades into slowdown everywhere.

3. There's too much context-switching.

The team is working on five different things because priorities keep changing.

They're context-switching constantly.

Research shows that context-switching costs you 40% of productivity.

So they're working hard, but their effort is scattered.

4. They're blocked by decisions that aren't being made.

The team needs a decision from leadership.

That decision sits in someone's inbox for three weeks.

The team waits.

Or they make an assumption.

Then the decision finally comes and the assumption was wrong.

They have to rework.

Any of these creates the pattern: hard work + slow progress.

I worked with a team once that was in this exact situation.

They were building a platform update.

• Weeks 1-4: Team is enthusiastic. Velocity is good. Everyone's excited.
• Weeks 5-8: Work is getting done, but feedback is coming back and changing direction. Rework starts.
• Weeks 9-12: Team is putting in long hours. But velocity is dropping. Rework is increasing. Morale is sliding.

By week 12, people are burnt out and the project is further behind than it was in week 5.

I remember sitting in a standup around week 10. Someone made a joke that fell flat.

Nobody laughed.

That's when I knew the system was breaking the team.

The Three Issues:

1. Early requirements were vague.

So they'd build something, feedback would come back, and it wouldn't be right.

2. Priorities were changing weekly.

One week Feature A was critical.

Next week Feature B was critical.

The team was context-switching constantly.

3. Decisions on infrastructure were pending.

The team couldn't finalise their technical approach until a decision was made.

That decision took eight weeks.

How To Spot It Early

Week 1-4:

Notice: Is velocity consistent or dropping?

If it's staying strong, you're probably fine.

Week 4-8:

Notice: Is rework increasing?

Are you re-reviewing the same features?

Are scope items coming back for revision?

If yes, that's signal #1.

By Week 8:

Notice: What is the team actually blocked on?

Ask them in a retrospective: "What's blocking your progress?"

You'll usually get a clear answer.

It's almost never: "We're not working hard enough."

It's usually: "We're waiting on X decision" or "We're reworking Y" or "We're context-switching too much."

What To Do About It

Step 1: Diagnose the real blocker.

First: Stop assuming it's execution.

Ask your team: "What's actually blocking you?"

Then listen.

The answer will usually be one of the four things I mentioned.

Step 2: Fix the blocker, not the effort.

If it's definition:

- Go back and clarify requirements before building.

- Get stakeholder sign-off on what "done" looks like.

If it's dependencies:

- Identify which teams you depend on.

- Establish clear SLAs for their responses.

- Make it someone's job to coordinate.

If it's context-switching:

- Freeze scope. No new priorities until you finish current ones.

- Protect the team's focus time.

If it's pending decisions:

- Identify the decision that's pending.

- Set a deadline for it.

- Escalate if the deadline is missed.

Step 3: Measure the change.

Once you fix the blocker, velocity should improve.

If it doesn't, there's another blocker underneath.

Keep digging.

Step 4: Keep the blocker cleared.

This is the most important part.

Blockers are like weeds.

If you don't keep them cleared, they'll grow back.

Make it someone's job to monitor for new blockers.

And clear them quickly when they appear.

Most teams have capacity.

They have energy.

They have skill.

They have will.

What they often lack is clarity and removal of obstacles.

When a team is working hard and moving slow, your job isn't to make them work harder.

Your job is to clear the path.

Remove the obstacles.

Clarify what done looks like.

Manage dependencies.

Protect their focus.

Do that, and the same team that looked stuck suddenly accelerates.

Because they weren't stuck.

The system was.

If you took the assessment and Sign #4 showed up on your project, do this:

Have a team retrospective.

Ask: "What's the main thing blocking our progress?"

Don't accept "we need to work harder" as an answer.

Dig deeper.

Get to the real blocker.

Then fix it.

Not with more effort.

But with clarity and obstacle removal.

Praying you have a blessed week.

Yom

P.S. Stop blaming the team. The moment you shift from "they're not working hard enough" to "the system is broken," solutions become obvious. And most of them are free.

​​​