"What Would Finishing This Today Look Like?"

When I don’t feel like I’m making sufficient progress at work, I have a favorite technique: asking “What would finishing this today look like?”

It’s a version of one of Tim Ferriss’ favorite questions:

“‘What would this look like if it were easy?’ If I feel stressed, stretched thin, or overwhelmed, it’s usually because I’m overcomplicating something or failing to take the simple/easy path because I feel I should be trying ‘harder’…”

Recently, I was building a complex web form, with brand-new APIs, in a sophisticated SPA, with scant and conflicting stakeholder input. I’d been slogging through requirements-gathering for days, and yet felt like shipping was still far off. So, I asked: “What would finishing this today look like?” I answered with backward-planning: start at the finish line and work backward to now.

At the finish line, I’m deploying the feature for acceptance before the end of the day, about 4 PM. That will give me time to ensure it’s deployed, test it, document details, deliver the work, and maybe address feedback.

Before that, I need it to pass code review. That won’t be a bottleneck, happily. My team reviews quickly, we’re synced on execution, I preempt nitpicks by reviewing my code, and I attach screenshots so that I can get instant design feedback. But maybe I’ll merge with one review, not two or more.

Before that, I need to finish the feature. This is where I’m stuck! To be easy, I’d need to:

  1. Move forward. Do the next right thing, commit, and repeat.
  2. Get it working, then make it look good. Focus on submitting the form, imperfect as it may be, then refine it.
  3. Have our backend engineers quickly alter the API as needed.
  4. Ignore some details in the behavior that aren’t documented and I don’t know if anyone wants.
  5. Write some basic automated tests. This lets me iterate and respond to feedback knowing I’m not breaking everything.

Visualizing this gives me a concrete checklist. It helps me to be proactive, over-communicate, sidestep middlemen, do things right the first time, abandon busywork, and move fast. Which is how I always want to work.

Reversing the Problem With Inverted Thinking

Another version of backward-planning is inverted thinking. With inverted thinking, you think ahead about a day of challenging work, imagining that you failed. “It’s now the end of the day and I didn’t ship. What happened?”

Some possible answers:

  • I moved backwards or started over.
  • I make it look good before getting it working, and built beautiful and incorrect thing.
  • I waited too long to ask for help.
  • I focused on behaviors nobody wants and edge cases that don’t matter.
  • I didn’t write tests and found silly bugs during smoke testing.
  • Some crucial platform (GitHub, AWS) was offline for much of the day.
  • I was distracted or unfocused.

I’m sure you can write your own failure scenarios! With this list, you can take each one and reduce or eliminate them as a concern. And ship today.