Using Dynalist as a Productivity Tool

I’ve been searching for years for the “perfect tool” to help me take notes, organize ideas, and keep track of all the tasks I need to do. I’ve also been deeply obsessed with lists forever. At some point I came across Workflowy, which I quite liked. I don’t remember why, but I then discovered and switched over to I don’t know if it’s the perfect tool, but I’ve adapted a way of using it that’s working well for me. I now pay for a yearly subscription, and use it for most things.

The Big Idea

The big idea for both Dynalist and Workflowy is really that everything is a nested list. So you can create lists within lists, to your heart’s content, and expand and collapse things at every level to view more or less detail. Dynalist does allow you to split those lists out into separate documents (not sure if Workflowy does this now), and even organize those documents in folders (see below), but generally speaking these systems encourage you to think of things as all connected through one giant structured list. I like that idea from a deep philosophical level, based on the premise that there’s some kind of grand scheme to things… but my pragmatic side also likes to be able to split things up and handle them separately, so let’s dig into that. This line of thinking goes back a really long way, including a stop on OPML along the journey.

Top Level Organization

I have 3 top-level folders in my Dynalist sidebar:

Folders in Dynalist.

I try not to delete any real “notes”, so if I don’t need them, I move them to Archived. Work and Personal are pretty self-explanatory. Inside each of those, I have the following three lists, at the top of that folder:

  • TODO: structured lists (varying structures, we’ll get there) of things that I think I need to do. The Work one is the most structured.
  • Notes: general notes, about anything and everything, organized based on topics/high level ideas.
  • Calls: notes that I take during various phone calls/meetings, for my own reference. Mostly structured by person/company, and then date.

Work > TODO

The top level of my Work TODO list looks like this:

Work TODO list
  • Backlog: This is kind of an inbox for things that I am not specifically doing yet, but it’s not handled like GTD (“immediate” processing), so things can sit in there for a while. It is set as my Dynalist inbox, so when I hit cmd-ctrl-i I can add directly to it from anywhere.
  • Daily: Here I have a sub-list for each weekday, which I set as H2 headings. Each of the days just contain everything I’m doing that day. I have a single repeating event on Friday to write up and post some “weekly notes”, a habit I maintain internally to keep colleagues informed with what I’m up to. That event repeats at 3pm on Fridays, and when I check it off it automatically adds a new one ready for next week.
  • Periodic / Scheduled: I have some things that I just want to make sure that I do, and they are on schedules less frequent than weekly. I keep an entry for them each in this list, and make sure that they recreate entries when I cross them off.

Daily Usage

To support scheduled tasks (using the !date notation), I sync Dynalist with my Google Calendar (Pro feature), so those items show up in my calendar along with other appointments, and remind me when it’s time to do them.

A lot of my entries involve interactions with people, and I mostly use @someone to refer to people consistently. I use some #tags but not very consistently. Since I delete a lot of my items (see below) I don’t find too much value (e.g. being able to refer back to things) in maintaining a lot of metadata.

Either at the end of each day, or the beginning of a new one, I try to spend a few minutes and map out what I’ll be doing that day, in the appropriate list (Work > TODO > Daily > Tuesday). I take a quick look at my calendar and add an entry for any scheduled meetings, 1:1s, etc. I put things in rough time order for the day, so my lists are both numbered and have checkboxes (cmd-shift-c to toggle checkboxes). If there’s a relevant link for an item, I’ll add that in the Notes field (shift-enter), so that I can quickly open/jump to it when I get to that item.

During the day, I try to focus in on a single thing, so I navigate to the specific item I’m working on, and my view will look something like this:

Focus on a single item. Sidebar collapsed, this is the only thing I can see.

I’ll leave Dynalist in my second monitor, in that view, while I’m working on that item. It serves as a constant reminder whenever I see it, that I’m supposed to still be addressing that item, otherwise I’d have checked it off. Once I’m done, I will in fact check it off (cmd-enter) and then navigate to the next item on the list. I recently discovered the keyboard shortcut to do this directly (cmd-shift-]) and it’s been a huge win for me. I found that previously I’d navigate back to the specific day’s list, and then start looking at/thinking about all the other things on my list for today — now I can just bounce straight to the next one and ignore everything else. I do leave checked items showing (Preferences > Viewing options > Show checked items) because it lets me progress throughout the day when I go back to that main list.

