Why Is Deep-Tech R&D So Fundamentally Different?

The one thing you need to know about deep tech R&D

What is it that makes a deep tech startup so different?

Not why the business-investing perspective of it is different, why is deep tech any different than non deep tech at the core?

Recently I had the opportunity to talk with a lot of other startups and colleagues about how they deal with challenges in their company’s R&D.

It dawned on me that I was extremely familiar with the in’s and out’s of what they were talking about. In fact, for every single event they described, I found myself recalling a similar thing that had happened somewhere along my own, now somewhat lengthy, career path.

Recalling all these events in a short period of time made me realize there is an important truth here about R&D in general, and deep tech R&D in particular that is worth pointing out.

But first things first …

What is R & D ?

R&D stands for Research & Development …

Research …. and … Development.

Research

And

Development

It really doesn’t matter how many times I repeat it, the point is, there are two meaningful words here: Research and Development (yep — did it again).

While the meaning of these words can span quite broad definitions, the acronym R&D remains the same across tech companies, and exactly how much R and how much D depends on what the company actually does.

It makes sense that a deep-tech company, whose core business relies on its deep tech will have more R than a non deep-tech company. But companies build products, not tech, and a product is much more than its tech.

A product is a beast of its own. And even when a product’s core is its deep tech, there is so much non deep-tech surrounding it: frameworks and infrastructure, comprehensive backend, dashboards, APIs, SW components, hardware and installations or slick UI/UX — a product is much more than its core tech.

So in the end, the vast majority of the Hi-Tech industry spends more of its resources on development tasks than research tasks — on the D and not the R.

But whether it be R or D, an R&D goal is to deliver a working product.

An awesome, working product! (assuming your product guys did a great job defining the product, but this is another topic altogether)

As R&D, we aim to deliver the best working product using as little time and cost as possible.

R&D in practice

Now, this is not as easy as it sounds. Even when the product is a completely non deep tech, you still have a lot of engineering, design, scale, cost and time challenges to solve.

There is always a back and forth between R&D, Product and Product-Market to try to set the best plan possible. The best product roadmap. What features can we have? Can we do this and that? How long will it take? What do customers prefer? And so on. And this roadmap relies heavily on R&D effort estimations.

An experienced developer or manager usually hits 20% uncertainty in his plans, and plans of such nature are indeed executed within this boundary of uncertainty.

Well, that is if they’re D plans …

Deep tech R&D

Enter Deep-tech

With deep-tech, more objectively difficult problems need to be solved. And as such, more objectively difficult tasks need to be completed. The higher the difficulty, the higher the uncertainty of delivering them.

When you ask a capable web developer, ‘how much time do you think it will take you to do a typical development task?’, a typical answer might be ‘3–4 days, give or take’. When you ask a capable algorithm engineer the same for a typical research task, a typical answer might be, ‘3 months +(2 to 4) months, followed by another 6 months to perfect’. Now, this is obviously dependent on the task at hand, but those are real typical answers from capable engineers, which illustrates the magnitude of difference in task handling.

At this point you might be thinking, wait a minute, this is idiotic. If I give the capable web developer a big enough task to work on, a project or a big feature, he will give me the same estimations, no? Similarly, let the capable algorithm engineer break down his plan to small, one-week tasks. What’s the big difference?

Well, while the web developer can break down a big project to tasks and make a plan that he can deliver within +/- 20% of the estimated time, the algorithm engineer working on a research task simply can not. When asked for a breakdown of tasks, you will find yourself having something like the following conversation:

A conversation with your algorithm engineer

Can you break down your plan for me?

Well, first let me get a full understanding of the problem. Then I will need to search and read a bit to find the most promising academic solutions for this problem. Then I need to quickly implement what seems to be the most promising one. Then I will do an initial test to see if this approach is getting us anywhere…

And then?

Then we’ll see, it really depends on the results. If the results are this, I might tweak it a little, if they are that, I might go and check the other solution. If they are so and so however, I will proceed with more testing.

Ok, and then?

Well, again it really depends on the results — I can’t see this far ahead or make such a complicated decision tree. I will need to feel it and see where the wind blows. But I think that within about 3 months we should be getting something, we’ll see.

How do you know it will take that long?

Well, I don’t. But there are some similarities between this problem and some other problem I worked on in the past. Although this, this and that are completely different so we will have to see how it plays out …

