What are work practices that you’ve adopted that you now think are underrated?

CEA has long had the concept of "who owns this ball."^[1] I'm gonna have a hard time in this answer conveying exactly how much this has become a whole encompassing working philosophy for me.

Level 1: The alarm bells about dropped balls

If you are having a conversation and someone's like "we should do X"... Someone should really be the person owning the ball for doing (or not doing!) X.

If there's a "ball" (a task of some sort) that's sitting around and not moving forward, and anyone has any uncertainty about who's responsible for it, they should flag that.

Example: "Ok, who owns the ball of reaching out to GWWC?"

Level 2: Passing balls

Be extremely clear in your communication when you're handing off a ball to someone else, or taking on a ball. This prevents balls from getting dropped in the first place. We use dedicated emoji-jargon for this at CEA:

• 🏈 for handing off a ball
• 🤾 for catching a ball

Example: "I'm not sure what happened there, looks like a bug. 🏈 to you to fix?"

Level 3: Systems that prevent dropped balls

We have a round robin system in our code reviews, to make sure that each code review is assigned to a single reviewer, who knows that it's their job to review that code. The reviewer then assigns the task back to the original developer to address comments and/or merge the code. The code review can literally never be in an ambiguous state. (Ideally anyway. Human be humans, and it happens.)

Both our developers and our moderators has the concept of an "on-call" rotation, both developed by me. Quoting from the moderator on-call doc:

You should be aiming to ensure an efficiently running ship. It’s your job this week to make sure that everything’s running smoothly. That does not mean doing everything yourself. But this week, the buck of dropped balls does stop with you.

***

I think I've done a fair job of communicating the type of thing I mean, but it really goes quite deep and broad for me. As I predicted, moreso than this suggests.

1. ^{^}

   I wrote this answer, and then realized I needed to give a shout out to @Amy Labenz and the events team, who really embody the spirit of this philosophy. Amy at one point bought like 40 styrofoam balls and had CEA write tasks they were worried might be getting dropped on them, and then we went around finding an owner for the balls, or deciding to drop them by choice.

I like the watch team backup concept. Basically a culture of double-checking without implying the other person is doing a bad job.

Try working from an office or a coworking space

I don't think this is the best solution for everyone, but it really helped my productivity. I'd never worked in an office until November 2021, and wasn't expecting it to have the difference it did. 

(I think things like FocusMate also work for people and do some of the same things, but I never got into the habit.)

A really useful tool for research I learnt recently (from CE) is time-capping. Set yourself a limited amount of time to accomplish a specific goal and move on at the end (or at least step back and re-consider). I used to have a tendency to get sucked down rabbit holes when researching - time-capping helps me keep track of when I'm spending too much time on something that doesn't justify it in terms of end-product. 
This post is a helpful introduction: https://forum.effectivealtruism.org/posts/nCJCuLaWHt3oooM3y/the-importance-of-time-capping 

Send calendar invites immediately when a meeting is agreed.

Always send follow up emails reiterating action points after a meeting.

Put your phone out of sight (and maybe turn it off).

Use the split screen function on your laptop.

Learn the ‘proper’ way to type.

Write a document with advice for whoever will eventually succeed you in your role.

Set specific goals for the next week or month, especially for longer-running projects (and tracking those goals), and then try to stick to those. This involves both considering external outcomes ("10 people visit this site") and your personal outputs ("I share a doc on a given topic with [some people] by [date]").^[1] 

Note: I'm hoping to get better at this — I think I have a lot of room for growth here. To the extent that I do it, it really helps me. (Thanks to my teammates, who've been great at pushing for this!)

