Paul Farry Blog

Musings and Discoveries whilst developing systems

The Two Rabbits Problem: Why Software Teams Should Chase One Rabbit at a Time

There is an old lesson:

If you chase two rabbits, you catch none.

The reason is simple. The moment you split your focus, neither pursuit receives the attention required for success. As you change direction towards one rabbit, the other gains distance. Then, when you switch back, the first has already disappeared.

The result is predictable:

Two pursuits. Zero captures.

However, if you focus on one rabbit, catch it, and then pursue the second, you eventually end up with both.

This simple analogy has a surprisingly powerful application in software engineering, project delivery, and operational improvement.

The Software Engineering Version

Software teams often fall into the trap of chasing multiple rabbits simultaneously.

A project encounters issues in production. At the same time, the team wants to:

Each initiative may be worthwhile. The problem is not the individual goals.

The problem is attempting all of them at once.

What starts as a focused effort quickly becomes fragmented:

Eventually nobody knows which change fixed the problem, which change introduced a new one, or why the system behaves differently from last week.

The team is now chasing two rabbits.

Or five.

The Cost of Divided Attention

When multiple significant changes occur together, several risks emerge.

Increased Complexity

Every additional change creates more variables.

If an issue appears after ten changes are deployed together, identifying the root cause becomes significantly more difficult than if a single change had been introduced.

Slower Learning

Teams learn by observing outcomes.

When multiple changes are introduced simultaneously, cause and effect become blurred.

Did performance improve because of the infrastructure upgrade or because of the code optimisation?

Nobody knows.

Higher Risk

Bundling changes compounds risk.

Even if each change individually carries low risk, their interactions can create unexpected failures.

Reduced Confidence

When deployments become unpredictable, teams lose confidence in releasing software.

Engineers become hesitant. Approvals become slower. Releases become larger.

The cycle reinforces itself.

Catching One Rabbit First

Effective engineering teams recognise the value of isolation.

Instead of making five significant changes simultaneously, they address one objective at a time:

  1. Identify the highest-priority problem.
  2. Implement the minimum change needed.
  3. Deploy and observe the result.
  4. Validate success.
  5. Move to the next improvement.

This approach often feels slower.

Ironically, it is usually faster.

By reducing uncertainty, teams spend less time debugging, less time rolling back deployments, and less time debating what actually happened.

A Real-World Example

Imagine a service suffering from authentication failures.

The team proposes:

All sensible ideas.

But which rabbit are we chasing?

If the goal is to reduce authentication failures, then that should be the only rabbit.

Solve the authentication issue first.

Once stability is restored:

Each step delivers measurable value and creates a clear understanding of outcomes.

The Hidden Trap: “While We’re Here”

Many software projects fail to follow this principle because of a phrase that sounds perfectly reasonable:

“While we’re here, we might as well…”

While we’re upgrading Java, let’s modernise logging.

While we’re changing logging, let’s introduce OpenTelemetry.

While we’re introducing OpenTelemetry, let’s redesign deployment pipelines.

While we’re redesigning pipelines, let’s restructure the application architecture.

Before long, a small change has become a strategic transformation program.

The original rabbit has disappeared into the bushes.

Focus Creates Momentum

The most effective engineering teams are not necessarily the teams that do the most things.

They are the teams that finish things.

Every completed initiative creates:

Each successful rabbit captured makes the next one easier to pursue.

Final Thought

The Two Rabbits Problem is ultimately a lesson in focus.

In software engineering, the temptation to solve multiple problems at once is constant. New technology, technical debt, operational improvements, and feature requests all compete for attention.

But whenever a team finds itself struggling to make progress, it is worth asking a simple question:

Which rabbit are we actually chasing?

If the answer is more than one, there is a good chance that you will catch none.

Focus on one objective.

Deliver it properly.

Learn from the outcome.

Then chase the next rabbit.

Eventually, you’ll catch them both.