Building Deep Tech Engineering Teams When the Path Is Not Written Yet

When people look at OmniShelf today, they see a team, a product, a system that works.
What they do not see is the quiet moment years ago when I sat alone in front of a blank whiteboard, staring at a problem that had no known solution. No roadmap. No example to copy. No one to ask for help.

‍

Deep tech begins with solitude.
It begins with uncertainty.
And this is the story of how that uncertainty slowly became a team.

‍

Why Deep Tech Does Not Behave Like SaaS

‍

I remember one afternoon testing an early prototype.
The algorithm refused to improve. We tried adjusting parameters, retraining models, changing data strategies. Nothing moved. Hours turned into days. For someone watching from outside, this might have looked like failure. For me, it was a familiar part of the process.

‍

Most software teams would respond by adjusting a sprint, reallocating tasks or estimating the next release date. But deep tech does not listen to estimates. It does not move because you want it to. It moves when a scientific insight appears, and that insight refuses to follow a schedule.

‍

You cannot set targets like
"Let us increase accuracy by two percent by next week."
Breakthroughs do not work like that.

‍

In classical software, you count potatoes. You know the shape of the work, the pace of the team and the direction of the project.

‍
In deep tech, there are no potatoes. The thing you are trying to build might not even be possible yet.

‍

And yet you continue. That is the mindset that separates deep tech from everything else.

‍

The Kind of Team You Need When the Map Does Not Exist

One morning, during an early stand-up, something struck me.

‍
Everyone was reporting progress, but the puzzle pieces were drifting.

• The mobile engineer was making headway, but without understanding the constraints of the backend.
• The backend engineer was building features, but without visibility into machine learning latency.
• The machine learning researcher had ideas, but no sense of how they would affect the real-time experience of a store employee.

‍

It was not incompetence. It was fragmentation.
We were fifteen specialists speaking fifteen different dialects.

And I realised something very important.
If deep tech is a landscape without a map, then someone has to see the whole terrain.

‍

My own experience had taken me across embedded systems, infrastructure, mobile development, backend development, mathematics and machine learning. That breadth became the bridge that kept the team aligned. It allowed me to decompose problems and show each specialist how their part connected to the whole.

‍

Deep tech does not reward large teams. It rewards teams with shared context.
A small group, senior and aligned, can do what a large team cannot. Because they build one solution, not fifteen partial ones.

‍

What Problem Solving Actually Looks Like in Deep Tech

‍

There is a moment that repeats itself often.

‍

A new problem arises. The team waits for me to assign tasks. Instead, I walk to the whiteboard. I do not start with code. I start with silence.

I draw a shape. Then erase it.
I draw arrows. Then cross them out.
I stand still and imagine flows, constraints, failures that have not happened yet.

Only after that do we talk about experiments.
Some ideas are safe. We know they will move us a little forward.
Others are risky. They might collapse completely or unlock something we did not know was possible.

‍

Choosing the right experiment is not luck. It is the slow build-up of intuition.

‍

Intuition is not mystical. It is earned. It grows from failures that taught you more than success ever could.

‍

Deep tech engineering contains mathematics and strategy, but also something softer.

• A rhythm.
• A feeling for when the idea is ready.
• A sense of when to chase the risky path because the safe one will trap you later.

That is the part no textbook explains.

‍

First principal approach + simplicity = intelligence

‍

There was a week when nothing worked.

Three approaches failed. Timelines stretched. Doubts crept in. Not from the team, but from the environment around us. People outside the engineering room often expect linear progress.

‍

Inside deep tech, linearity does not exist.

‍

In those weeks, leadership is not about giving orders. It is about absorbing uncertainty so the team can continue without fear.

‍
There is no manual for how to lead when the answer does not exist. You learn from others who walked unknown paths.

• Steve Jobs.
• Gandhi.
• Elon Musk.
• Ilya Sutskever.

‍

Unlikely names to appear together, but they have something in common. They moved through uncertainty with adaptability and mission-driven clarity. They accepted pain as part of progress. They understood that opening new paths always carries risk.

‍

These stories mattered to me. They reminded me that leadership is not about certainty. It is about commitment. You keep moving, even while the ground forms under your feet.

‍

When Things Finally Start to Take Shape

I can recall the first time I saw the entire system running end to end.

‍
For years the product had existed as a constellation of components.

• Machine learning was here.
• Infrastructure was there.
• Mobile logic lived in a different corner.
• Backend had its own world.

But one day, the puzzle clicked.

‍
Not perfectly, not fully polished, but recognisable. The shape was there. The system breathed.

‍

That was the moment when we began documenting everything.
Not because documentation was overdue, but because the system finally stood still long enough to be described.

‍
The unknowns were shrinking.
The architecture was emerging.
We were ready to shift from exploration into refinement.

‍

This is the natural progression of deep tech.

• You explore.
• You discover.
• You stabilise.
• Then you scale.

But the order must never be reversed.

‍

Why a Small Team Achieved What Larger Companies Could Not

‍

Whenever people hear about our team size, they ask the same question.

‍How did fifteen engineers build something that corporations with hundreds of engineers could not?

‍

The answer is simple.

• We learned faster than they could.
• We stayed close to the frontier of what was technically possible.
• We iterated without bureaucracy.
• We aligned deeply on the mission.
• We worked as one unit, not fragmented departments.

‍

Innovation is not about headcount.
Innovation is about how quickly a team can absorb new information, adapt and execute.

‍

A large team cannot match that speed unless every person shares context and moves together.
Few companies achieve this. Small deep tech teams often do.

A Final Reflection

‍

Deep tech is not only engineering. It is a form of courage.

‍

• The courage to begin without clear direction.
• The courage to persist when the path vanishes.
• The courage to lead people through ambiguity and protect them from its weight.

‍

When I think back to that blank whiteboard at the beginning of OmniShelf, I realise the most important part of the journey is not that we built a breakthrough product. The most important part is that a small group of people chose to believe in a mission strong enough to keep going when nothing was certain.

‍

In the end, deep tech is not about writing code.
It is about building the path that allows the code to exist.