• How this helps
  • When there are a lot of things to do, it's much easier to prioritize when I'm setting goals on somewhat longer time scales ^[2]
    • I can look at my list of 20 tasks, estimate how long each will take, and realize that I can't fit all of that in the next week. This forces me to deliberately decide which I will deprioritize. I think the alternative tends to be more like pretending that time doesn't exist, and that I can just work longer or harder to avoid tradeoffs like this, which can mean that I'll spend a bunch of time working on something of medium importance, and then need to scramble to get the really important tasks done.
    • It also makes it easier to stop myself from saying yes to new things that pop up. And on the flip side, when there's a time set aside for answering "what are the important things I need to do this week/month?" I notice things that I might miss if I don't ask myself that question. 
    • The prioritization also tends to be better when I'm tying it to specific and pre-decided goals,^[3] as opposed to thinking about whether I think a task or project is good on a case-by-case basis — I think in the latter case it's easier for me to just be excited about something and want to do it based on that. 
  • It helps me feel like I'm actually getting stuff done (& fight impostor syndrome)
    • I sometimes feel like I'm not accomplishing anything. When I've been planning OKRs (4-6 weeks, for us) or sprints (1 week), I can look back on that period, see what tasks I planned to do — which I know I thought were promising/useful — see which I've done, and fight against the feeling that nothing happened. 
  • It saves time
    • Switching between tasks costs time. When my approach is more opportunist — I finish a task, then think about what I should do next — I think I lose a lot of time in between tasks (in total, more than if I'd just planned ~everything in one chunk). If I've got a list of tasks in my Asana, I can just start working on the next thing. 
  • When I have a big and long project, it's much easier to make regular progress on it when I have regular events or meetings when I deliberately break the long project up into pieces that I can make progress on in the next week/month. 
    • Before working at Rethink Priorities, I'd mostly done research and assorted education-adjacent jobs. I had mentors for research, but they were usually quite hands-off, and the research often involved me kind of floating around reading things for a while before scrambling to produce something at the very end. Working with a manager to systematically break longer projects up into sub-goals/milestones was a revelation for me when I was a fellow at Rethink Priorities (see more), and I think made it much easier to actually make progress. 
    • Sort of related: minimizing the time between when you have an idea and when your customer benefits from that idea
• How to do it / get better at it
  • Keywords: OKRs, sprints (I think the online team does something a bit different and more individual-based, but close enough)
  • The thing that's really worked for me is working with people who are better than I am at this. (And having managers who push me to do this.)
  • Some notes on how I do this (I'd love to hear how others do it, as I don't think my processes are great): 
    • My job involves some amount of reactive work — things that come up during the week, etc. — so I just leave some space for that kind of thing. 
    • To get more objective/external goals (to track outcomes), I might set up some slightly silly operationalizations/metrics, like "we get N substantive comments on [a thread]," "the moderation team uses the handbook for X% of incidents in the next month," "[my teammates] rate [this internal document] to be an improvement of at least 4 (on a 1-5 scale where 3 is neutral) over the last iteration." (These are fake.) I think that I've often ended up tracking outputs — things like "I share [a doc on a topic]" over outcomes, and I'm trying to be more outcome-oriented. 
  • Other people might have suggestions! I'd be interested.

1. ^{^}

   Also related: having theories of change (e.g. see discussion here) and back-chaining. 

2. ^{^}

   I'm sometimes tempted to think that I prioritize fine on a day-to-day basis, but I currently think I'm deluding myself when I think that

3. ^{^}

   This relies on trusting the goals to be more accurate than your intuitions, which I think we should normally do. 

Finish all bursts of work with a Placeholder. 

A placeholder is note, even a sentence, that allows you to more easily 'get back in the flow' of a task after leaving it for some time.

A major drain of the productivity of modern knowledge workers is that we engage in too much context switching i.e. switching from task to task. When I move from doing emails to getting down to writing, it takes some time to 'get into the swing' of writing. If I then have to take a call, I have to restart the process of getting into the headspace to write. Often the previous task 'drags' on our attention.  This is often called attention residue.

Many people try to solve this by reducing the amount of context switching they have to do (see deep work). But many eventually realise that it's just not possible to reduce the amount of context switching to an optimal level. 

Another angle to tackle the problem is to have systems that allow you to quickly change between tasks. If we can minimise the time taken to 'get into it' then we decrease the cost of context switching. Placeholders are just such a system.

Examples of placeholders:

• TODO's in code. Make them specific: "TODO: add type hints to this function"
• Stopping writing mid-sentence. "There are numerous benefits of intermittent fasting, including...." or "One promising method might be mechanistic interpretability. Smith et al define this as...."
• When problem-solving: describe the context and thought process. e.g. say I'm trying to decide how to solve a programming issue but have a meeting in 5. I might write: "this function needs to get all the files for a given fiscal week but they only have dates in the filenames, you think there might be a function to convert date to FW in Jacks' utils package but haven't asked him, he might be off today?". This basically allows you to jump back into your thought process. 
• At the end of a few hours of online research, create a short summary of the best websites you found, and why you found them valuable

Context: I work as a remote developer in a government department. 
 

Practices that help:

• Show up at least 3 minutes early to every meeting. Change your clocks to run 3 minutes ahead if you can't discipline yourself to do it. Shows commitment.
  • On a related note, take personal time to reflect before a meeting. Think of questions you want to ask or what you want to achieve, even if you're not hosting the meeting and you just do it for 5 minutes. 
  • Try scheduling a calendar reminder with an intention before the meeting. Ex: Say back what others said before you speak (active listening). Ex: Go out of your way to help. Ex: Red team ideas. 
• Create a physical calendar and cross off days until the end of a project. Creates urgency. 
• Displace email communication to some organised form/tracker. Ex: When I have a bunch of bug/features to write code for, I'll ask people to put their comments in one centralised spreadsheet instead of keeping track of email threads. 
• Host events to build personal connections. Ex: Games lunches, making cards for someone who just had a baby, etc. Takes virtual relationships a lot further.
• Ask for recurring feedback. Ex: in a weekly meeting. Forces people to actually reflect on how you've been doing instead of giving superficial answers impromptu. Also, normalises negative feedback as well as positive. 
  • If you do get superficial responses: "X looks awesome!" - ask followups like: "Could you give me an example of what went well so that I know what to keep doing?" 

Try "managing up" with a simple text document during meetings.

I'm the main contributor on a project with a light management layer. The autonomy' s nice. But it's given a lot of space for stakeholders to spend check-ins talking about their long term wish list (which is fun for them) while avoiding the prioritization I need them to do. 

Recently, I started bringing a text document into check-ins on my understanding on what the priorities, editing it as the meeting goes, and assigning items as (In progress), (todo), or (nice-to-have). It's Kanban in spirit but without the overhead of actually running Trello / Jira/ Notion.

• Circulating meeting materials 1-3 days prior to facilitate deeper discussions
• To be very clear about "what is the ask" at the start and end of every email/paper/deck of slides. Is it just for awareness, or is the recepient supposed to discuss something proposed, give suggestions or endorse it.
• Identifying actionable followups from the notes taken at every meeting/conference/ seminar/paper

User interviews for everything — including written content

• What these are: Say you’re working on a project of some kind. Its output could be a write-up, a website, an event, a course, etc. User interviews involve figuring out who’d use or engage with the thing you’re working on (the users), and then asking people from this group questions (and get them to show you how they use some things) to figure out things like: 
  • How might they hear about or discover your project?
  • Will they be able to easily use it?
  • What are their actual needs? (Maybe you know that they want to start working on effective animal advocacy but are struggling. You’re interested in building a jobs board. But is that their problem? Maybe they already have a list of jobs, but don’t know which are most impactful, or they’re applying but can’t tell which are appropriate given their skillset, or they would like to develop their skills…)
  • Relatedly: maybe people are generally positive about your idea, but would they actually use what you’re working on? 
  • See the Mom Test (here's a video summary, or Wizard of Oz testing)
• Highlight: One mini revelation for me was that you can also do a fair amount of user interviewing for written content — even stuff like Forum posts.^[1]
  • E.g. say you've got a broad topic you want to write about — maybe it's an explainer on economic growth, but you don't know exactly what to focus on (you don't really know what questions people have). You can make a Notion doc with headings making points you could write out ("How economic growth relates to happiness," "How economic growth is measured," etc.). But don't write those sections out. Instead, collapse them in the doc, and ask a few people from your target audience to explore it in front of you, and see what sections they uncollapse — which sections they seem interested in. 
  • There’s a book called “Write Useful Books” which I think is primarily on stuff like this, although I haven’t read the whole thing.
• Resources: I expect people who are not me will have better suggestions on what can help develop user-testing skills, but the thing that’s worked best for me so far was first sitting in on some user interviews, and then just getting through some on my own, gradually getting a bit better. I also read a bit about it. See also the page on product management, although it’s a bit sparse.

1. ^{^}

   I don’t always do anything like user interviews on my writing, but I've done it occasionally and it’s seemed to turn out well when I have.

Try to minimise meetings and get as much done over Slack / by messaging people.

Having routine office-wide deep work times

Having a Google doc for people you have regular meetings with (e.g. supervisors) and writing down all the non-urgent things that come to your mind that you want to discuss with them. That doc will fill with stuff before your next meeting.

Having an accountability buddy. I suspect most people already know what this is (having someone who knows your daily/weekly/monthly goals and helps you stay committed to them).

It's probably a more commonly known practice than those in the other comments but still an underrated one. 

Using an Kanban Type system for group things. The whole Inbox, Doing, Done is a good visual way to see if something has been lagging. I did it with PKM on obsidian, and then implemented it with my publishing house and it's been great.