At the end of the day, I’ll delete everything completed, and if I have any items left in that day that I didn’t complete (happens all too often, I’m afraid), I’ll either roll them over to the next day, or reassess what to do with them entirely. Sometimes I’ll move them back to my Backlog list, sometimes I’ll change the entry to get me to delegate it to someone else, or sometimes (eventually) I’ll accept that I’m never going to do it, and I’ll just delete it.

Delete checked items, via the hover-hamburger menu.

I think those are the main unique pieces of how I use Dynalist. It’s been working well for me, and I’ve been doing things like this for a while now. If you’ve never used Dynalist (or Workflowy), but are a compulsive list-maker like I am, check them out. For longer form note taking and idea capture, I’m curious to give Roam Research a real try, it seems like a less-structured, long-form version of these tools.

Remote Work At Scale

COVID-19 (aka coronavirus) has many companies suddenly experimenting with remote work for the first time. I tweeted yesterday that unfortunately people are likely to have a pretty rough time due to the rushed nature of the experiment, and some folks asked if I could expand on that, so here we are. There are already a bunch of write-ups, resources, and tools if you look around (including one from our CEO Matt, and this great webinar-format session from Cate and Nicole), so it’s worth getting other views and ideas as well.

We’ll look at some concepts that I think underpin successful distributed work, and then we’ll dive into a loosely-structured “day in the life” to look at some of the specific tools and approaches we use currently at Automattic. This is all based on about 13 years worth of working remotely or fully-distributed, 11 of which have been with Automattic where I’ve been a part of growing the company from ~40 people to ~1,200 people, spread across 76 countries. I’ve been everything from an individual engineer to a leader across groups up to about 60 people. We’ll focus on the day-to-day type work of an engineering-heavy organization rather than the business/human resources/operations side of things. This is going to be long, and probably a bit rambling.

Before we get into it, three quick notes;

  1. I tend to use the term “distributed work” rather than “remote work”, because at Automattic we don’t have a central office to be “remote” from. We’re fully distributed. Like a decentralized network. Have been since day zero.
  2. We operate across many timezones (almost all of them), which creates its own complexities and amplifies the need for certain practices and approaches. If you’re taking an existing shared office remote, that might not be the case, but a lot of the approaches we use will probably still be useful to enable more async work (we’ll get to that below).
  3. Tools are not the answer. Working remotely requires a cultural shift from your org, and a change in how you do business. Tools are part of the puzzle, and having good tools helps, but they won’t make or break your success.
Continue reading “Remote Work At Scale”

Management Communication: Priority Exceptions

Constantly-changing priorities and surprise projects erode team morale and leave everyone unsure of if they’re working on the most important thing, or if they’ll ever get to finish anything. While being adaptable and flexible is critical for most teams, it’s always important to have some kind of roadmap and approach to prioritization and planning work. There are many different ways to plan and prioritize your work; what’s important is that when priorities change — and they will change — you acknowledge that change and adapt quickly.

If you don’t clearly acknowledge the change in plans, your team can start to question the point of the plan in the first place. They’ll start to wonder if they are expected to do this new thing and the old thing, or just the new thing, or since the new thing is not in the plan, perhaps they should actually ignore it? Don’t leave room for interpretation. Clearly set expectations and make sure you communicate unambiguously what is being asked of them. Sometimes they need to be given clear “permission” to really work on this new thing, and delay or drop the old thing.

On my teams, we use a process we call a “Priority Exception” to clearly address a major change in our plans. This process is used when we had a plan of work, and for some reason something not on that plan jumps to the next most important thing for us to work on. The goal is to acknowledge the change, clearly communicate the impact this change will have on existing work, and critically; highlight why it is so important that it should disrupt our plan. We use this template to ensure the right information is always included, and distribute the details to everyone on the team (and any other relevant stakeholders).

What new thing is happening?

Right up front, we outline the new work at a high level so that we all know what we’re talking about. We link out to our project management system or code tracker for further details. This section includes which individuals or teams will be required for the new work.

What existing thing is being delayed?

