Entrepreneur Reality

Building an own company is a dream for many. The advent of the Internet made it more possible than ever. Develop a website, mobile application, or something which can work on the Internet and make it live. Building applications might seem a task that has to deal with common sense, and it is true too. But, at the same time, there is no measure of common sense and also not too safe to assume that everyone has that enough common sense to go about it.

An idea doesn’t translate as it is from business terms to code. Of course, that shouldn’t be shocking. Even when you translate from English to French or any other language, it’s an approximation and an interpretation. Many aspects can be lost in translation or gained in translation, if lucky.

Same is with software development, once translated from business terms into code, the pieces in the software are confined to work using that particular interpretation, which developer calls as logic. No matter what you think in your head, the reality is out there, code is real – as real as brick and mortar. As developers are building the application, the restrictions keep growing; it’s not as fluid and flexible as it is in your mind, and it has boundaries and contexts.

Developers often find it’s easier and faster to develop applications from ground zero than modifying an existing feature. To change or add a new feature, it means one should have enough knowledge of ground reality – in this case, existing code. And this is where Entrepreneur Amnesia kicks in.

“Startups fail” – we were taught to live in that comfort zone. Not just a few startups, but supposedly 70-90% fail, that number became so huge because of the mindset that anyone everyone can build a startup, an internet company, all you need a web or a mobile app. It’s as good as saying that anyone who can envision a table, chair, menu, and has an opinion on the taste of food, should hire a cook and open up a restaurant.

So, the founder/entrepreneur brings their idea forward, figures out a way to hire a team or an external agency. The business terms of their concept need more language to communicate with developers, so they envision the product, features, UX, and UI. And they are eligible to make that decision because apparently, they can be in shoes of their user. Development starts, coding begins. As time passes, in a few weeks, the entrepreneur can finally see something – a UI, a button, a form, and some functionality.

What was happening during these weeks? – The developer tells you that they are working on setup and backend. The founder says “OK” because their knowledge ends there, and it’s not their expertise to care about that aspect where lies the foundation of their whole idea – because code is real.

More time passes, more features are developed and rolled out. Depending on the development team, the application came out great, or things already went south. It’s important to remember; the founder has been explaining his vision and development team has been interpreting and translating. So, it is someone else’s interpretation. And after a good time, founders get more ideas; different ideas, enhancements, improvements – development team might have already clued in that some of those ideas are not possible, some might take time. As we are humans and we also know how to be in shoes of a sheep too, the founder nods their head that maybe it is not possible.

Pause a bit. What the development team is saying is that – The current reality is not supporting the future vision. It’s so inflexible and disheartening for a founder to know that. It’s not just the code that is not helping; it’s the cost and time which would take to make that change. It’s so big that the founder would probably get pissed off. How can a small change cost at the same magnitude of developing multiple features? The problem – Imagine constructing a house; the cost it takes to renovate might be most of the time equal to changing, adding few rooms. But, the founder forgot the reality – code is real. What’s communicated is already translated, and the founder only remembers what he visioned, not what is in the system.

Tech companies have thousands and hundreds of software employees to maintain their applications because as the size of the code grows, the flexibility decreases, the scalability is lost – so to keep up the pace, more and more people need to work in parallel. And also, it’s not dependent on one person; they have a chain of hierarchy to approve features, high level – low-level designs to for-see if they are missing anything during translation.

It’s very dangerous this – the entrepreneur amnesia – where the founder forgets the reality which they had control over at one point of time and gets lost in that vision, only to finally to blame some technology team that they failed at their job. Products, Applications, Startups are not built out of books. Every startup is a new book, and keeping a tab on the exact reality is the most important thing.

Well, you ask, what’s the solution?

  • Building a great product is a by-product of building a great team. Have a vision for building a team – even if it includes someone external.
  • Be a team player – Build with your team strengths. Make sure it’s not only your vision that is building – there might be a more straightforward solution to achieve more or less the same.
  • Be aware of the amnesia. Pay more attention to understanding the building blocks of technology, at least till someone else is playing that role.

It’s easier to say for a founder that they are the product owner, project manager, decision-maker, and everything. Do remember that they are not just titles. They are roles. Roles have responsibilities unless you can fulfill all those responsibilities; you are creating a big hole in your company from Day 1.

A startup aims to solve a problem, and the problem is real. If the problem is real, there should be no reason for startups to fail to figure out and execute a solution.

The reality of an entrepreneur and their business activities should reflect what’s already developed. More than the market conditions, it’s the distance from reality too. Software is costly, and it’s not as flexible as one perceives it to be. Keeping it flexible is also a cost. Encourage good coding practices, give your technology team to refactor the code.


Abstractions are not just to separate concerns

Abstractions are much needed and essential for us in this world to function correctly. Though we don’t accurately understand how petrol/diesel comes from deep underground, you go an abstracted concept called Fuel Station. You don’t care how Banks works internally; you interact with the interface provided by Banks in the form of their websites or their buildings where people are sitting for you. They separate concerns so that one can do their job neatly and much.

In Software, abstracting away things is the norm. As you grow into a better developer or an architect, your entire focus goes into organizing your solution into folders, namespaces, packages, microservices, etc.. Even the companies divide themselves into teams and abstract them based on roles they need to perform. When you see a problem in UI, you directly contact your Lead UI person because it’s their responsibility. You either shower them with praises or rain fire on them, depending on the situation.

When you apply abstraction to Human Resources, the rules of coding don’t apply. It’s a different game. We often listen to people feeling pressure of working in a team, under a person. The problem is not just that person. It’s the chain of management above that person who lives in a simple assumption: “Well, we have abstracted some concerns into a team; it’s their headache how they do it.” As the technology evolved, the need for one person to take care of everything – referred to frequently as “full stack” also became a norm – and mostly, this is also a form of abstraction, to the least possible level – “a single human.”

Abstractions are not only to separate concerns, but they are also to identify problems, and they are the foundation to refactor.

It’s not the problem with the idea, it’s with the way we abuse abstractions. Abstractions are not only to separate concerns. They are to identify issues with ease and refactor your notions. The purpose of abstraction also should be to understand the problems teams have within them, groom them, nurture them – not to throw work at them and expecting results at insane speed and quality – that’s not the job of abstraction. It’s a way to organize. 

Just because a concept called “Washing Machine” was abstracted, you don’t throw insane loads at it. As there is no way to measure Human potential, management often doesn’t know. As it’s hectic to track individual potential (though that’s what they are supposed to do), they abstract all team members into predictable abstractions – everyone should work for 8 hours and finish this much work. In companies with a lot of teams, there is no foreseeable way for problems to reach management, particularly technical problems. Unfortunately, abstractions though supposed to make teams lighter and move faster, become counterproductive and make things slower.

Some questions to keep asking your team: Are they struggling with some technology choice?

  • Are they able to train peers properly – junior or senior
  • What is killing productivity?
  • If team members would change something, what would it be?

As a final note, when you are hiring external companies, freelancers also – the problem of management doesn’t go away. Understanding their issues and limitations is vital to create an environment of honest communication and address gaps.