How to succeed as an early-stage researcher: the “lean startup” approach

I am approaching the end of my AI governance PhD, and I’ve spent about 2.5 years as a researcher at FHI. During that time, I’ve learnt a lot about the formula for successful early-career research.

This post summarises my advice for people in the first couple of years. Research is really hard, and I want people to avoid the mistakes I’ve made.

My argument: At the early stage of your research career, you should think of yourself as an entrepreneur trying to build products (i.e. research outputs) that customers (i.e. the broader community) want to consume.

You might be thinking: but I thought I was trying to maximise my impact? Sure, but at this stage in your career, you don’t know what’s impactful. You should be epistemically humble and responsive to feedback from people you respect. You should be opportunistic, willing to pivot quickly.

I am calling this the “lean startup” approach to research. By now, everyone knows that most startup ideas are bad, and that founders should embrace this: testing minimal versions of the product, getting feedback from customers, iterating, and making dramatic changes where necessary. When you’re starting out in research, it’s the same.

Early-stage researchers have two big problems. Number one, all your project ideas are bad. Number two, once you’ve written something, nobody is going to read it. It’s like an app that nobody downloads. It is possible to avoid these pitfalls, but that requires active effort. I will list many strategies that I’ve found helpful. At the end of the post, I’ll give a few examples from my own career.

A lot of this advice is stolen from people who have helped me over the years. I encourage you to try it out.

EDIT: I am most familiar with AI governance. I’m not sure how well my views generalise to other fields. (Thanks to the commenters who raised this issue.)

Problem 1: your project ideas are bad

In the early stage of your research career, 80-100% of your project ideas are bad. You’ll feel like your favourite project idea is great, but then years later, you’ll ask yourself: “what was I thinking?”

Executing an idea requires a large time investment. You don’t want to waste that time on a bad idea.

By “project idea” I mean not just a topic, but some initial framing of the problem, and some promising ideas for what kind of arguments or results you might produce. So, how do you find a good one of those?


  1. Ideally, someone senior tells you what to work on. But this is time-expensive for them, and they don’t want to give away their best ideas to somebody who might execute them badly. So more realistically…

  2. Write out at least 10 project ideas, and ask somebody more senior to rank the best few. Always keep this list and add to it over time. This is a tried-and-tested method and it works very well. If you are pushing just one, single project idea, you might be able to arouse some minor, polite interest from other people, but this is a much less meaningful feedback process.

  3. Notice when people are genuinely interested. Sometimes you will get a cue that a person is actually interested in a puzzle or argument that you’ve formulated. You notice that they’ve been nerd sniped. That’s a very valuable feedback signal. It is also a reason to recentre the project around the exact question that nerd sniped them. Because you don’t yet have a well-developed sense of what issues are most interesting, you should update heavily on this kind of feedback. (As you get more experienced, you can allow yourself to get nerd sniped by your own ideas.)

  4. Fit into an established paradigm. While at FHI I have gradually absorbed a sense of the implicit worldviews of senior people, and what kinds of problems they think are important and interesting. You can get some of this from reading papers. One good strategy is to extend a line of inquiry that existing research has begun. Read existing literature and think: can I add anything to this? It’s tempting to look for an idea that everyone has completely missed — something paradigm-shifting. Perhaps that would be good in theory, but most likely, you’re too inexperienced and ignorant to actually pull this off.

  5. Ask yourself: why do we care? Often, early-stage researchers will have ideas that are loosely connected to important topics, but not enough for people to actually care about the answer. A mental exercise: imagine the best-case scenario, where your research produces some strong, unexpected conclusion. Is that conclusion going to be relevant to anyone? Should it affect what key actors do, e.g. what regulation should be enacted, or what strategies AI labs should adopt? I’m not saying you need to do applied research, or have a detailed “theory of impact”. Just make sure that people are going to care about the result.

  6. Go where there’s supervision. If a respected, experienced researcher is willing to supervise particular research projects, that’s a very strong reason to do that research.

  7. Strongly consider doing empirical work. Early on, your comparative advantage probably isn’t producing ingenious, theoretical insights. (Unless you are unusually smart, and unusually knowledgeable about the existing literature and unwritten ideas.) Your comparative advantage, relative to established researchers, is that you have: more time on your hands, less other important stuff to be getting on with, and more enthusiasm for doing donkey work. Therefore, one strategy is to find a project that is important and yet requires drudgery. Collecting and analysing data is good, whether that’s quantitative or qualitative. In my case, within my PhD work, I’ve done about 40 interviews with AI researchers. That means people see me as an expert on certain topics.

