One priority is like wind in the sails

It’s true that I can scale myself, teams, and organizations to walk and chew gum at the same time, but it is surprisingly effective to focus on one thing at a time. This is the essence of “priority” — put all my energy into one outcome until it’s done. Then the next one, the next one, etc. as my efforts start to compound.

I, like many folk, do much of my best work in coffee mode. When that deep, coffee mode work aligns with my priority, everything is operating smoothly and life is good. If my priority (singular) changes and I need to go deep on something else, that’s not ideal but not so bad either. As long as I can still focus, things are good. When I’m asked to go deep on two things or pulled to work on deep but unaligned tasks, that’s when things get gnarly.

A useful activity that looks like (and is often called) prioritizing is sorting (“triaging”) a list of potential work by what’s most impactful or important. This is more of a planning activity than a priority exercise. It acknowledges there’s a lot to do and time is finite. The result sends a clear signal: this thing at the top of the list is more important than all the things below it. In particular, any of the top items are more useful to work on than all the things further down the list.

Get better at finishing projects. That’s working smarter, not harder. Finished projects, axiomatically, don’t need prioritizing against other work. Limiting work in progress is difficult to pull off in the moment but a crucial tactic to apply when things get intense.

Possibly controversial: multiple priorities is about the same as having no priorities. The trick that priorities pull is freeing us of the energy-sapping process of deciding what’s most important and what trade-offs to make. A single priority is a note from your past, well-considered self saying “this is more important than all the other things; work on it before anything else”.

Systems of “one priority”:

Multiple priorities make it unclear what expectations are for individuals. Choosing what to work on becomes difficult and a burden. A single priority is a mission, a clarity of work. Get this thing done, declare victory, move on.

Planning focuses our ideas

Planning is essential. But, not too much. Mostly in the next 90-day window (with apologies to Michael Pollan).

Humans are, with few exceptions, awful at planning. It’s impossible to see the future. We rely on our previous experience over data too often. Or, not enough. Or, in the wrong combination for this scenario. Beyond a few days, the world we operate in is too complex, people too hard to predict, and all of it is interconnected in surprising ways.

Even worse, humans easily deceive themselves with plans. It’s so easy to look at basically any kind of ambition or outcome and say “yeah sure, given 6-18 months this seems totally feasible.” (With apologies to our ambition, it probably is not feasible.)

Yet when we account for those hazards, planning is essential (apologies to Dwight Eisenhower). Most things won’t go to plan, but making one forces us to think things through, ahead of time. Outcomes without a plan are worse than outcomes from a plan that has to change when reality punches us in the face (with apologies to Mike Tyson).

I find that periodically looking 90 days into the future to think about what I want to focus on and outcomes I hope to realize is a pretty dang good way of setting myself up for “luck favors the prepared”.

Planning the work is an essential part of doing the work. An ambitious but uncertain 6-month idea becomes an ambitious but plausible plan in steps. Make a 90-day plan by breaking it into chunks. Organize them into a coherent fraction of the 6-month idea. Make trade-offs to decide what’s most important or risky. Start on the first thing. Rinse and repeat.

Iteration is part of planning. Unknowns, predicted and unpredicted, rear their head. Risk turns into caution turns into incidence. Nothing goes exactly to plan. So, we take another swing at the plan, armed with new information.

We’re always smarter than we were last week or last month when we made the plan. Sticking to the plan is foolish. Updating or overhauling the plan makes much more sense than trying to argue with it.

Planning is like writing. They both focus our thinking. An idea that flops when we take it from our brains to the page probably needs more work, whether it’s writing or planning.

Working, directly & small

Omar Rizwan recollects that one of the original selling points of React was that you could consolidate all the HTML, CSS, and JS for a single component in one file. No navigating across large directory trees to find the one line of code that implements the behavior you want. Far less worrying “if I change this am I unwinding a ball of yarn that I will regret?”

(Side note: one of the most powerful tools programmers have is scope. Most things are easier when you’re working in smaller and more local scopes. If your HTML/CSS/JS only applies to the file you’re looking at, many things are easy or possible.)

I’d forgotten about this selling point and wish things had evolved differently to support it. In the large, many programming techniques don’t work and this one is no exception. But in the small, how wonderful would it be to express everything about an idea you’re trying to build in just one place?

Lately, I’m finding that my prototypes and weekend hacks are most successful when I don’t try to get “too serious” about them too early. Adding type checkers, linters, even switching contexts to write automated tests are all “too serious”. If I give myself a little freedom to work messy and concentrate on the idea, not the code, things go better.

I suspect there’s a connection between working messy, generating ideas, and using a framework that doesn’t punish/forbid throwing all your code into one file.

The unreasonable effectiveness of checklists

Checklists are a fantastic tool for thinking. This despite the existence of GTD, Kanban, PARA, and any number of ways to organize projects and figure out how to finish them. When I’m starting a project or when the going gets weird, checklists are usually how I end up thinking my way through.

Continue reading “The unreasonable effectiveness of checklists” →

Onboard new teammates with a 90-day plan


My new boss had written up a 90-day plan for me the week before I started. This was perfect timing. I was already starting to put a bow on my current work and my focus was wandering. Now my brain could start working on ideas for the next gig. Plus, I had a much better idea of what I’d start working on and how to make an impact than I did coming out of my interviews. It was one of the better emails I’ve ever received.

Continue reading “Onboard new teammates with a 90-day plan” →

Use factories to create jumbo object graphs

The entire time I’ve been using FactoryBot, several years at this point, I’ve used it one factory at a time:

company = create(:company, name: "Acme, Inc.")
alice = create(:user, name: "Alice Smith")
posts = create_list(:post, 3, user: alice)

Do you see the mistake I make all the dang time? Spoiler alert, I forgot the company relation on Alice’s user, so she is either orphaned (unfortunate) or created on an entirely unrelated company. That’s gonna make my test fail in weird ways!

Lately, I’ve been trying something different: create the whole object graph I want to test on in one fell swoop:

company = create(
  :company,
  name: "Acme, Inc",
  user: build(
    :user, 
    name: "Alice Smith",
    posts: build_list(:post, 3)
  )
)

The entire intent of the test scenario is made clear right here. And, the error I so often make is solved structurally rather than by vigilance.

Granted, that’s pretty chunky and way more lines. I feel like it’s a worthy tradeoff!

When I need to reference the models created by my jumbo object graph, I use RSpec let and ActiveRecord finders with a mind towards consistently finding the right thing:

let(:company) do
  create(...) # the whole company bit from above
end
let(:alice) { company.users.find_by(name: "Alice Smith") }
let(:posts) { alice.posts }

Failure = entropy due to adding humans

Here’s a real dinger of a sentence from Michael Lopp’s latest, The Art of Leadership: Small Things, Done Well:

Failure is created by the increasing entropy of a growing number of humans running around the building, good intentions in hand, breaking things.

Growing an organization requires rethinking trust, coordination, and collaboration. The breakpoints where things go from working pretty well to an absolute shamble come faster than we think. They don’t even occur at nice, round numbers like base–2 or base–10 orders of magnitude.

Figuring out how this works for teams, companies, social networks, and whole countries feels like one of the big unsolved problems of the knowledge/attention-era.