Hide table of contents

Basically every time I’ve worked with new people or on a new kind of project, I’ve learned a practice or method that now seems quite important to how I work. I want to see if we can crowd-source more (and discuss them). 

So share things you’ve learned! I’m sharing some as answers on the thread. 

Note: Please don’t hesitate to share things that you think are common. I expect that fewer people know about them than you might think — especially if you’re from a field or industry where the practice is normal. (Relevant xkcd comic.)

See also: 

I made this image in Midjourney
New Answer
New Comment


15 Answers sorted by

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.

Strong agree! I really like how passing balls works in practice in the forum moderation Slack, it gives energy/momentum instead of draining it.

A small nitpick is that 🤾 to me looks like someone throwing a ball, and I would use ⛹️

When I met my boss he has a different but related theory. It's about the steel ball, rubber ball and glass ball.

The steel ball you can drop and it won't break, but you need to pick it up to keep going.

The rubber ball you can keep bouncing down the line.

The glass ball, once broken can't be fixed. 

You have to identify which item is which.

3
JP Addison🔸
I like this
2
VictoriaS
Anyone mind giving an example for a glass ball?
2
Weaver
For me full-time work(military) there are certain safety regulations regarding when things need to happen and who needs to sign off on them so they can go ahead. A recent example is when we had an emerging requirement that needed a general to sign off on something otherwise six months of planning for an event would be out the window. The general was out of our chain of command and thus wouldn't need us to do the thing we needed, it would just be good training for his people. We had a requirement, they had a requirement and something got lost in the translation, causing us to either make several high-level phone calls or drop the glass ball.
1
VictoriaS
Thanks!

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

+1, this has been a great new learn for me

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.)

Focusmate works incredibly well for me!

 

Some things I really like:

  • If you show up more than 2 mins late your session is cancelled, meaning you'll kind of disappoint the person on the other end of the call, and you have to wait another 13 minutes to get started. That's a big motivation to show up and get started!
  • During the session, there's someone else expecting you to make progress in the next 25/55/75 minutes. I feel way more (healthy) pressure to actually make progress when there's expectations of a stranger (compared to e.g. a colleague or friend)
  • Th
... (read more)

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.

Learn the ‘proper’ way to type.

Is this just directed at people who still use hunt-and-peck, or is there some new “proper” way to type beyond normal [full hand / home key] typing?

2
freedomandutility
But proper way I just mean full hand / home key

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 

FYI this is often called "timeboxing"

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

This is really interesting, thanks for sharing! I try to do this sometimes, but want to make this more of a priority!

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.

While I don't think Trello / Jira/ Notion have significant overhead, +1 for this tip because I think it illustrated something we often forget with productivity/ project management/organising : the best system is one that you can feasible use.

  • 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.

I like using 'Todoist' quick add feature (on mobile and desktop) to do this without having to open up the Gdoc and interrupt my workflow.

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.

Curated and popular this week
 ·  · 25m read
 · 
Epistemic status: This post — the result of a loosely timeboxed ~2-day sprint[1] — is more like “research notes with rough takes” than “report with solid answers.” You should interpret the things we say as best guesses, and not give them much more weight than that. Summary There’s been some discussion of what “transformative AI may arrive soon” might mean for animal advocates. After a very shallow review, we’ve tentatively concluded that radical changes to the animal welfare (AW) field are not yet warranted. In particular: * Some ideas in this space seem fairly promising, but in the “maybe a researcher should look into this” stage, rather than “shovel-ready” * We’re skeptical of the case for most speculative “TAI<>AW” projects * We think the most common version of this argument underrates how radically weird post-“transformative”-AI worlds would be, and how much this harms our ability to predict the longer-run effects of interventions available to us today. Without specific reasons to believe that an intervention is especially robust,[2] we think it’s best to discount its expected value to ~zero. Here’s a brief overview of our (tentative!) actionable takes on this question[3]: ✅ Some things we recommend❌ Some things we don’t recommend * Dedicating some amount of (ongoing) attention to the possibility of “AW lock ins”[4]  * Pursuing other exploratory research on what transformative AI might mean for animals & how to help (we’re unconvinced by most existing proposals, but many of these ideas have received <1 month of research effort from everyone in the space combined — it would be unsurprising if even just a few months of effort turned up better ideas) * Investing in highly “flexible” capacity for advancing animal interests in AI-transformed worlds * Trying to use AI for near-term animal welfare work, and fundraising from donors who have invested in AI * Heavily discounting “normal” interventions that take 10+ years to help animals * “Rowing” on na
 ·  · 3m read
 · 