Next we’ll specify what work we’re putting on hold or slowing down because of this new work, or how we’re creating capacity to work on it. We’ll try to include details on the expected impact of our delay; If we can put a number on it, this is where it goes. Lost revenue? Delayed launch? Losing more users? Be specific.

Why is the new thing more important?

This helps head off questions about why we had to “drop everything” to work on something unexpected. This should clearly demonstrate why the new work is more important or more urgent than the planned work. You should be able to clearly illustrate why it offsets the impact of the delayed work (as detailed above).

How did this come about?

As a form of mini-retrospective, this is a chance to highlight why this work was such a surprise. It’s an opportunity to learn and avoid surprises in the future, or come up with other mitigation strategies, depending on what happened.


We set a clear timeline covering any wind-down of current work, transition to the new work, and expected completion or progress milestones. Since Priority Exceptions often come with an external deadline, we’ll make sure that is clearly communicated as well.

Priority Exceptions are a useful, lightweight tool for communicating changes in priorities, and for learning how to reduce priority-thrash over time. Teams have appreciated the clarity they bring to otherwise-potentially-confusing times, and the clear permission they give to delay work in favor of something more important.

Arc’teryx Norvan SL Hoody Review

Before we get into any details, let me just get this out of the way — I absolutely love this thing, and giggle every time I get to use it. It makes no sense, I know, but here we are.

OK — now that you know how biased I am, let’s jump into some details.

I have the black and red, size Large. I’m 6’4″ and have bizarrely long arms, but the Norvan SL Hoody fits as well (if not better) than most standard long-sleeve items I get my hands on, and isn’t too baggy around the body. When I first pull it out of the pouch it might be a little short (because the fabric is all crumpled up), but then it smoothes out to full length pretty quickly. The semi-rigid hood rim and extended and reflective cuffs are really nice touches, and help make this jacket feel like more than just a super-expensive poncho.

When it’s tucked into the pouch, this jacket is so small and light that I end up taking it with me everywhere. I throw it in my work backpack in case it starts raining on me while I’m out. I take it to outdoor concerts in case there’s rain. I’ve taken it on a couple of work trips so that I could use it for a morning run in the cold and/or wet, or just to save space when I’m traveling carry-on-only. I throw it in my mountain biking backpack in case it rains while I’m riding. It’s great — it’s about the size of my fist, and just fits everywhere. I often just have it on a small carabiner and clip it to my belt loop if I don’t want to carry a bag.

On one work trip, I used it when running in 32 degree weather, over just a t-shirt. It cut enough of the wind and provided enough warmth for me to get 5k in without too much discomfort (my legs were a different story). On a ride, I was able to throw it on and avoid getting soaked during a surprise downpour. While I definitely heated up (and got more sweaty) wearing the jacket and riding in pretty warm weather, it remained impressively breathable and drawing the zipper down a little was enough to cool off a bit.

My only concerns with the Norvan Hoody are just how delicate it is, since I’ve read reviews about it losing its waterproof surface when used with a backpack (straps). I try not to wear a heavy backpack or move around too much if I have one on, to minimize damage. So far it’s looking good. I keep it in the pouch most of the time (vs hanging it up), and am hoping that’s not going to contribute to any fabric deterioration. I guess my one other wish would be pockets, but for something this waterproof, minimal and lightweight, we can’t have everything.

Engineering Management Lessons From Mountain Biking

Since moving to Colorado, I’ve been lucky enough to get out mountain biking pretty frequently. I love it. On some rides you’re just trying to get up or down the mountain in one piece, but on some rides you get good time to think quite deeply. On a recent ride I was rolling around (pun intended, you’re welcome) some ideas about engineering management, and realized there are some good parallels between mountain biking and leading teams of engineers.

Look Out Ahead

When you’re riding single track, it’s really common to have your eyes glued to the trail right in front of your wheel. Big mistake. Not only does it mean that you’re going to be constantly reacting and trying to respond to things as they appear right in front of you, but it also means that you’re not going to have any advanced warning of big changes ahead. Like a tight turn. Or fast descent. Or a jump/drop-off.

Instead of staring right in front of your wheel, you should keep your eyes further out ahead. This gives you more time to react, some time to pick your line, and the ability to adjust your approach as needed by speeding up, slowing down, changing your stroke on the pedals, or even just bracing for impact 😉

