Overcoming Inertia in Tasks and Projects

All projects face unexpected issues.

Ideally, when this happens, the team comes together, figures out what’s going wrong, and adjusts their plan. Maybe they set a new deadline. Or, they may even decide to drop the project if the problem’s too big and it’s smarter to focus on something else.

But things don’t always work out so neatly. Sometimes, a team runs into trouble and just keeps on going the same old way. No one stops to rethink the strategy or suggest a new timeline. Everyone just keeps on with their tasks by inertia.

Then, one issue leads to another, and before you know it, you’re used to the chaos. And that’s when you miss a big deadline and find yourself in a mess because it’s not the first project that’s been delayed.

Let’s talk about why these things happen and how we can stop them before they begin.

Starting with a simple example — and it’s not about coding. Say you’ve got to cut 5 sweet potatoes (I always struggle with those). You grab your knife, not realising it’s a bit blunt, and get to work.

You pick the first potato, and it’s tougher than you expected. But maybe it’s just a tough one. You try another, and nope, it’s definitely the knife. By the time you’re halfway through the third, you know you made a mistake.

Now, the wise would pause and sharpen the knife. Not me. I’m thinking, “I’m over halfway already — I can handle these last two potatoes.” I don’t even consider that it is my darn knife, I will be using it again at some point and I’ll have to sharpen it eventually. I regret not checking it earlier, but hey, two more potatoes, right?

The best time to plant a tree sharpen the knife was twenty years ago.
The second best time is today.

– Chinese proverb (not sure, I saw it on Instagram)

For those who can’t connect with the sweet potato tale, here’s a different scene.

Your colleague picks a task. A small one, supposed to be done in a day. The next day, they show up at the standup meeting, admitting they got stuck and spent a day trying to figure it out. They should’ve asked for help, but it’s only clear now in hindsight. Thankfully, they’re back on track now.

Another day goes by, and at the next check-in, the task’s still not done — hit by a couple more surprises. In retrospect, teaming up with someone the day before would’ve been smart, but they kept thinking the end was in sight, so they didn’t ask. Had they known the struggle ahead, they’d have reached out for sure.

The following day, the task’s still hanging. Almost finished, then bam — a strange edge-case causes a memory leak that eats up hours. They ponder getting help but figure it’ll take longer to bring someone up to speed than to fix it alone. Looking back, it wasn’t as quick as they thought, but the time’s already spent. The team offers to help, but they decline — it’s nearly done, just some unit tests and docs to go. This time, they’re sure they’ve got it right.

In both scenarios from above:

• The first hiccup seemed like a one-off.
• Upon realizing their error, there was regret for not adjusting course.
• Yet, future actions remained unchanged, either because the mistake was deemed a one-off or it felt too late for corrections.

This pattern can unfold over any timescale—from minutes (like with those potatoes) to days (like that small task) to even weeks and months. Here’s a story of my own.

Some time ago, my team took a small project. It was low-risk, a perfect fit for one or two people.

We quickly settled on a strategy, broke it down into tasks, and dove into coding. But as we hit the 80% mark, we realized it was far more complex than anticipated. And complex projects demand a different playbook: thorough design reviews, risk assessments, and heightened scrutiny—none of which we had done.

We had two paths. One was to hit pause on development, draft a design proposal, arrange a review, gather feedback, and then either proceed (if the feedback was minor) or scrap everything and start anew (if the review demanded it). The other path was to keep on going as we were.

You can probably guess—I opted for no change, convinced our initial plan was solid and that second-guessing it would be a waste of time. I also figured we’d already encountered enough issues to have uncovered them all. No more surprises, right? Lol.

To cut a long story short, it took a few more unexpected twists (and sprints) before we circled back, documented everything, and brought more hands on deck.

You might have lived through something similar—like that time someone skipped writing tests for a new feature. Then it crashed production, and everyone thought, “a test would’ve caught that.” You fix it but skip the tests again, thinking, why bother when you’ve just checked it manually?

It’s rather a common issue:

• We should’ve documented it, but I’ve already explained it in a call, and it’s unlikely anyone will ask again soon.
• We should’ve automated that deployment, but I’ve done it manually this time, and we don’t update this product often.
• We should’ve seen that dependency coming, but now that we’ve found it, surely it was the only one.

