Low-tech task and time management

June 25, 2021

I am often asked how I manage my time, tasks, and overall workflow. Spoiler alert, I do not use software. I tried software in the past, but it didn’t make my business more efficient. I developed a different, low-tech approach that works very well for me. It is a variation of time-boxing and is literally just folded pieces of paper. Here is how it works.

For a standard piece of paper: I fold it into thirds along the long axis. I unfold it and then, along the short axis, fold it in half and then in half again. Trace the folds with a pen, and voilà, I have my time-boxing base: 12 boxes. The math nerds probably understand why I took this approach. Base-12 is a better counting system than base-10. In this context, 12 is better than 10 because it divides evenly in lots of ways. This gives me options for various time boxes. This is more apparent when you consider both orientations for the piece of paper (letterbox vs portrait).

From here, I can use the paper in a bunch of ways. My most common use is to create 2, one-week sprints. I fold the paper in half, leaving me two sets of 6 boxes. Each day is a box, with the last box split for the weekend. I always pencil things in, so that I can erase and move them as needed. I literally cross things off as they get done. This allows me to keep the dynamic workflow my business requires.

Here is where this system starts to make sense. Those boxes are pretty small. I can only pencil so much in. So, I plan from a very high level, but also instinctively know when I am putting too much on my plate for one day. I literally can’t fit too much in. The weekend has this effect exaggerated. While I tend to work every day, I tend to get less done on the weekend. Well, my weekend time boxes are half as big. I can only schedule half as much as a regular day.

This concept works particularly well for traveling. Hotels always have pieces of paper, but they are often small. Typically I’ll just have 1, one-week sprint. Even then, the boxes are teeny. That’s perfect because I work from the road but am never as efficient. When I am traveling, I need to focus really hard and limit myself to only the work I can squeeze in. The rest will wait until later. This brings me to macro-time-boxing.

I can use my 12-box layout horizontally to plan a quarter. Each month is a row. Each box is a week. Because months are not a perfect 28 days, I end up, most months, with a few extra days that are “not accounted for”. This helps give me slack in my scheduling. This concept is probably familiar to those with the Theory of Constraints. More or less, I plan in dead space, and it gets filled in by project run-over.

Going even more macro, I can use the layout vertically to plan a year. Again, I can only fit so much into one box, so I can only plan each month from a very high level. If I pencil in 6 or 7 projects for a given month, that month is going to look (literally) very, very full. I find this literal and physical limitation much easier to recognize than any kind of conceptual or even digital solution.

By combining the various layouts, I can have a year, a quarter, and 2 one-week sprints on 3 pieces of paper. This gives me a fantastic bird’s eye view of all three planning timeframes. At the end of every quarter, I create a new quarterly plan but also update my yearly plan. This keeps me constantly thinking about one year from now.

Keep in mind, I use this for all kinds of planning. I pencil in estimated completion dates but also estimated payment dates. This helps me plan my finances. I know how much money I need to earn in any given month. If I have numbers that are too low for any given month, I see that coming weeks or months in advance and prepare for it. This is a part of how I leverage days cash-on-hand in order to challenge the dogma of deposits.

Developer’s note: I use paper-folding for time management as a daily reminder of how I can hone my craft. I often give the advice, “if you want to be a good front-end developer, study geometry. If you want to be a good back-end developer, study algebra. The good news? These concepts go hand in glove.” There is another layer to this idea.

If you want to be a great front-end developer, practice origami. This skill allows us to create structure, by folding and most importantly – folding in the correct order. Here is how it applies to code: CSS is often misunderstood because folks are folding the paper in the incorrect order. In other words – if you are struggling to figure out a layout – stop using CSS. Grab a piece of paper, and use nothing but raw geometry, your brain and your hands to fold that layout into existence. Once you have the layout created via nothing but folded paper, the math and CSS are dead simple. Returning to base-12, we can easily see how this kind of counting applies directly to CSS. Any decent front-end grid will include even widths (say every 5%) but also base-12 (5/12 or 41.6666666%). You can easily achieve these widths via folds and geometry. Before long, you recognize how a very small sample of utility classes can create any page structure. Folding pieces of paper, for time management, reteaches me this lesson, every day.

If you want to be a great back-end developer, play string games, like cat’s cradle. String games are about weaving a single loop of data into endless, unbroken transformations. If you are frustrated by PHP or complex data streams – play string games. You will discover that loops and streams can be altered in multiple ways in order to get from one state to the next. There is no “correct” path but there are some that are more efficient and others that are dead ends.

Let’s take these ideas and stretch them further. What else can origami and string games teach us? Well, WCAG and universal accessibility.

You can go to any culture with paper, and likely find someone familiar with some sort of paper folding game. You can fold the paper once and pass it. The next player makes another fold. So on and so forth, until we have collectively made a shape. A fun game, but it teaches a wonderful WCAG lesson. 1. Not all cultures have paper. 2. Not all people can see the creases in the paper. This is exactly the same as when someone says, “the color contrast seems fine to me”. Great, for you – but what about someone with low-contrast vision? They can’t see the grey and grey any more than they can see the creases in the paper.

String games, however, teach us the real empathy of accessibility. Every culture has string. You do not need to speak a word of each others’ language to initiate the game – just a simple loop of string. Going one step further – string games are fully accessible to someone who can’t see at all. It is incredibly difficult, but you can feel your way through a string game – alone or with a partner. Playing a string game, in this context, teaches us true experienced empathy but also teaches us, we must actually test for website accessibility. Close your eyes, and play a string game. Close your eyes and navigate a website. You just unlocked a series of new skills.

Not to mention – paper folding games are more about moving from one point to another. String games are about a conversation. You need to listen and see someone’s point of view as much as you do anything else. If you are not paying attention to the conversation that happens within a string game, you will send to your partner, a dead end. The game ends, because of your expression to them. In this context, string games give us a lot to think about, when it comes to WCAG. Through this lens, WCAG becomes so much sharper and easier to understand.

Origami and string games have a lot to teach us. Be it empathy, advanced CSS utility classes, API data unpacking or good old fashioned empathy – the lessons abound! Bonus … these concepts keep the idle mind and hands busy, during airport layovers. Give them a go!