Pausing, Logging and Keeping Up Momentum

A funny thing happens after a goal is reached sometimes - you naturally withdraw for some head clearing time. I've noticed this in my intellectual freedom zone that is my start-up. I'm motivated and pushed by my own actions and interests, so there's nobody else telling me what to do.
When I manage development groups, I'll usually do something following an accomplishment, take the group out to celebrate, skipping off an afternoon. Larger milestones often schedule a lessons-learned meeting to chat, vent and capture best practices. Even though there is much still to do, there's benefits of doing this take a breather approach.
I notice it in this free-form development work too. As I attain a goal, I seem to pull back and do some tidying, and do some big picture thinking. There's no shortage of next steps still required, but one seems to mentally need a bit of perspective after climbing a mountain.
That analogy is pretty good - it is like climbing a steep hill. When you reach a plateau on the way up, you tend to stop and take a breather in preparation for the next steps.
A downside though can be that it is sometimes tough to get back into the flow again. One should ensure that they know what the next steps are rather than waiting idly for divine inspiration. Just like the other development steps are planned, so should be your pauses and your re-engagements.
A technique that seems to work for me is to get back into the work by leading with to-do lists. I'm using this approach quite heavily. The rule of thumb is - if you're pausing, make a short next steps list in your log book or worklog file/blog/etc. It really has helped with productivity boosting, as you tend to make an effort to close off all the outstanding items before your next pause.

I run two worklogs these days - one is a private blog, the other is a text file in my core development area. When I'm working in the Eclipse environment I have a WhereAmI file that gets continually updated, in a very prosaic style. There I will often capture thought processes in trying to fix a problem, outlining my thoughts, the sections of code that are likely involved, even variable names and routine() names that are key. The result is that if I pause for some reason, I can quickly recover the area of activity. As well, I can recover the thought process I was going through.
The ancillary benefit is that the act of describing a problem will often evoke the solution. We see this as young engineers and scientists, talking to our mentors or supervisors. As we would start to describe an insoluble problem, you would come upon the answer half-way thru, and feel embarrassed for having brought it up. Later, I learned to have mock gripe conversations in my head to see if that turned up the solution, and often it would. The logfile/book does the same thing.
The file is also searchable, as is the private blog of course. The blog worklog I use for my other notes. Development that is not specifically in the Eclipse milieu, but also business building work, and broader interactions.

So those are just a few thoughts on managing the pauses, the tools associated with re-engaging, and not losing the threads of your engagement. Perhaps I should now turn to my task list at hand and try to make some progress following this last milestone achievement.

Researchinator reaches for the oars to find that they are still attached, functional and ready for action...