Research & Development in a Startup

I’ve seen and been in Research & Development (R&D) teams in the past. Sadly I can’t say any of these teams have been successful making a significant impact on the directions company they were serving took. R&D is often mentioned in the context of the military (in 2015, the US Army’s research, development, testing and evaluation (RDT&E), coupled with procurement accounts, made up 18 percent of the budget) or big companies such as Amazon, Google, Apple, Microsoft etc…

Source: https://www.bloomberg.com/view/articles/2016-08-09/amazon-and-google-change-the-r-d-race

But we rarely talk about R&D at a startup stage. As a matter of fact, if you google those terms you will find a lot of articles about R&D tax credits and deductions but little about how other startups tackled setting up a R&D team. As Splice CTO, I believe we reached the stage where it’s important to look ahead and start planning in advance instead of being purely responsive. But how can you plan if you can’t see 6 to 12 months ahead. If your product team (engineers, designers, PMs) are in good hands and executing quarterly objectives in a healthy manner, you probably should consider doing some R&D. I previously talked about why hiring a VP of engineering is crucial and how I (as the CTO) am delegating the day to day operations. This is critical since without that, I couldn’t even consider thinking ahead.

What I want to avoid

I have been on both sides of the R&D line, I know how frustrating it can be to receive a half done concept project that I’m in charge of shipping and maintaining ASAP. I also know how frustrating it feels to work on great research and realize it will never ship because the R&D team is so disconnected from the engineering or business team. Too often R&D teams end up being a group of misfits lead by someone who likes to tinker with new cool stuff and think they can recreate the genesis of the company in a vacuum. Often those people are seen are “smart” and left alone because “we don’t want to lose them” and who knows, maybe they will come up with something amazing? Another common situation is that the company has a special task force that tackles special projects they have to ship outside of the normal dev cycle. Those situations aren’t healthy, they create tension within the teams and put pressure on processes.

I really believe that R&D should be designed to be an integral part of the company and not as a special island where cool projects are being developed. I also think it’s important for engineers and designers to get room to explore different possibilities without relying on a team that did all the design for them. It is important to keep the team motivated but also to help them grow.

Setting goals and scope

Settings goals for a team is a great way to define expectations and making sure we are aligned on why we work a certain way and what we are doing. Let’s first start by breaking down what I hope R&D will accomplish:

• Explore technical & business opportunities
• Evaluate feasibility
• Evaluate technologies

The big question is how do we do that, especially in a software company that believes in small iterations and agile planning? And how do we leave room for the engineering team to discover adequate solutions on their own.

Operating timeline

Now that we have goals we need to understand where the team will operate. By that I mean what part of the company timeline should the team focus on. The way I see it, here is how I break down a yearly timeline:

1. Current quarter: clear roadmap to execute on to well defined objectives coming from the executive team. This is the main focus of the VP of engineering and Product. R&D is not involved.

2. Next quarter: in planning, execs have rough business goals that need to be converted into objectives and metrics. Discuss strategic approaches to get there with VP of product and VP of engineering leading the concretization of the roadmap. R&D to advise if needed, potentially researching something that comes up and that can’t be handled by the “execution team” (more on that later).

3. 6 months from now: R&D to explore opportunities & feasibility to help shape future objectives and strategies. R&D team’s main focus.

Execution and R&D teams

Let’s talk about the execution team in comparison to the R&D team. The execution team is the team in charge of shipping, it’s the frontline team that focuses on this quarter. That team’s primary objective is to deliver solutions to the problems the exec team decided we wanted to tackle this quarter. This is not a team made of “janitors” (term I heard from a manager in a previous company), it’s also not a team of “contractors” that go down a list of stories pre-defined for them. It’s a team made of awesome people who understand our products, necessary compromises, value delivery and see the rubber hit the road on a daily basis. This is the team constantly building and shipping.

In comparison, the R&D team doesn’t ship, or at least not to users. This service team is there to explore very hypothetical or deeply complex questions. Their output is what feeds into the decision making that helps us as a company to pick the problems we want to tackle next quarter or the one after. They help the other teams understand our potential needs for planning, staffing or strategic decisions such as acquisitions. This is not a team of crazy scientists working on whatever might be cool one day. This is a team exploring questions that might get closer to our North Star faster. This is a team that is technical, product and business oriented since they serve those departments. This is a team that always give partial answers to difficult questions so others can use to decide if a problem is worth tackling and when.

Scoping

Some level of research should happens at almost all levels. Very rarely do we have exact answers to questions without spending some time researching/discussing options. Both the execution and the research teams should have room to do that. To help us with terms let’s talk about discovery vs research.

Discovery: is becoming aware of the solution to a well scoped, measurable problem. Discovery is generally short (from a day to a week) and ready to implement almost right away. One way to think about it is that we know a solution is right there, but we need to make sure we discover it.

Research: as per the dictionary definition: “the systematic investigation into and study of materials and sources in order to establish facts and reach new conclusions.” In other words, the gathering and establishments of facts that help us make educated decisions.

The execution team needs discovery time, they are given problems to tackle and have a lot of context but sometimes need room to explore and find the right approach to a specific problem we are about to tackle.

The R&D team is working on longer term research projects, with a less concrete output and lots of throw away work to be able to extract facts and reach new conclusions.

Output

So what should be the output of the R&D team. We talked about extracting facts and reaching new conclusions, but what does that mean?

• The R&D team doesn’t ship code to production. At best the team output might live in a sandbox or as libraries.
• The R&D team doesn’t hand out half-way done projects for engineering & product to finish.
• The R&D team provides engineers, PMs and designers with documented research, prototypes and at times suggestions.

In other words, lots of research documentation that can be leveraged by the executive and execution teams as well as libraries, throw away prototypes and flows.

Misc

• The R&D team isn’t solely technical
• R&D doesn’t handle maintenance and support of their research with the exception of libraries that weren’t explicitly given to another engineering team.
• R&D priorities and backlog are maintained by the CTO based on input from the exec team & other team members.

Research and development isn’t about software architecture/design or solely about technical feasibility and cost. It is about exploring business opportunities ahead of schedule to help the company make educated decisions to define our backlog.

Researching and Developing in the open

It’s crucial that R&D doesn’t operate in a vacuum. The R&D team is a service offered to the rest of the company. While the team doesn’t usually ship things to users, there is a lot of information that can be very valuable to a lot of employees. The work has to be done in the open and make easily available for any employee to dig into or ask questions.

Research documents are organized and made available on an employee-only site.

Stakeholders

While the CTO is running the day to day of R&D, the team can be seen as an “oracle” with various people asking “what if” questions.

The questions should focus around two large themes:

• Business opportunities
• Feature inquires

Here is an example. Marketing is interesting in growing our Windows market since they think there is room for expansion in a specific vertical. They might word a question such as: “what if we wanted to make our service A more valuable to people using products from company B. What could be done to increase conversion of users of company B?”

The request should come with some sort of importance level but with the understanding that the priority of what is being worked on will be made transparent and negotiable at an exec level.

Feature requests are more specific and usually come from designers, PMs and engineers. We have a theory that doing something around X would really help our metrics Y. What if we wanted to work on X, what are our options, what’s the feasibility and potential cost?

We are still at an early stage of settings up R&D at Splice. There are still a lot of unknowns but by trying to define roles, expectations and scope, I believe we put all the odds on our side.