Write linked notes so you don’t have to remember

Writing linked notes helps engineering makers and managers alike develop the super-powers of augmented memory and the appearance of effective multitasking.

I’m revisiting Simon Willison’s essay and conference talk Massively increase your productivity on personal projects with comprehensive documentation and automated tests. I’ve started thinking about it1 as “the surprisingly effective power of writing linked notes”.

In particular, those last three words:

  • Writing: most thinking is improved and clarified by writing.
  • Linked: writing is even better when the writer or interested colleagues can return to it later. Linking facilitates discovery via browsing and searching.
  • Notes: mostly static text, but sometimes executable tests/documentation, too!

Over time, writing linked notes gives you what looks like the myth of multitasking. Really, it’s reducing the cost of context-switching and remembering:

This is how it relates back to maintaining 185 projects at the same time.

With issue driven development you don’t have to remember anything about any of these projects at all.

I’ve had issues where I did a bunch of design work in issue comments, then dropped it, then came back 12 months later and implemented that design—without having to rethink it.

Occasionally, I get a feeling, whilst working on a tricky problem, that I am starting to lose the thread. Keeping all the variables, ideas, and context is difficult as the interconnections grow. That’s the moment when writing it down to get it out of my head allows me the space to remember less, concentrate more, and push through to make progress again.

Highly recommended.

  1. And, sharing it with anyone who will listen. Present company included.

Leadership keywords

My current theory of leading software teams and projects has four keywords:

  • Trust: I assume everyone is working to get the job done. They assume I will help them get the job done. This starts off more like faith and grows into trust as teams coalesce.
  • Autonomy: each person on the team is independently productive for a significant chunk of their day. When they make assumptions to stay unblocked, they are adept at collaborating asynchronously to verify them or correct course.
  • Agency: each person solves the task they’re working on in a way they see fit, within the conventions shared by the team. If an interesting idea comes up outside of the those norms, anyone can pursue it such that they maintain the trust/faith of their colleagues.
  • Support: each person knows that the team, particularly yours truly, is there to help each other. This most often manifests as pairing on troubleshooting, designing, coding, etc. Most importantly, sometimes it is sharing the load when one person is feeling overwhelmed.

Support is a recent addition. I had previously thought that autonomy and agency were the things enabled by trust. But I’m starting to think1 support is a crucial part of the equation too.

Without support, you’re just throwing people into the pool and telling them they can stay a-float however they like. It omits the “get good enough to swim” part, which is pretty crucial!

This kind of support is most obvious when you’re bringing someone new onto a team. But you need it throughout an individual’s tenure on your team. The people with years of deep experience and history in their head need support of a different variety.

Teaser: I’m on the fence about adding 2-3 more words to my repertoire. There’s a lot of moving parts to leadership!

  1. Largely due to onboarding people to a team/system/organization with a long history. This doesn’t happen without a larger-than-normal support effort. Perhaps that effort is amortizable over time (i.e. writing docs), but it’s still a big lift.

Don’t be spooky

It’s possibly the best advice for managers I’ve given so far. When you’re communicating with your team, lead with context and reassurance. Never message someone on your team, “let’s talk when you get a minute”. That’s void of information and scary as heck!

I have to remind myself of this when I’m rushing. It’s faster to ping someone to arrange a synchronous talk than it is to write out what I need to say and cover all the bases. But that doesn’t give me license to skip all the context. Broad strokes are okay. An information vacuum is not okay.

Accidental spookiness invites story-crafting. Minds race. Lacking information or context, we tell stories. They often aren’t happy stories, regardless of how good your relationship with the team. We humans are better at convincing ourselves to fear something (survival instinct) than the other way around.

Avoiding spookiness reduces the chance of people telling themselves negative stories. Context and clarity counteract reading the tea leaves and world building. Even more important, it prevents people from pre-gaming the conversation. That way, they don’t prepare for a conversation that happened in their heads, instead of one that’s about to happen. (Avoiding pre-gaming is important on both sides of the conversation, as it turns out.)

A corollary to “don’t be spooky” — deliver constructive but critical feedback as close to the “original sin” as possible. Receiving feedback that you did poorly weeks after the fact is disconcerting. It can lead the recipient to wondering what other things they’re doing poorly but won’t hear about until later. Which leads to story-crafting, and the whole negative cycle starts a-new.

Give your team enough context to pre-game conversation based on the real context, not conjecture. And don’t hold on to feedback for “that perfect time”.

“Rationalize and solve” doesn’t help someone who is venting

If you’re doing the whole servant leadership thing, you’re gonna hear some people venting frustrations. Yihwan Kim, When a 1:1 turns into a vent session:

As an engineering manager, I’m learning that a big part of my job (perhaps my only job) is to help people solve problems. I happen to enjoy solving problems myself. So it’s only natural that when someone starts venting, I want to rationalize the conversation, correct inaccuracies, and discuss actionable next steps.

I always have to remind myself: don’t.

Relatable. It’s easy to react to someone venting by rationalizing and solving. As Yihwan points out, that’s not the card to play here. The win condition for these is to 1) hear your colleague out and 2) help improve the cause of the vent if your teammate wants you to.

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.

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”