Problem 2: nobody cares about your work

The biggest challenge is just getting anybody to read your work.

You think you’re solving important problems and people will value the answers. But then you finish writing, you share what you’ve made, and nobody has time to look at it. Even if it’s got a cool title and a good summary (which helps), many people will think to themselves: “Nice, I’m looking forward to reading that”, and then never get around to it. Or they’ll skim read the first two pages and then get distracted.


  1. Work on problems that people actually want the answers to. (See above.)

  2. Find an elegant way of describing your argument /​ findings. Your elevator pitch shouldn’t be: “I’ve explored this area, and I’ve come up with 11 different thoughts on the topic” (a common mistake). Ideally, it should be: here’s my neat encapsulation of a puzzle, and here’s my clean solution to that puzzle. Your high-level framing of the project will change over time, as you get more and more clarity. Publishing the work as an academic article will help with this, because your reviewers aren’t going to accept some “exploration” and accompany opinions. They’re going to want something slick.

  3. Go narrow. Early-stage researchers have a bias towards biting off more than they can chew. If you focus on a narrow problem, you might actually be able to offer an expert treatment of that problem. You don’t want to cover a broad space of ideas and be the 10,000th best-qualified person in the world to write about each one.

  4. Focus on the title, abstract, and introduction. These should be snappy, polished, and should grab the reader. The introduction is a great chance to frame your contribution.

  5. Draft and re-draft (and re-draft). The writing should go through many iterations. You make drafts, you share them with a few people, you do something else for a week. Maybe nobody has read the draft, but you come back and you’ve rejuvenated your wonderful capacity to look at the work and know why it’s terrible. Imagine a threshold of quality where, once the piece is good enough, an important and busy person considers it worth their time to read. Anything under that threshold has very little value, but cross it, and suddenly you’re in business. (Note: I’m talking about your main research projects; half-baked ideas might be fine in other contexts.)

  6. Write clearly. Your writing style should help the reader, packaging the ideas for easy consumption. Assume the reader is very easily distracted, and has almost no ability to store information in their working memory. (I’ve followed my own advice in this post, so apologies for the lack of epistemic hedging!)

  7. Publish. The final output of your project should ideally be an academic article, a blog post, a publicly-available report, or something similarly accessible. This has a bunch of benefits. Most obviously, people can actually read your work. They can share it with colleagues, talk about it, cite it, build upon it, etc. Also, your colleagues are more likely to give feedback on a piece that’s actually going somewhere. And finally, publishing the work forces you to actually make it good. Sometimes people use Google Docs for the final product, which doesn’t have these same benefits. Google Docs works well for info hazards, but I’d avoid working on info hazardous topics until you know somebody will actually read what you write. It’s fine when you have established a customer base for your research, or have some other reason to be confident that you’ll get eyeballs on your doc (e.g. the work has been commissioned).

  8. Market your work. Successful academics know how to do this. One strategy is to have multiple places where people can consume your work. There’s a journal article, a pre-print, a blog post, a Twitter thread, a podcast interview, a talk, and a YouTube link to the talk. Relatedly, there should be multiple in-bound links to your paper. This is another benefit of publishing your work in an academic venue. The publisher might do some SEO; readers might stumble across your work accidentally; if your work is respectable and therefore citable, then those citations will provide more in-bound links.

  9. Co-author. If you have a co-author, you have somebody you can bounce ideas off, somebody who can read and give comments, and somebody who can help to market the work. If the co-author has prestige, that will help for getting readers.

