Tags: flow

RSS - Atom - Subscribe via email

Intentionally interrupting momentum and limiting flow

Posted: - Modified: | productivity

You know how when you get going on something, you want to keep going? It’s a great feeling. You’re in the flow, you’re in the zone. Time passes unnoticed. You’re getting stuff done.

I don’t trust that feeling. At least not all the way.

Here’s what got me thinking about this: I had just finished sketchnoting a book. It was fun. I felt accomplished. I wanted to do another sketchnote. In fact, I had already returned the previous book, picked another book from the shelf, and settled in for more drawing.

Then I stopped and asked myself, Is this really what I should be doing next? I was basking in the glow of people’s appreciation on Twitter and I already had all my tools set up for doing the next book, so it made sense to do another sketchnote. But was that really the best use of that moment?

More of the same, or something else?

I still stay up too late programming sometimes. I still spend hours reading. I still write my way past lunch, snapping out of the trance, suddenly starving, late in the afternoon. But I’m getting better at paying attention when part of me pipes up with weird questions.

I dug deeper and found these sub-questions that help me evaluate whether to continue or whether to switch, and what to do next:

  • Am I at the point of diminishing returns or temporary saturation? It’s like the way that if you’re eating your favourite food, there’s a point after which you don’t enjoy it as much. Sometimes giving it a bit of a rest lets you appreciate it more.
  • What could I be neglecting if I focus on this, both in terms of things I need to do and things I want to do? Am I better off spending time with W-, taking care of things around the house, or learning about things that don’t currently give me the same thrill?
  • Is there value in letting this simmer and blend? I can crank out a lot of similar things quickly. Or I can give myself time to learn from people’s feedback and my reflections on process, so that I improve more with each step. Sometimes different things mixed together result in interesting flavours and textures, like the difference between a purée and a stew.
  • It’s easy to do more, but what would enable me to do better? How can I step back and improve the infrastructure for future work? Infrastructure is not exciting, but it’s good to do. It helps to think about specific ways to make something better. What could better mean?
    • Faster?
    • Deeper?
    • Broader?
    • More consistent?
    • More focused?
    • More aligned?
    • More engaging?
    • With better chunking or flow?

Sure, sometimes I’ll lose myself coding or writing or drawing. But sometimes it’s good to interrupt my momentum and ask: What’s important to do, even if it’s not currently as shiny or as fun as what I’m doing?

Do you do this too? What have you learned? What questions do you ask yourself to help you decide what to do next?

Related posts:

Sketchnote Lessons: Arrows and Connectors

Posted: - Modified: | drawing

You can use use arrows or connectors to guide people through your sketchnote/drawing. Here are some samples:image

For more drawing tips, check out the other sketchnote lessons!

Bug-hunting spreadsheets

| geek, ibm, work

There’s a certain delight in working on obscure problems. In my case, I was trying to debug an old spreadsheet that statistically analyzed survey responses in order to match them to innovation archetypes. It started when I noticed that a few chart labels were incorrect. In the process of trying to figure that out and make handling multiple survey responses easier, I ended up deep in Visual Basic code, untangling algorithms that didn’t make complete sense to me.

The spreadsheet had been created three years ago, and it was hard to track down people associated with the project. Documentation was practically non-existent. Working with the source code, sprinkled comments, and formula auditing tools, I figured out what was going on.

So I knew what the code did, but I wasn’t sure it did what it was supposed to do. I asked two team members and a third consultant to refer me to someone who could explain the manual procedure and provide the missing information. If I could figure out how to do the analysis by hand, I could find the bugs and update the spreadsheet.

Even if we end up discarding the tool, I had fun following the logic through the code. There’s something about understanding a small piece of the puzzle well, and then expanding your understanding until you can hold the program in your mind.