Engineers, if you need to solve a problem, start a company

Before founding Keen AI, I worked at one of the UK’s large electricity operators for a few years. My job involved building mathematical models of how the network operates and how likely particular assets were to fail based on their condition.

To understand an asset’s condition, you need to inspect it, and this introduced me to the world of asset inspection: lots of engineers, lots of images, lots of manual review. It was slow, expensive, and often frustratingly inefficient. The tools to automate some of it existed – I had even sketched out a system to process videos and train models. But the organisation had other priorities, and nothing came of it.

Eventually I left. Not just because I wanted to start my own company, but because the problem was still there, and it was simple enough, in principle, that I could try solving it myself.

The question that interests me now, looking back, is why engineers often end up in this position: close enough to see the problem clearly, skilled enough to imagine solutions, but unable to act within the structures they work in.

It turns out that proximity to the problem, combined with familiarity with its constraints and failures, is exactly what can make technical founders effective. (Index Ventures’ analysis of 200 top tech companies found that nearly 80% had a founding CTO or technical CEO). Having lived with a problem, understood its nuances, and glimpsed what might fix it, you’re already halfway to a solution.

The problems worth solving are the ones you’ve lived with

History is full of engineers who did exactly this. Sergey Brin and Larry Page built Google because existing search engines returned rubbish results, and they knew a better ranking method was possible. Jensen Huang co-founded NVIDIA because he understood the limitations of graphics processing. Steve Wozniak built Apple because he wanted a computer he could actually afford. I doubt any of them expected to grow billion-dollar companies. They set out to solve problems that bothered them personally, using technical skills they already possessed.

Of course, these industry heavyweights had more than technical expertise in their arsenal. You also need curiosity about the business problem itself; why it exists, what people have tried before, and why those solutions failed. You need to sit at the intersection of understanding the market, the problem, and the technology that could solve it.

That combination isn’t common, but when you have it, building the solution yourself often makes more sense than trying to convince someone else to do it. And that decision has practical implications from day one.

Building the product yourself changes the economics

When you can implement your own ideas, the path from concept to reality compresses dramatically. It reduces the need to wait for budget approval or spend months explaining your vision to investors who don’t share your domain knowledge.

This matters financially. When you can build the product yourself, you can bootstrap. You can iterate based on actual customer feedback rather than investor opinions and ‘total addressable market’. You can stay profitable – or at least capital-efficient – while you figure out what people actually need. The sooner you take venture capital, the more of the business you give away and the more pressure you’re under to scale before you’ve properly validated the solution.

This approach also gives you flexibility. That model training pipeline I initially built wasn’t valuable to consumers. People didn’t want tools to train their own models, but rather, they wanted answers about their assets. Pivoting in this direction took weeks rather than months, because I could build it myself. I wasn’t locked into a development contract or trying to redirect a team that had already committed to a different vision.

Customers are your peer review

In concept, the roadmap is clear: build something useful, price it fairly, tell people it exists. If it solves their problem, they’ll keep using it. If it doesn’t, they won’t. The work you do correlates more directly with the outcomes you get.

This suits the engineering mindset: break problems into components, test hypotheses, iterate based on results. Starting a company extends this methodology to business.

Building the product is only the beginning. At some point, you need people who can ‘sell the sizzle’, people who understand how to create excitement around what you’ve built. Apple makes incredible products but their marketing is also second to none. They built a lifestyle around it. They told stories that mattered to consumers. This is where some engineers struggle. Knowing when to bring in help for that aspect is crucial.

The relationships you’ve built become your foundation

Years working in an industry means you’ve built relationships with people who understand the problems you’re trying to solve.

See Also

Why faster iteration matters in startups – insights from Ruslan Tymofieiev

The organisation I left is now a client. So are Scottish Power, SSE, and several distribution operators including RTE in France. They know I understand their world because I worked in it. They trust my technical judgement because they’ve seen it firsthand. If you leave on good terms, those relationships become the foundation of your new business.

Selling into large, slow-moving organisations is never straightforward: there are countless internal hoops to clear, even when the solution is demonstrably better. But having an insider’s understanding of the landscape, and knowing who might champion a solution, can be the difference between a pilot that stalls and one that scales.

The problems you spotted whilst working inside the system don’t magically disappear when you leave. Starting a company lets you address them more directly, and the network you’ve cultivated over the years becomes one of your strongest advantages.

The only real obstacle is deciding

If you’re an engineer who has identified a problem worth solving, the practical barriers have never been lower. Cloud infrastructure is cheap. Development tools are sophisticated. And if you’re solving a real problem in an industry you understand, finding your first customers is a matter of having conversation rather than running a campaign.

You don’t need an MBA or venture capital on day one. You need a problem that matters enough to spend years on, the technical ability to build a solution yourself, and the willingness to learn how organisations actually operate.

Not everyone is suited to founding a company. But if you’re sitting on a solution to a problem you’ve lived with – if you know it would work because you’ve thought it through from every angle – the question becomes: what’s stopping you?