With engineering teams, if you’re heads down responding to the things right in front of you, you’re going to be in that same reactive position, and things will constantly take you by surprise. Take some time to not only plan out ahead, but forecast and “game out” what the future might hold. Will you need to hire more people soon? Adjust team structure? Train your people up in some specific skill? Transfer knowledge between key people? If you’re not looking ahead, these things can catch you by surprise, and become a much bigger issue than they needed to be.

Build Momentum

When you’re on a really gnarly section of technical trail, it’s all too easy to slow right down and find yourself picking your way through rocks and bumping across things uncontrollably. As counter-intuitive as it sounds, it’s often better to speed up and keep moving than it is to slow down and try to delicately navigate every little obstacle. You can end up feeling like a bit of a steamroller, skimming over the top of everything, but you end up with a smoother ride, and it’s a whole lot more fun than bumping and grinding through every rock in your path. Instead of slowing down and being overly cautious, a common refrain is “let it roll”, meaning don’t brake, just roll through the obstacles using your momentum (and then quickly move on to the next one).

Something similar can be said for engineering teams, who benefit from building and maintaining momentum in their work. Get in the habit of shipping, and always protect that habit. Don’t slow right down and get stuck in the details. If you adopt an extremely slow and overly-cautious approach to shipping, then you can quickly find yourself in a state where you’re not shipping at all. Once shipping becomes a habit, that momentum is easier to maintain and build upon, to continue increasing your velocity.

Find Your Velocity

As a balancing point to the previous one, it’s also important to find the right velocity. On a mountain bike, if you go too slowly, you’ll have a rough ride, experience every bump and rock, and probably not enjoy yourself much. If you go too fast, well, there are plenty of YouTube videos to show you what happens. You need to find a pace where you’re making good progress, but you’re not completely out of control. It’s probably a little faster than you think it is, so you should push yourself and really find your limits.

If you’re moving too quickly as an engineering team, it probably means you’re shipping sloppy work, failing to validate ideas, accumulating a ton of technical debt, or just plain old rushing things. Find a sustainable pace where you can deliver quality work, without burning people out, and without shipping junk. That being said, moving too quickly is rarely a problem with engineering teams, so remember that speed matters, and always push to move as quickly, but sustainably, as possible.

I’m sure there are more parallels to be explored, but these were the only ones that came to me before I hit the more technical section of the trail, and had to really pay attention!

Keyring 2.0 and Keyring Social Importers 2.0

Yesterday I released new versions of both Keyring and the Keyring Social Importers packages, containing a bunch of updates and new additions. If you’re already using them, you should have update notices in wp-admin. If you’re not yet, then download them at the links above, or search for “keyring” in wp-admin under Plugins > Add New.

What’s changed? It’s been a while since the last official release of Keyring, so there’s a bunch to catch up on:

  • All Google services have been modified to use a shared base service (cuts down on code duplication significantly).
    • Added a GMail Service (props @poisa).
    • Added a YouTube Service (based heavily on @superbia‘s work with Google Analytics).
  • Added a Pocket Service (props @roccotripaldi).
  • Keyring is now available for use with Composer, via Packagist.
  • Lots of bugfixes, including token refreshing should now work properly.

The Social Importers haven’t seen an official release since 2017, so there’s a ton going on there as well:

  • Added a Strava importer (props @mdrovdhal) and introduced a bunch of improvements via iteration (props @marekhrabe). Having another service with map-based data makes me want to add some core to make it easier to map things visually.
  • Introduced a global option (for all importers) that allows you to set posts to published, draft, private, or pending when importing them. A lot of people were asking for/hacking this in, so I figured I’d just add it to the core package. Being able to import as draft and then selectively publish, or import an entire service to “private” posts is a nice addition.
  • Lots of improvements and bugfixes to both Twitter (some props @chrishardie) and Swarm/Foursquare.
  • Added a Pocket importer, again props @roccotripaldi. It works similarly to the Instapaper one, so if you’re using Pocket instead, check it out.

If you’d like to keep an eye on things more closely, or even contribute, check out Keyring, and the Keyring Social Importers on GitHub. It’s been really awesome to see some more contributions to both packages coming in, so I’d love to see more of that.

