Today's blog is a mix of a rant and logical points based on my experiences. What's it about? Non-technical founders/leaders. Right off the bat, I realized this blog is going to be highly biased and prejudiced. But let’s dive in and get my thoughts written down.

Motivation Behind This Blog

The inspiration for this blog comes from my experiences and conversations with friends in the IT industry. I’m strictly focusing on the IT domain here. Let’s first understand the background of these non-technical founders/leaders. In IT, as seniority increases, many professionals transition away from coding and into managerial or organizational roles. But in my short experience, I have understood that in IT you need to be up to date with things at least in your domain, otherwise you will be chewed up and thrown out. But the most common tendency of these seniors is not being up to date with these technologies and using the team to do that work. Hence all the information is second-hand information. Many of these senior professionals, after accumulating substantial wealth, quit their jobs and start their own companies. This trend is more prevalent among boomers. Millennials and younger generations often lack the financial resources or choose alternative paths that they find more fulfilling.

Where It All Begins

Boomer founders/leaders, often seasoned salespeople, exude confidence when starting a business. Some do create incredible companies. However, many launch ventures solely because they can bring in clients, overlooking the nuances of building products, setting up operations, understanding business basics, and learning through failure. So their whole strategy is getting very good engineer and getting the product or services off the ground. Don't get me wrong this strategy is not bad it's pretty straightforward, you (engineers) build and I (founder) will bring in the business and clients. If I have money lying around I would use the same strategy. While this approach can yield initial success, it’s heavily reliant on the engineers’ capabilities. Without a strong, technically sound CTO, things quickly fall apart.

Here is a compilation of sentences I have heard from non-technical founders/leaders and CTOs in AI/ML companies:

“Did you create your own LLM or did you use something like ChatGPT?”
“Why can’t we put all microservices on one server?”
“Why can’t we build our own LLMs?”
“Can we increase the servers by just keeping one server?”
“Can we train the model with just 5 images?”
“Why can’t we use one IP for 5 servers?”
“Can we implement RAG without LLMs?”
“Can we press the proxy button to turn on the proxy?”
“Why are we wasting ₹500 for a static IP?”
“Why are we using OCR? Why can’t you just read it and type it?”
“Can we start the server after receiving the request?”
“Why is a payload needed in an API?”
“The user should get the response: ‘Wait, the server is starting.’”
“What is MLFlow?”
“Can we implement MLOps using LLMs?”

Some of these questions might seem like genuine attempts to understand the process, while others are outright ignorant. However, these aren’t just random queries they come from people at the helm of technical teams.

Implications for Technical Teams

The absence of a technically competent leader results in several issues:

Lack of Guidance: Well there is no one to discuss the solutions or provide technical experience. The teams have to figure it out on their own. The founders/leaders unnecessarily get involved in the technicalities when in fact their whole focus should be on sales. Improper timelines because they know how complex a certain solution is.
Unrealistic Timelines: Timelines and projects are thrown by saying “That should be pretty easy”, no god damn it is not easy.
Unrealistic Expectations: When founders/leaders lack an understanding of technical constraints, they set expectations that are impossible to meet, causing frustration among engineers.
Product Crashes: The lack of technical foresight leads to fragile systems that are prone to failure.

If you see any top founders/leaders they have direct involvement in at least the initial product they built on their own, they know the code, they know the process because they built it, and they know the implications of implementing a solution by going the A route and by going the B route. Hence they know exactly when coming up with new use cases on how complex it might be to implement it. They also know how each thing works and they can understand when the engineer is saying a certain solution is unrealistic they can verify it by themselves and the engineers don't have to explain why it's unrealistic.

Impact on Processes and Systems

The absence of robust systems and processes is another consequence. Products are often stitched together like Frankenstein’s monster functional but precarious. This lack of a solid foundation can cause everything to collapse when even minor issues arise.

And if they are good at sales they can bring in a lot of clients, but I have seen those clients are often achieved by giving products for cheap, selling unrealistic dreams and expectations like 99% accuracy. Imagine when there are issues in the product that trust is automatically lost. And we have seen clients leave left and right. Why? because the founders/leaders themselves don't understand the product, they don't know the technicalities, they don't know how things work, and they have never architected solutions. So all the blame falls on the engineers.

What About Sales/Business-Oriented founders/leaders?

Even if someone says Prathamesh they are sales/business people they might know these details. And to that I would say, yes I agree, but as I have mentioned above since they don't understand what they are selling, most of the clients and especially if the client is somewhat technical, are lost, because they can immediately sense the bullshit. The confidence is immediately lost. And you know what sometimes knowing the answer immediately matters a lot, they should not have to say “Let me ask my team, and I will let you know” because you don't know anything and all the time have to ask the team. It creates a perception that this founder doesn't even know what they do. So even if they the code for instance line by line and expecting from anyone is unrealistic, they should at least know the basics.

The Good Side of Non-Technical Founders/Leaders

Everything is not bad being a non-technical founder, these people have an insane skill of bullshitting their way to sell the product. And that is art in itself. Hence they are very good at converting the leads to clients. However, their success rate could be much higher if they had a strong technical counterpart to balance their skill set. A solid top management team is crucial for long-term stability.

The Shiny Object Syndrome

You will also find these founders/leaders with Shiny Object Syndrome. And specifically, now it's almost like they get an orgasm with mentioning AI. They want to introduce it everywhere and I mean everywhere, is it needed? No, has the client asked for it? No, does it even go there? No. But all the responsibility is on the engineers to implement these new solutions and figuring out themselves. This also impacts the priority, because each week something new comes up and priorities change because now we have to implement that, but what about the thing we were doing currently, what about the efforts we were putting currently, answer? “I think we can do both. That should be pretty straightforward” But how should we implement it “You guys are visionaries, you come up with it, I don't know”.

Conclusion

As we can see it's a complete disaster. What is the result? Employees attrition. People leave the organization because of the frustration. The founders/leaders don't change their attitude and the company becomes a house of cards, it can collapse at any time, why? Because we are just one mistake away from it. One might say, but Prathamesh you are young you do not know the full picture, but the points mentioned here are common sense and don't need business knowledge or experience.

Prathamesh Kulkarni

From Frankenstein Products to Employee Attrition: The Downsides of Non-Technical Leadership