The “lean startup” approach in action

I have two examples where the “lean startup” approach has really benefited my work.

Example 1: Early in my PhD, somebody I respect told me that I should narrow my focus, zooming in on one of my topics (publication norms in AI research). Soon after, OpenAI published their GPT-2 blog post. I was following lots of AI researchers on Twitter and there was a big negative reaction. I was supposed to be doing something else that day, but instead I spent all day collecting and cataloging these tweets. When I was done, I showed some people, and I was surprised at how excited they were. Somebody encouraged me to make the analysis slightly more in-depth, running a few regressions, so I did. They shared the Google Doc with people at FHI and elsewhere, and it got lots of interested commenters. In retrospect, this experience really made me pivot. I started doing a case study on GPT-2 for my PhD research, and (after people still being interested) I extended this work into nearby areas. This has worked really well for me.

Example 2: My most successful paper grew out of a similar process. I had interviewed some AI researchers who were making the following argument: if GPT-2 can be misused by bad actors, then the model should be open sourced, because this actually helps people defend against misuse. For example, people can turn GPT-2 into a classifier for machine-generated text. This argument was bouncing around in my head. At the same time, Peter Cihon and I were looking into the history of responsible disclosure in computer security. I noticed that my AI researcher interviewees were plagiarising their argument from computer security researchers — computer security researchers often say that software vulnerabilities should be widely shared because this encourages software-makers to find a patch. But I felt like there were holes in the analogy: with AI misuse, how easily can the “vulnerability” be patched? I was in a meeting at GovAI and we were going around the table giving updates on what we were working on. I casually mentioned this stuff, and Jeff Ding said in a serious-seeming way: “that’s actually a really interesting and original point.” When I spoke to Allan Dafoe, he was clearly excited and enthusiastic about the idea. We co-authored a conference paper, with me iteratively refining the ideas in response to Allan’s feedback. Somewhere buried in the paper, I used the phrase “offense-defense balance of scientific knowledge” and Allan liked the phrase; so, that became the title. I wrote the paper instead of doing the other stuff I was supposed to be doing. The paper was well-received and was great for my career. Why was the paper idea so good? I could probably give a much better answer now, two years later, than I could at the time. I’m glad that, at the time, I went with the flow.

Counter-example: I am soon going to share a paper called “Structured access to AI capabilities: an emerging paradigm for safe AI deployment”. When I first floated a very underdeveloped, early version of the idea with some colleagues, it got a lukewarm response. I started working on the paper anyway. People got excited when they saw the first draft, and more so when I gave a talk at FHI. I initially took a more Steve Jobs style, “the customer doesn’t know what they want until you show it to them” approach, but then took the subsequent positive feedback as a sign that I should invest further in the idea. This reflects the fact that, now that I’ve got more knowledge and experience, I can have a slightly stronger prior in favour of my ideas being decent.


The lean startup approach to early-career research involves immersing yourself in an intellectual community. This is an uphill struggle, because at the start, you don’t have much to add to that community. You have to find something to offer, using what little feedback you can get. (Although to some extent, you need someone to make a bet on you.) If there’s an existing group of people who care about a particular topic, that’s a great opportunity. Don’t pigeon-hole yourself as somebody who is only going to work on a particular topic. Having mentors, collaborators, and people who will read your work is extremely valuable.

[Meta: I wrote this yesterday when I was supposed to be doing something else. It started as an email to the first-year research scholars at FHI, but while writing the email, I realised it might make a good forum post. A colleague walked into my room and I told him the first two subheadings (“your project ideas are bad” and “nobody cares about your work”); his reaction made me think I should make the post less depressing. When I was writing the conclusion, the phrase “lean startup” came into my head, and I rewrote the title and introduction to fit that framing. Thanks to Allan Dafoe and Markus Anderljung for helpful comments. Thanks to Allan for general mentorship and support.]