Download Keyring and the Keyring Social Importers plugins for WordPress.

DJI Mavic Air Review

After drooling over it for months at Costco, I picked up a bundle package with a DJI Mavic Air back in November. I’ve now flown it a fair bit, and wanted to write up some observations on it.

First of all — this thing is amazing. It’s so much fun to fly, and honestly feels a bit like magic, especially when compared with cheaper, fully-manual quadcopters. Probably the coolest feature of this thing (for me, a n00b) is that if you let go of the control sticks, it’ll automatically just hover in place. Brilliant.

The bundle that I got came with propeller guards (2 sets actually, which turns out to be ridiculous — if you break those guards you’ll almost certainly manage to destroy the drone itself), so I started out flying with them on. It has object detection/avoidance in three directions (forward, backward, downward), so between that and the prop guards, it’s relatively safe. I still managed to crash it pretty hard a couple of times, and break some propellers. I got carried away and bought a bunch of replacements, but now haven’t needed any in a while.

I’ve purchased a second battery, and got a little carried away and purchased an Anbee Power Bank so that I can recharge batteries without access to an outlet (e.g. if I was out backpacking or mountain biking or something, and watched to capture more than 2 batteries worth of action; about 30 minutes). The batteries claim to be 21 minutes of flight time, but in my experience they’re pretty much always 14 or 15 minutes (stopping at about 20% battery remaining, for safety). I haven’t tried running them down to 0% to see how long they actually go, so maybe that’d get me to 21 mins before it fell out of the sky.

Beginner mode + propeller guards is a good way to get used to things. Once you graduate out of there, you’ll end up turning off/ignoring a bunch of warnings and things; these devices and their software really try to make sure you’re doing the “right thing”, safely. The app takes some getting used to (especially the special flight modes), but generally is pretty good and pretty intuitive. It always tells you everything that’s going on, and lets you tweak and configure things a fair bit.

I find that I have to calibrate the compass almost every time I go out to fly, which is kind of annoying, but pretty quick and simple. It reminds me of calibrating the compass on an iPhone, where you have to way the phone around. In this case you’ll be spinning yourself around in a few directions, and then you’re up and running. From deciding to fly, to having it in the air, it’s normally less than a couple of minutes.

The drone itself (and the controller) is amazingly portable/compact. When you pack it down into the small case that comes with it, it’s hard to believe that the whole thing is in there. I specifically love how compact the controller is. The control sticks detach and stow inside the controller itself, genius! With the controller compacted down, and the drone folded away inside its case, you can just slip them both in jacket pockets, or throw the whole kit in a backpack.

I’m definitely still figuring out how to get the most out of my drone, especially when it comes to video. I’m looking forward to spending some more time on that, and trying my hand at editing some short videos.

Thoughts to Ponder

Loved these thoughts from the outgoing Chief Data Scientist of the White House:

  • Dream in years
  • Plan in months
  • Evaluate in weeks
  • Ship daily
  • Prototype for 1x
  • Builder for 10x
  • Engineer for 100x
  • What’s required to cut the timeline in 1/2?
  • What’s required to double the impact?


New Year, New Theme

To ring in 2019, I’m changing this blog’s theme to Twenty Nineteen, the new default WordPress theme, designed and primarily created by my excellent colleague, Allan Cole (check out his music, published as The Stuyvesants, they’re groovy).

Apart from being pretty similar to, but a nice upgrade from the previous theme here, Twenty Nineteen also harnesses the full power of Gutenberg, the new WordPress Block Editor. I’m going to convert some posts to blocks so that I can use some of the better gallery options and whatnot, and will be using Gutenberg for everything going forward. It also reminds me a bit of the styling used throughout Instapaper, which I’ve spent a lot of time in lately 🙂

Happy New Year!

Honeymoon in Japan

After our wedding, and cleaning everything up, we had just another day or two at home before heading off on our honeymoon. We decided to go to Japan, since neither of us had ever been there, and we both really wanted to go. It was a really amazing trip, even though it was brutally hot and humid at the time of year we went. We managed to do most of it on award points/miles as well, so that made it all even sweeter 🙂

Continue reading “Honeymoon in Japan”