Can you set a deadline for delivery?

I can roughly estimate the time for my first tests, but afterwards I really can’t know.

There are simply too many unknowns. But don’t worry, we’ll figure it out, we always do. It just takes a little time.

This exchange only emphasizes the differences in two very different crafts and mindsets (researchers and developers). The confusing part is that they both usually use software to perform their craft, so it’s easy to expect similar approaches. But both crafts, simply put, are very different and require very different mindsets.

That being said, there are a whole wide range of problem difficulties and uncertainties, and developers do stumble upon a problem that requires a more research-like approach from time to time. A good example of this would be a rarely reproduced bug, where you find yourself in ‘detective’ mode for an unusually long period of time (a month even).

The Fundamental R&D Graph

Like all good engineering stories, this one also includes a graph.

Without getting into detailed definitions of problems, goals and tasks, I’ll just say that a task is when you try to solve a problem or achieve a goal in a specific way.

In an attempt to summarize the relationship between task difficulty and uncertainty, a simple graph comes to mind.

The harder the task the higher the uncertainty in delivering it.

A simple task like writing ‘hello world’ in your go-to language has very little uncertainty in delivery. When it comes to an impossible task though, you most likely don’t even know it’s impossible.

Since every task has a different expected delivery time, the uncertainty is normalized to the expected delivery time (percentage). So this graph does not say that a simple task will take a short amount of time and a difficult task a long time.

A big project that may take a lot of time can still be simple with low uncertainty. Conversely, developing something that traditionally takes a lot of effort or cost with new, groundbreaking tech that initially has a lot of uncertainty is a big part of what deep tech is.

That being said, a task starts somewhere on the graph and the more effort you put into it, the less uncertain it becomes. This does not happen by itself. It always requires effort. But the more effort, the more you advance in your research or development, the more clear and certain it becomes. Always moving down the curve from left to right.

Recognizing where you are

The 3 main classes

It is common to use 20% uncertainty as the drawing line for development, for the D. Namely, we have a development content plan in hand: we know what we need to do and exactly how to do it. Yes we have some uncertainties, but we know how to manage them. The next steps are very clear: prioritize, create a plan, and execute.

Just above that is what is widely known as a Proof of Concept (PoC). A PoC is when you have a list of things you need to prove, and if they are proven, you can move forward with a well defined development content plan.

And above that is research.

In research, you are in a cycle of validation. First you need to formulate the problem. Then you come up with ideas for a solution, evaluate the ideas, select and adjust and go back to evaluate again, until it is good enough in terms of product-market fit. (Recall the previous conversation with the algorithm engineer)

I emphasize the good enough part, as it is in the researcher’s nature to always make the solution better and enter another adjust-and-evaluate cycle, and this is exactly the point where deep-tech deliveries may go astray.

How to recognize where a task should be placed:

There are two simple questions here that I find very helpful:

1.What exactly needs to be done to deliver?

We need to first do “x” and see the results (Research).

If we prove A,B and C we can develop “x” and “y” (PoC).

Execute this development content plan (Development).

And

2.Was it done before ?

No (1000% uncertainty).

There are a few academic papers (~200% uncertainty).

There are many academic papers (~100% uncertainty).

It was done by one company (~75% uncertainty).

A similar thing is known but not exactly what we want to do (~50% uncertainty).

This company did something similar but not with this and that (~50% uncertainty).

I did a similar thing once (~30% uncertainty).

I did similar things many times (~15% uncertainty).

I didn’t do it, but it’s common knowledge. Here is a recipe for doing exactly that (~15% uncertainty).

Sure, I do exactly that all the time (~10% uncertainty).

And so on.

No matter how big or small a task may be, the point is that you have to recognize the task’s level of uncertainty in order to follow up with a suitable process.

Moving towards a working process

Everything so far has only set the foundation for the hard work to begin.

In my company, we follow different processes for Research, PoC and Development. We recognize and manage all of our tasks throughout their R&D lifecycle accordingly. All the way from highly uncertain R tasks, through D level till delivery.

We do not hide from the complexity of it, we do not avoid tough decision making in uncertain environments, and we do not give up in face of a challenge.

We face it head on.

And try to be smart about it.

How do you handle it?

What does your process look like?

Whatever it may be…

You’ve got to love deep-tech R&D.