Target Fixation: The Silent Killer of Software Projects

You've all seen Top Gun. Maverick chases Jester and gets so focused on trying to win that he violates the rules of engagement. You might think that it's just a movie. But real life is worse. Much worse.

Nearly every combat aviator has a story similar to this:

I was tight on my opponent’s six, matching every maneuver, staying locked through turn after turn. I almost had tone when suddenly my controls went dead.

The instructor had taken over. We were banking hard away from the fight. I was about to protest until I heard her. Bitchin’ Betty, screaming at me over a cockpit full of alarms.

I was bingo fuel, below the hard deck, and my opponent’s wingman had a solid lock. I was already dead. I just hadn’t noticed yet.

Sounds crazy. How could he not notice?

Yet your team is experiencing this phenomenon every day.

Worse yet, it's killing your project.

What is Target Fixation?

A developer joins the stand-up and says, “The story is going well. Almost done.”

The next day, they say the same thing. And the day after that.

They’re not slacking off. They’re deep in the code, working hard, fighting with a problem they’re convinced is just one step away from being solved. Every small victory feels like proof that they’re getting closer. But as the days pass, the fixes get messier, the code more fragile, and the original design harder to recognize.

The more they struggle, the more convinced they become that they’re nearly there. Each small change feels like confirmation that success is imminent, even as the overall system moves further from stability. What started as a focused effort turns into a slow-motion crash of motivation and clarity.

They’re so focused on finishing, they’ve stopped evaluating their approach.

What’s happening isn’t laziness or incompetence. It’s target fixation.

Hours get sunk into a solution. Quitting feels like failure. The closer we believe we are to done, the harder it becomes to step back and question our approach.

Target fixation traps developers in a loop of diminishing returns. It narrows attention, kills perspective, and discourages the one thing that could actually resolve the problem: stepping back to re-evaluate their approach.

Why Does it Matter?

Let me tell you about a high-performance team.

They committed to an aggressive sprint. Custom reporting work they’d never done before. The Product Owner helped them break it into simple, incremental steps. Each milestone delivered something usable. Even a partial sprint would have been a win.

The sprint launched like a rocket. The team tore through the backlog, completing stories faster than expected. Momentum was high. Confidence even higher. For a moment, it looked like they might exceed their goal. A huge win if they could pull it off.

Then, midway through the second week the pace faltered. Progress slowed. Bugs began appearing. The clean, elegant code that defined their early work was starting to fray. By the end of the sprint, they’d actually delivered less working software than they’d had at the halfway point.

In the retrospective the pattern became clear. Their early speed had come from constant refactoring — keeping the code simple and nimble after each feature. But as the finish line came into view, they stopped. They believed they were “almost done.” So they pushed forward instead of cleaning up.

Those last features tangled with the existing code, introducing regressions that forced rework and broke prior functionality. The harder they pushed, the worse it got.

If they’d stayed disciplined, kept refactoring and maintaining clarity, they would have finished strong. But fixation took over. The moment they believed they were “almost done,” they stopped flying the plane.

Understanding the Impact

The team in our story understood their problem. They knew they screwed up and took steps in the future to prevent this mistake. But that's not how most of us experience the problem.

Teams assume that taking a long time is normal. And so the burndown is more of a burn line with a dip at the end. That dip is where the team tries to get something out the door at the end of the sprint. Often of a lower quality.

Developers know this doesn't look good to management. They each take multiple stories "in progress" to work on something else whenever they get stuck on one.

Developers are being intelligent. It is a workable strategy. It's not a winning strategy, but the best a developer can do on their own.

Teammates can't help because they have 3 to 5 stories of their own.

Strategies for Fixing Fixation

The first step is to recognize that you and I are unlikely to detect target fixation on our own. We need a partner who's not down the rabbit hole with tunnel vision. Someone to maintain the big picture and tap us on the shoulder when we need it.

We need to lean into the power of the team.

Stop taking on multiple stories and focus on delivering one at a time.

Focusing on a single story opens two practical strategies for breaking fixation:

1. Trigger a swarm when a story takes longer than expected
2. Pair developers so one person can focus while the other maintains perspective

Let's look at these options in more detail.

Detect Off Track Stories

Contrary to popular belief, it is possible to know when a story is running late. It requires a bit more tracking, but the tracking can be well worth it. Especially if it gives us more visible data for our retrospective.

The missing data is a prediction of how long the story will take. Before you start the story, have the developer predict how many days it will take them. The following table can give team members confidence in their prediction.

Size	Time Range	Story Points
Small	1–2 days	3
Medium	3–4 days	5
Large	5 days	8

If the story goes longer than expected and the developer is confident, give them one more day. Then trigger a swarm at the next standup.

Pros: We can react to developers being off track within a day of when they should be done. New data that can be analyzed during retrospective.

Cons: Requires additional tracking. Doesn't detect the problem until enough time to complete the story has been expended.

Pair Developers

Pair Programming can be a highly effective technique for improving code quality. Unfortunately, many managers don't want to commit duplicative resources. And there's no guarantee that both developers together won't end up with the same tunnel vision.

One method of addressing this problem is to pair development and QA instead. Rather than having both developers focus on coding, have one of the developers perform formal testing as the coding developer checks in changes.

This approach encourages continuous integration and works especially well with Trunk-Based Development.

Critically, the developer performing QA can notice when the quality drops or check-ins stop happening. They can intervene immediately to stop fixation. And suggest alternative approaches from a "big picture" perspective.

Pros: Detects fixation much earlier and provides an immediate resource to solve.

Cons: Reliant on the skill of the QA developer and willingness to intervene.

The Right Solution for You

The best solution is to use both techniques. Pairing becomes your first line of defense, back-stopped by a process that forces a swarm before it's too late. The back-stop and additional retrospective data give team members experience in detecting the problem earlier, making pairing more effective over time.

This approach of using interlocking approaches is recommended by the Momentum Agile Process. Consider this process if you're interested in doing both.

If you must choose one, consider the skill level of your team. If your team is highly skilled and effective at delivery, use the pairing approach. It will be effective at avoiding fixation—further amping up their delivery.

In all other cases, forcing a swarm is the most reliable option. Even if you don't ask for a prediction before the story is started, you can use the table provided to know the maximum amount of time you should wait before triggering a swarm. Team members will come to recognize target fixation and learn to work together to avoid it.

Conclusion

Target Fixation is a dangerous trap for software developers.

It destroys teams and projects — but only if we let it.

We know the solution: Teamwork

Now use it.