Skip to main content

How to write a grant proposal for industry

I've recently had the pleasure of reviewing proposals for Google's Research Awards program. This is a huge program that gives away millions of dollars a year to a large number of university research projects ranging from machine vision to human-computer interaction to mobile systems. After spending eight years in academia struggling to get funding for my own research, it is quite nice to be on the other side of the table and be the one helping to give away the money, rather than begging for it.

First of all, this is nothing like reviewing proposals for, say, the NSF, where you have 15-20 page proposals and project sizes ranging from 3-5 years and anywhere from one to ten PIs. The Google proposals are (thankfully) short -- only 3 pages -- and generally ask for funding for a couple of grad students for a year, plus some funding for a summer month of a PI and maybe some equipment. So the individual grants are small, which in some sense is frustrating since it's hard to propose anything big and groundbreaking when it's just for a year. Essentially this means that most PIs are only asking for money for things they are already working on, rather than spearheading work in a new direction. (Arguably Google should be giving away more money to fewer schools for longer periods of time, but this is my personal opinion.) Also, NSF proposals are reviewed by a panel of (mostly) academics drawn from all over the place, who are supposed to be impartial. At Google, the reviewers are both researchers and software engineers who may or may not be working in areas related to the proposal itself.

Most of the proposals I saw left something to be desired. Far too many of them were asking for money for things that we already know how to do (like write an Android app for your pet project) or which have been done to death (like develop yet another mobile ad hoc routing protocol). On the other hand there were the rare proposals that had an exciting new idea and proposed to do something that Google was not about to go do on its own.

A few tips if you ever apply to this program (and I certainly encourage you to do so).

First, think about who the reviewers are. They are mostly not people like me. Most of the engineers at Google don't have a lot of experience reading and reviewing research proposals (let alone writing them), and many of them are not going to be in your immediate research area. Try to reach out and explain why your work is important at a broader level; the reviewers in this case are typically not your peers.

Second, think about why Google should fund this research. The key question I asked myself was not whether Google would benefit from the research, but rather why should Google fund a university to do this project, rather than just do it ourselves. If Google can hire a couple of engineers to solve a problem, I don't see any reason for us to fund a university to do it instead. On the other hand, if the university PIs are going to do something hard, or groundbreaking, or risky that Google would not have the time or resources to do, we should fund it.

There's also the related question of why should Google fund a research effort rather than another funding agency, such as the NSF. This one is a lot easier to answer: I know from experience that it's damned hard to get money from the NSF for many kinds of projects, and Google can help seed new research efforts that would be difficult to get off the ground otherwise. But if a project seems like it can and should be funded through another agency, that makes it less attractive from my perspective.

Third, try to get the exciting ideas up front. Most Googlers are extremely busy and probably won't spend as much time reading the proposals as you'd like them to. If you bury the lead it will be much harder for the reviewers to see the big idea and get excited about your work. It also helps to establish your credentials in the proposal itself -- not just your CV, but a paragraph or two in the main text saying who you are and why you are the right person to do this research is incredibly helpful (especially in the case when the reviewer is outside your area).

Finally, it always helps to have a champion at Google. If there is someone within the company that you know personally, who can vouch for your work and wants to work with you on a project, this helps tremendously. Having a grad student spend time at Google as an intern is a great way to make those connections.

It's just a guess, but I would not be surprised if other companies' research grants worked in much the same way. While I was at Harvard, I got a lot of funding through places like Microsoft Research, Intel, IBM, and Sun, all of which have fantastic university research programs. (Well, except for Sun, which no longer exists.) Of course, keep in mind that I don't speak for the rest of the Google Research Awards committee, and other reviewers very likely use different criteria than I do.

This is my personal blog. The views expressed here are mine alone and not those of my employer. 


  1. If there is someone within the company that you know personally, who can vouch for your work and wants to work with you on a project, this helps tremendously.

    That sounds a lot like the paper acceptance process, how diligent is Google in making sure the process does not turn political? Is there some sort of double-blind rule, or the rule where if you personally know the PI involved, e.g. someone who's a faculty in the university you were formerly at, you can't make the decision?

  2. Anon - first of all, Google never promises that the proposal review process will be "fair" or "unbiased." This isn't the NSF. Google can decide for itself how to use its money.

    That said, there is a desire internally to give everyone a fair shot. Any reviewer on a proposal is asked to disclose whatever relationship they have with the PI, and since the PI also mentions their Google sponsors/contacts in the proposal. However, nothing prevents us from deciding to fund one proposal over another based on factors like the PI's reputation, their relationship with Google, and so forth.

    I realize that the academic community believes that everything should be fair and unbiased but that's not how the real world works.


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…