About the program Hi! We’re Chana and Aric, from the new 80,000 Hours video program. For over a decade, 80,000 Hours has been talking about the world’s most pressing problems in newsletters, articles and many extremely lengthy podcasts. But today’s world calls for video, so we’ve started a video program[1], and we’re so excited to tell you about it! 80,000 Hours is launching AI in Context, a new YouTube channel hosted by Aric Floyd. Together with associated Instagram and TikTok accounts, the channel will aim to inform, entertain, and energize with a mix of long and shortform videos about the risks of transformative AI, and what people can do about them. [Chana has also been experimenting with making shortform videos, which you can check out here; we’re still deciding on what form her content creation will take] We hope to bring our own personalities and perspectives on these issues, alongside humor, earnestness, and nuance. We want to help people make sense of the world we're in and think about what role they might play in the upcoming years of potentially rapid change. Our first long-form video For our first long-form video, we decided to explore AI Futures Project’s AI 2027 scenario (which has been widely discussed on the Forum). It combines quantitative forecasting and storytelling to depict a possible future that might include human extinction, or in a better outcome, “merely” an unprecedented concentration of power. Why? We wanted to start our new channel with a compelling story that viewers can sink their teeth into, and that a wide audience would have reason to watch, even if they don’t yet know who we are or trust our viewpoints yet. (We think a video about “Why AI might pose an existential risk”, for example, might depend more on pre-existing trust to succeed.) We also saw this as an opportunity to tell the world about the ideas and people that have for years been anticipating the progress and dangers of AI (that’s many of you!), and invite the br
 ·  · 3m read
 · 
Hi all, This is a one time cross-post from my substack. If you like it, you can subscribe to the substack at tobiasleenaert.substack.com. Thanks Gaslit by humanity After twenty-five years in the animal liberation movement, I’m still looking for ways to make people see. I’ve given countless talks, co-founded organizations, written numerous articles and cited hundreds of statistics to thousands of people. And yet, most days, I know none of this will do what I hope: open their eyes to the immensity of animal suffering. Sometimes I feel obsessed with finding the ultimate way to make people understand and care. This obsession is about stopping the horror, but it’s also about something else, something harder to put into words: sometimes the suffering feels so enormous that I start doubting my own perception - especially because others don’t seem to see it. It’s as if I am being gaslit by humanity, with its quiet, constant suggestion that I must be overreacting, because no one else seems alarmed. “I must be mad” Some quotes from the book The Lives of Animals, by South African writer and Nobel laureate J.M. Coetzee, may help illustrate this feeling. In his novella, Coetzee speaks through a female vegetarian protagonist named Elisabeth Costello. We see her wrestle with questions of suffering, guilt and responsibility. At one point, Elisabeth makes the following internal observation about her family’s consumption of animal products: “I seem to move around perfectly easily among people, to have perfectly normal relations with them. Is it possible, I ask myself, that all of them are participants in a crime of stupefying proportions? Am I fantasizing it all? I must be mad!” Elisabeth wonders: can something be a crime if billions are participating in it? She goes back and forth on this. On the one hand she can’t not see what she is seeing: “Yet every day I see the evidences. The very people I suspect produce the evidence, exhibit it, offer it to me. Corpses. Fragments of