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.

Small Posts

Missing Data

It’s often observed in the startup world that newcomers take a pacifying approach to judge their ideas. They destroy the realistic market conditions with their slick hockey stick graphs, they just know millions of previously undiscovered customers waiting to be saved, to top it off an imaginary line of investors struggling to make their ends meet.

Well, there is nothing to stop all of that when at the end of the day, ignorance is bliss. But, the problem is when some practice that magical spell over and over again, with a sense that it’s only a matter of time before their dreams become reality because they are dreaming.

Let’s dig it with an example to humor you, Jack wants to celebrate his daughter’s birthday party and is in search of caterers. He googles it and he doesn’t find anything satisfactory. He goes here and there, finally finds one, and gets done with the party. But the itch has already taken its root, it’s only a matter of time before it takes over the host. Entrepreneurship is a dream and Jack has it. His struggle to find caterers for the party already convinced him that the problem is there and it’s real and it’s thriving, he needs to curb it. 
He goes out there, gives it another try, he sees everything he wants to see. He reads everything he wants to hear. Voila, there’s a startup idea and there is no competition either.

The research and expertise he gained during his small voyage are not enough to assess the market or predict the future. For many like Jack, they get one shot to crack at it. Most of the lessons out there capture only 10% of the iceberg. Entrepreneurship is beautiful and tough. But, it’s not impossible. If 70% of startups fail (Jack read that 90% fail), it’s not because its a norm. It’s not a fact that they should fail. 

One of the most important questions you need to ask before arriving to a conclusion: “what’s missing”. You might have collected as much data as you want, but where is the missing data. In Jack’s case, one aspect he should be pursuing is – “Didn’t anyone try this idea before? Are those startups already dead? Why did they die? Where is the missing data?”

Small Posts

Outcome vs Process

Everyone wants their outcome to be “Perfect”.

How does one go about it?

Well, Look at the output and criticize it, iterate it. Miss the root cause and chase a ghost inside your head. Often underestimate problems and overestimate people. If someone has to define a quintessential lifestyle, most of the time, it would be outcome-driven. React to the Outcome, because one doesn’t understand their thought process.

What’s the alternative?

Try to perfect the process. 

First, define a process, apply it to a simple task. 

If the output is not favorable (time & quality), iterate the process. 

Iterate it till 8/10 times the output is favorable, and then scale it – Now take up more tasks. 

You and your team should trust the process and, along the way, make small amends.

Executing something is an art more than a science. Understanding what works and produces favourable outcomes, takes effort. Iterating output usually has no baseline; it can be extreme, leading to constant under-kills, over-kills, finally settling for something mediocre.

Small Posts

The Bad Experience Privilege

John says to Mark: “You had a good life, you have no idea what I went through, so, I don’t expect you to understand. I have had some awful experiences.”

Mark shuts up, End of Story.

Bad happens for a whole lot of reasons. When someone is selfish, the outcome is bad. When someone does nothing instead of something, bad happens. But, Good – It takes a lot of perseverance, consistency, and sacrifice.

We encourage people to share bad experiences more than their good experiences. It’s not enough to know “what not to do”; we also need to know “what to do.”

Do you think someone has had a good life? Ask them, what did their parents do, how were their friends, get curious. Don’t just dismiss them as ineligible to understand your life.

This world needs to hear good stories too, now more than ever.