"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:

• Move forward. Do the next right thing, commit, and repeat.
• Get it working, then make it look good. Focus on submitting the form, imperfect as it may be, then refine it.
• Have our backend engineers quickly alter the API as needed.
• Ignore some details in the behavior that aren’t documented and I don’t know if anyone wants.
• 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, move fast, and possibly break things. Which is how I always want to work. I just needed a reset.

Reversing the Problem With Inverted Thinking

Another version of backward-planning is inverted thinking. With inverted thinking, you think from a position of failure. For a day of challenging work, I might ask: “It’s 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.

• Agile