So, what’s the game plan to combat this inertia?

Set the expectations

Imagine you're setting off on a drive with no map and no clue how long it will take. You pick a direction, hoping the road itself will be your guide.

But what if you make a wrong turn?

You might pass a landmark you weren’t meant to see, or notice that the distance to your destination isn’t decreasing on the road signs. Or perhaps the setting sun raises a red flag because, even though you didn’t know the exact duration, you certainly didn’t expect to be on the road all day.

Discovering mistakes like this can be a slow and costly process.

That’s where expectations come into play. And I’m not just talking about the big-picture journey, but also the smaller, interim milestones along the way, and when they’re supposed to happen.
Sure, you might wonder if a detailed roadmap is necessary with all the risks and uncertainties involved. But at the very least, you should have an idea of what the next leg of the trip looks like and when you expect to reach it.

It’s not about micromanaging every step; it’s about having enough foresight to recognise if you’re off course and need to adjust your trajectory.

Schedule the check points

Having a roadmap is one thing, but what's the point if you never check it?

Imagine you’re working on something, heads down, deep in the zone. You’ve got your code, you're progressing, all looks good. But if you never stop to ask, “Are we still on track?” you might miss the signs that you’re going off course.

To prevent it, begin your day by outlining what you aim to achieve and how long you expect it to take. Then, set the rules on when you’re going to assess the progress. If you expect something to take two hours – put a timer to assess your work. Are you meeting your own expectations? If something’s taking longer than anticipated, it’s a prompt to reassess and consider adjustments.

This is exactly why many teams have stand-ups or some other form of checkin-in with each other. “How’s it going?” “Hit any roadblocks?” “Need a hand with anything?” – this is exactly how we make sure we’re still on track to meet our expectations and the right questions are being asked.

Act upon surprises

Every surprise, every deviation from what you expected, is a piece of new information. This new information should prompt you to update your knowledge and reassess your actions.

Think of it this way: you set an expectation that performing certain actions (X) over a period (T) will give you a result (Y):

X × T = Y

You follow through with your plan for the allotted time, but Y doesn’t materialize. This is where the learning opportunity lies—you’ve just discovered that X × T ≠ Y.

If you continue doing X as if nothing has happened, you’re throwing this learning opportunity away.

Before deciding on your next steps, you need to understand exactly what happened:

• Did you carry out all the actions you planned?
• Did you dedicate the amount of time you had allocated?
• How does the result you’ve achieved compare to what you expected?

Let’s take an example: suppose there’s a bug in your software that needs fixing, but you can’t figure out how to replicate it. You have a vague idea of which part of the program might be responsible, but you’re not certain what triggers the it. You decide to try out some common scenarios to see if any replicate the issue. It’s a lot of work, but you expect that by tomorrow you’ll either find the cause or rule out your theories.

Tomorrow arrives, and you aren’t there yet.

Per the algorithm above, you review your actions and realize you didn’t stick to the plan. You tested a few scenarios, got sidetracked by a minor bug and fixed it, updated some outdated documentation while testing another scenario, and helped a colleague with a code review. In the end, you only completed a fraction of your original plan (X₁), along with other tasks that didn’t contribute to solving the main issue.

You also notice that you didn’t spend the entire day on the task. Between the work mentioned above (T₁), you attended four meetings, responded to questions on Slack, and installed a mandatory MacOS update.

Looking at the scenarios you tested, you see you’ve only covered about a quarter of what you intended (¼ Y).

In essence, you did X₁ * T₁, where X₁ and T₁ are only subsets of initially planned X and T. With that, it comes with no surprise that you didn’t achieve Y.

This is the critical moment when inertia can take hold.

You might think the plan is still sound and you’re on the right track. Yesterday was just a bad day, and you didn’t put in the effort you intended. But today, you assure yourself, will be different—you’ll stick to the plan and identify the bug by day’s end.

However, it’s important to question what will make today more successful than yesterday. Weren’t you just as committed to the plan as you are today? Didn’t you intend to spend the whole day on the bug?

