As CEO of Disney, Michael Eisner had a policy that any employee could come to his office and pitch an idea. He believed that breaking down hierarchical barriers allowed innovative ideas to come from anywhere, and it worked. Disney invested in many of those pitches, some of which became the kernels for films like The Little Mermaid and Pocahontas. 
At Heroku, we know our employees are full of innovative ideas waiting for investment. That’s why any engineer can propose a project through a process we call Research Grants. If the proposal is funded, that engineer gets about two weeks to experiment with their idea and create a work product that can lead to innovative new technologies or even turn into a Heroku feature.
The Research Grants program has been in place for more than a year, but it's really the formalization of an ad hoc process that’s been a part of our Heroku culture since the early days. In the last year we've seen a wealth of innovation powering new products, modernizing our infrastructure, eliminating friction for our users, and reducing our cost-to-serve. Here's how it works.
One little spark
Research Grants usually start with a problem. Sometimes it's an engineer's own itch or a rough spot customers repeatedly stumble into. When smart people encounter one of these problems they tend to think of very clever ways to solve them. All we need to do as a company is give them a path they can follow to turn the idea into a reality.
Once the idea has been formulated, the engineer drafts a Research Grant proposal using a simple template. The template is meant to roughly imitate the scientific method, and has three parts:
- Question(s) - these are what we’re hoping to answer as part of the research
- Prediction - a hypothesis; what we expect the results to show
- Procedure - how the work will be conducted, how long it will take, and what artifacts will be delivered
The questions stem from the problem the research is hoping to solve. For example, "can we reduce costs by reusing dynos in our tests?" or "can we use open source frameworks as a platform for functions-as-a-service?" or "can we use static typing in Ruby?"
Once written, a proposal is submitted to a Research Grant Oversight Committee for review. The committee takes different shapes in each department, but is always a cross-sectional representation of leadership including architecture, management, and product. The committee evaluates the merits of the proposal, and decides to accept or reject it.
The review process is important for two reasons. First, it ensures that the idea is valuable to the business--Research Grants aren't meant to support wild tangents from our core mission. Second, they create an environment of institutionalized creative friction, which was another one of Eisner's values. He believed good ideas come from supportive conflict, which requires some amount of friction. If an idea needs more thought, the committee will tell the engineer who proposed it. It’s the only way they'll be able to improve the proposal or do better next time.
After the funding period, the researcher usually delivers a report and sometimes a prototype. This creates a strong foundation from which the idea can grow towards a prioritized project that an entire team could work on. Because the product owners and engineering managers have been involved from the outset, we don’t need to resell the idea. The stakeholders are already invested.
A whole new world
Research Grants allow ideas to work their way from the bottom up while adding value to the business. This is an important characteristic because it corrects some of the mistakes made by other programs designed to encourage innovation.
Google's defunct 80/20 policy and similar programs allow engineers to experiment at their own discretion. Some great ideas and technologies have come out of these programs, but they lack a strong connection to the business. As a result, they are often reduced to a perk, rather than a tool for driving innovation the company can benefit from.
A Research Grant's focus on business value is important to the engineer doing the research as well. When you take advantage of a perk like Google’s 80/20 policy, the cool Uber-for-cats app you made won't help you get that raise or promotion. But when a Research Grant is successful, it will look excellent in your portfolio.
Research Grants also provide constraints that 80/20 cannot. If people work on a blank canvas with no rules, they tend to think too much or never finish what they've started because the scope can quickly become too big. Research Grants create a clear timebox and a goal that engineers can work toward because the system forces them to define those upfront.
Be our guest
We'd love to see other organizations copy or borrow the Research Grant model. If you want to get started quickly you can fork our template GitHub repository. We use Git to facilitate our proposal and review process, which makes the program very developer-oriented (like most things at Heroku).
If you give Research Grants a try, reach out and let us know how it goes, what you learned, and what you would change. If you have questions or feedback, open an issue on the GitHub template.