So, what will you do differently this time? How will you safeguard the time allocated for bug hunting? How will you stay focused and avoid distractions? If you still have three-quarters of the scenarios left to test, you’ll need to find a way to accomplish three times as much as yesterday. And if you’re not planning any adjustments, perhaps it’s time to reconsider your estimates.

Create a safe atmosphere

Safe atmosphere is essential because without it, the strategies we’ve discussed are unworkable. People must feel free to make mistakes and admit when they’re wrong.

In all places I worked, it was always okay to admit not knowing something, ask for help, or acknowledge a misstep. But I know that not all environments are like this. In places where blame is common, people might conceal their errors, perhaps by padding their estimates to create a buffer for unseen issues. This approach might work for self-detected errors, but it falls apart when others point out the mistakes, leading to defensiveness rather than constructive dialogue.

There’s a wealth of advice for leaders on fostering a safe environment. You’re likely familiar with the basics:

• Begin from admitting your own mistakes and knowledge gaps.
• Practice blameless conversations.
• Help people to see the value in feedback and how it helps them reach their goals, fostering a willingness to adjust.

But what if you’re not in a position to shape your team’s culture?

It’s a tough spot, but there are still ways to course-correct openly without casting it in a negative light. One method is to explicitly plan for problems.

Say you’re assigned a task you expect to complete in a day. If that day passes without progress, asking for help can be scary in a blame-heavy atmosphere. It’s easier if you’ve set the stage for assistance by initially stating you’ll assess the problem and involve others if it’s more complex than anticipated. The same goes for larger projects – schedule regular assessments with the intention of refining your approach if you find a better one.

Does this change the reality of the situation? Not really. But it reframes adjustments from being the result of failure to being an integral part of the plan. If the chosen approach doesn’t pan out, that’s precisely why you planned the assessment.

Help others out of the progress trap

When you’re deep in work, it’s hard to realise you might be off track. You’re in the thick of it—solving problems, slaying dragons, and pushing forward. It all happens so gradually, it feels like progress. But remember, just because you’re moving doesn’t mean you’re heading in the right direction.

The first principle is that you must not fool yourself—and you are the easiest person to fool.

– Richard Feynman (but I also saw it on Instagram)

We set expectations and checkpoints to help us assess our progress and spot when we’re going astray. But it’s this very act of planning and assessment that can be uncomfortable. It’s easier to avoid asking the tough questions and to keep on ‘progressing.’ To jump into coding without a plan, because then, anything you do seems like progress. Or to make a plan but never really check your results against it, because “plans are useless, planning is indispensable.”

If you notice teammates falling into this trap, step in with some helpful questions:

• “When do you expect to finish X?”
• “Now that we’ve had this setback, do you think X will still be done by Y date?”
• “What’s the goal for today?”

And don’t forget to share your own plans and progress. It helps set a standard and encourages everyone to think about whether they’re really moving forward, not just moving.

Final words: know when to stick to the plan

While it’s important to be agile and responsive, there’s also benefits in holding steady with your plan. Constantly changing directions can be just as counterproductive as not changing at all. It’s about finding that sweet spot.

You’ll face problems and delays; that’s inevitable. The key is to know which issues are just bumps in the road and which ones signal a need for a real change in plans. And that’s not easy.

Why? Because it all rests on how solid your estimates are. If you’ve got a good handle on your timeline, you can tell whether a new problem is something you’ve already accounted for in your plan. If it is, then keep calm and carry on.

But estimating is a task in itself. We start off optimistic, get a reality check, and then swing to overly cautious. To get better at it, consider these steps:

1. Estimate with probabilities: outline the best, worst, and most likely scenarios. This helps you stay grounded and prepares you for potential issues.
2. Review after completion: once you finish a task, compare the outcome with your estimate. This reflection helps improve your future predictions.
3. Respect the history: don’t ignore your past performance. It’s the most reliable data you have. Aim to do better, sure, but base your plans on what you’ve actually achieved before.

Remember, planning and doing are different modes of thinking. You need a wide lens for planning and a narrow one for doing. That means you’re not always in the best position to question the plan when you’re in the middle of the work.

The good news? If you’ve set clear expectations, checkpoints, a plan for surprises, and fostered a safe environment, you’ve built a strong defence against unnecessary changes. Stick to the plan, adjust when you must, and keep moving forward.