All In

As a young fledgling startup, you should not be building layers of abstraction over the technology that you are using; on the contrary, you should be going all in.

I have talked to multiple startups doing this. The intention is to future proof the product; this should be the least of your concerns during the early days. In your gestation period, you should be spending your waking hours building features to acquire customers and grow. That is what will make or break your startup, not the abstraction layers you create for the distant future.

blue-blurred-background-chips-1553831

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

If you are using MySQL, then go all in on it. MySQL has a lot of features that are above and beyond the ANSI SQL standards. Do not try to be standard compliant and avoid the esoteric non-standard features; try to leverage them as much as possible. It will take you faster to market at the cost of being locked in on MySQL for the foreseeable future. If your startup survives to see the day when MySQL becomes the bottleneck, you will have enough resources and expertise to make the switch. Same applies to cloud providers. Do not try to be cloud agnostic; utilize the features given by your cloud provider to the maximum.

This might sound orthogonal to some of the advice that you might get on the internet as well as sound engineering practices. A lot of these are written for mature companies with established product and revenues, not for young, early-stage startups. As with everything, it is all about context.

If you think about this, it boils down to a simple decision; whether you live in the present and try to maximize for today and the immediate future or plan out for the distant, uncertain future. A young startup, trying to make its mark on the world, should do the former.

This is a bit counter-intuitive and becomes challenging to do if you have a mindset that is more attuned towards a systematic way of thinking and doing. A lot of things with startups are counter-intuitive and go against the grain. If not, would it not be a cake walk?

Photo by Nancho from Pexels.

Make It Small

“Make it large” is the mantra these days, but when it comes to releasing software, think the opposite, make it small. The secret to a successful release is to break it into numerous small deployments; this serves a dual purpose, minimizes risk as well as gives you enough leeway to fix bugs before it negatively impacts end users.

Never wait for a feature to be complete for deployment. Break it into multiple smaller chunks and keep deploying these to production even though no one will be using it. Smaller deployments always win over one big bang deployment. Longer the code runs in production, more data points you have to analyze and take corrective steps.

animal-art-baby-1289845

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

If you can test with real users without them knowing, there is nothing like it. If you put your mind to it, you will always figure out a way to do this. Taking an example, let us say you are building a chat feature for your application. You can stealthily release it without informing your users and send dummy messages on their behalf. The user does not see any chat related functionalities, but behind the scene, you create dummy messages and send them to one another. Apparently, this is how Facebook tested their chat before launch; this allows you to check your feature realistically in ways it will be ultimately used.

Another trick is to log the action without actually carrying out the intended side effect. Say for example; you are introducing an API rate limiter. As a first step, start logging whenever an API call hits the rate limit threshold. During this phase do not block the calls, the idea is to emulate the result; this lets you test out the feature with real traffic and fix any bugs before it starts negatively affecting your API consumers. Once you are confident of your approach, you can roll out the feature where you block offending callers.

Phased rollouts is a life saver. Release features to a small set of users, keenly observe your application and gradually ramp up to 100%; this minimizes the impact of bugs and lets you catch them early.

Another lifesaver is feature flags. The idea behind a feature flag is simple; you put all your features behind an on-off flag which you can toggle if and when needed. The ability to turn off features during their early lives gives you a lot of flexibility and room to maneuver and improvise.

If you are working on refactoring or replacing an infrastructure component, never do a stop the world cut off. Always run both the systems in parallel and only once you are confident of the new approach, do the switch over. Say, for example, you are moving your data source from MySQL to Mongo, start by writing to both the datastores in parallel. Then change your application to work with Mongo while still keeping the option to fall back to MySQL if needed. Put this behind a flag which you can toggle. Only once you are confident of everything working with Mongo, pull the plug on MySQL.

The common thread that holds all these strategies together is to plan your deployments such that they are small and gradual; if something goes wrong, it is not catastrophic. You increase the scope gradually as you observe and gain confidence.

As they say – Risk is what’s left over when you think you’ve thought of everything. A bit of planning goes a long way in reducing risk as well as giving an excellent experience to your users.

Photo by Magda Ehlers from Pexels

Market Size

When I was working on Kwery, a lot of people used to ask me – Why are you not trying to build a team and raise money? The niche market that Kwery served was not amenable to VC money or building a team. Kwery was an experiment in creating a single person lifestyle business.

Market size is defined as – The number of individuals in a certain market who are potential buyers and/or sellers of a product or service.

carnival-carousel-circus-992763

When building any business, gauging the potential market size is the most critical step. The size of your team and the amount of money you want to raise should correlate with the market size. If the intention is to create a big business, you should be going after a big market. A lot of would-be startup founders are fixated on their idea and raising money that they do not analyze the market size or fool themselves into thinking that the market is vast. Peter Thiel, in his book Zero To One, beautifully explains the significance of market size.

The story that you build around your startup should also reflect the market size that you are after. In 2014, professor Aswath Damodaran estimated the value of Uber at ~6 Billion dollars with the story that Uber is an urban car service company. Bill Gurley, the lead investor in Uber, refuted this saying that Uber is not an urban car service company but a logistics company that is going to be everywhere, not just urban areas and is going to exploit global networking benefits, not local networking benefits. With this story, Bill Gurley was valuing Uber at ~53 Billion, a ~9X increase from Aswath Damodaran’s valuation. With a change in the story, the market size that Uber is after went up. This incident illustrates the importance of framing your startup story for big market size.

Some parting words on market size from Kunal Shah, founder of FreeCharge – Market > Product > Team.

Startups and VC La La Land

With daily morning newspapers dedicating pages and front lines to startups and venture capital(VC) investments, they are no longer the niche they used to be. Whenever a startup investment is in the news, I hear questions along the lines of:

  1. Is the VC crazy to invest so much money in that startup?
  2. Why does that startup need massive amounts of money?

In my opinion, these questions stem from not having an understanding of how the VC business works.

Let us say that there is a contest with prize money of 1 billion dollars. You have to form teams, do some tasks; whoever wins, walks away with the prize money. There are a hundred individuals who are eager to participate but do not have the financial means and resources to recruit people to form teams and get to work. There is a wealthy benefactor who is ready to fund these hundred individuals with 10,000 dollars each. He strikes a deal with each of these hundred people saying, if you win, you give me 50% of the prize money; if you lose, you do not have to repay the 10,000 dollars I gave you. The benefactor is sure that one of them is going to bag the prize, she does not know who. The benefactor has invested 1 million dollars in total(10000 * 100) to ensure a return of half a billion dollars, i.e., 500x returns.

The above is a crude explanation of how the VC industry works. The individuals are the startup founders, and the wealthy benefactor is the VC. The only difference is, in the real world, there is no guaranteed success, i.e., there is no way for the VC to tell with cent percent certainty that someone is going to win for sure; it is all about probabilities, data, reading the trend and gut instincts. To bring a semblance of certainty to returns, VC spreads her bet on a wide array of startups in different domains; at least a handful of them is going to hit the jackpot.

dollar-499481_640.jpg

Why does this startup need so much money and are the VCs crazy to give them that?
Startups that VCs invest in are not chasing organic growth. Organic growth is steady, sustainable growth which compounds to big returns over decades. VCs are chasing exponential returns in a few years; not steady growth. The money that VCs give to startups helps them with this exponential growth.

Why so?
Double-digit returns are achievable by investing in public companies and debt. Why take the risk of investing in startups with absolutely no guarantee of returns when there are better ways to get there? For the chance that VCs are taking, the gains have to be comparable, i.e., exponential returns.

Why do startups need so much money?
To short-circuit the whole organic growth curve and achieve exponential growth so that investors get the returns in a relatively short period. The money is spent on scaling teams, building technology and more importantly in acquiring users through discounts and advertising. In short, the VC capital infusion empowers startups to compress multi-decades of growth to a decade or less.

Why is this startup spending money on discounts when they are not even profitable?
Big spending circles back to the concept of exponential growth and building market dominance for a winner take all effect. The idea is that once the startup dominates the market or has enough users, they will eventually figure out a way to make money, dominate the market and turn profitable. Case in point; Amazon, Google, and Facebook. When VCs invested in these firms, none of them were revenue positive, but look at where they are today. Of course, there is a risk of startups never figuring out how to make money, but VC investment is about calculated risks and spreading the bet.

You might have read of startups of previous successful founders raising astronomical capital without even having a product. VCs are not crazy to do this; they are betting and playing with probabilities and sentiments. The chance of the founder hitting the lottery again is high, hence the clamor to invest. VCs know for sure that not all the startups they invest in are going to be home runs, some are going to go dud and die, and they take this into account while investing. Only a very handful of the startups they invest in turn out to be successes and these handfuls generate the returns. A minority of the successes cover up for the majority of the failures. Returning to our lottery example, out of the hundred, the VC is betting on only one person to win, she knows the rest of them are going to fail, but she gets 500x returns with just one win and 99 failures.

Treat this as a dummies guide to startups and venture capital. I have watered down a lot ignoring VCs and funds who invest for more extended periods. Like any business, the VC industry is varied and diverse.

Startup Hiring

Hiring is an area which is usually given a lot of lip service but neglected in practice. Especially in a startup, where there is a shortage of workforce, hiring at all levels has a profound impact on the future of the organization. When compared to a big organization, the value proposition of a startup to its employees is concerning speed, freedom, and responsibility. But, when it comes to hiring, startups adopt the cookie cutter hiring strategy of big companies.

The regular interview process is biased toward extroverts and people who can speak well. In my opinion and observation, this does not correlate to someone who is good at what she does. I have been observing this since my college days. During campus placements, flamboyant and boisterous students made their way into companies while the quiet ones who were good at studies and who could get along with others were often overlooked. The same thing happens to a lesser extent with the regular interview process too.

Taleb says the following of doers.

For those who do things, it is harder to talk about what they do. Reality doesn’t care about talk. It is full of pauses and hesitations. Clear, non-hesitant speech is the domain of non-doers.

Interviewing is an intimidating experience, and not a lot of people excel in this, especially people who are good at what they do. Also, the kind of questions that are asked during an interview has hardly any resemblance to the day to day work. I have written about this before too. A big step in this direction is to craft an interview process that mimics your organization’s day to day tasks. The best way to do this is to have an assignment based interview process. You can create assignments that resemble tasks that you do on a daily basis and ask candidates to work their way through this. An approach of this sort takes the whole adversarial, and interrogative tone out of interviews and makes it an enjoyable experience.

An important aspect to take care while creating an interview process is to take subjectivity out of interviews. Who conducts the interview should not have a bearing on the outcome of the interview. Another thing to keep in mind is to subject all candidates of a particular level to the same questions. Following the above ensures that you are evaluating every candidate on the same yardstick. It is essential to do this to create a quantitative interview process. This sort of standardization also helps in creating a checklist of what you expect in answers to questions. If you have these covered, anyone can take anyone’s interview and evaluate candidates. Is it not ironic that startups claim to be data-driven, but when it comes to interviews, the whole data-driven approach takes a corner seat.

hiring-3531130_640

An example interview template would be to have an assignment that closely resembles a task related to work. Try to keep the assignment practical yet straightforward. A good candidate should not take more than 3 to 4 hours to complete the assignment. On submission; evaluate the assignment on code quality, conventions, comments, instructions to run, test cases, boundary condition handling, error handling, and documentation. Post that, have a phone screen with a bunch of questions that mostly have a one-word answer. Make this as practical and broad as possible. Try to touch all aspects of work from data structure choices to computational complexity to databases, web servers, etc. The idea here is that if someone is good at what they do, they should be able to answer these without any preparation. Then invite the candidate for face to face round where you ask the candidate to expand on the take-home assignment. Add a bit more complexity and see how the candidate fares. Finish off the entire process with a design round. I have presented a very rough template, tweak it, add more rounds and improvise to fit your needs; every organization is different.

Along with all the above, soft skills are critical. The sad fact is a lot of people do not know how to conduct interviews. I have heard of instances where interviewers were rude and outright obnoxious, not punctual, candidates not kept informed in advance of the interview schedule, candidates not being adequately attended during the face to face rounds, etc. All these play a significant role in shaping the image of the organization in the candidate’s mind.

In the talent market, big companies, as well as startups, are competing for the same piece of the pie. By adopting a hiring process similar to big companies, startups are not going to get an ace up their shoulder. What startups should be focussing on is coming up with a flexible hiring process that is unique to their organization. It is not easy to execute this in a big corporation but very much doable in a startup. Starting from how you engage with a candidate for the first time to the interview to the offer rollout process, everything is ripe for disruption. Differentiate yourself from others. An interview is a big opportunity for you to make a mark on the candidate, seize it right there.

Kwery

When I was at FreeCharge, I did a lot of data engineering. One of the recurring patterns that I saw was:
1. A new product or feature gets launched.
2. The PM wants to schedule a report for her feature.
3. The report should run at a particular frequency.
4. The PM along with others from the C-team should get this report in their inbox.

We had hundreds of reports like this at FreeCharge. We explored tools like Redash, Metabase, etc; but all these tools were geared towards creating beautiful dashboards and visualizations; report generation and report delivery through email were given a step motherly treatment. We hacked together a solution to solve this problem with bash/Python scripts, GIT, Jenkins, etc. The business analysis team wrote the query to generate the report, but they had to depend on the engineering team to schedule the report, create HTML and deliver it over email. One of the goals of the solution was to make the business and product teams self-reliant in report generation. Since the solution was stitched together using different tools that were not meant to solve this problem, it worked but had its chinks; this seeded the thoughts for Kwery in my mind.

logo

Kwery is a tool that solves the above niche problem well. It was also an attempt at building a single person lifestyle business that could supplement my regular income. I followed a lot of lean startup principles while building Kwery; made an MVP, deployed it at an organization that had the above pressing problem and then iterated from there.

With Kwery, initially, I had to take a call as to whether to make it a SAS product or an in-house deployment. I decided against the SAS route as I was not sure how many organizations would be comfortable giving complete access to their data sources to an external fledgling SAS tool. I wanted to make the onboarding process of Kwery as simple as possible. Hence, I shunned all external dependencies for Kwery, opted for an embedded database so that I could package Kwery as a single binary. The only dependency needed to run Kwery is a Java 8 runtime.

I deployed Kwery in a couple of places which use it even today. Kwery has received a lot of love from them, but I never hit the numbers that I had in mind when I started. The opportunity cost was bearing on me. I had to take a call between continuing to work on Kwery or cutting my losses and moving on; I chose the latter.

Like the old saying – Every cloud has a silver lining, I have open sourced Kwery under MIT license. It is very easy to get started with Kwery. Give it a spin, open Github issues if you face any trouble. Pull requests are very much welcome.

We are a startup

Being part of a startup is not an excuse to shoot first and ask questions later. “We are a startup” is the most common phrase people spout when you ask them about their sloppy processes and development practices. Being a startup cannot justify having zero process or letting developers be trigger happy. Being a startup cannot be a reason for condoning sloppy employee behaviour like taking leave without adequate notice or working from home on a short notice.

I am privy to startup lores where everyone writes components in a language of their own choosing. If today’s fad is Node, then the developer uses Node and if tomorrow hacker news has a post touting the next greatest language, the developer switches to that. We are a startup, we do not have a QA and pre production environment for testing, we test code directly in production. We are only a couple of people, hence we do not need version control. Since I am a single guy who manages servers, configuration files are not in version control, my brain is my GIT repository.

Being part of a start up is an opportunity to move fast without being burdened by the bureaucracies/politics of big organizations. Say for example, you find an employee kicking ass, as a manager/lead in a start up you can give that person a raise by having a quick chat with the CEO. In a big organization, you have to make a case for that, present it to a committee, justify why someone should be given an out of turn raise etc, in short, there is a lengthy process and guidelines for these sort of things. It is also an opportunity for you to trust people and call them out when you see something odd without introducing a process around it. If you see someone working from home on a very regular basis and it is hampering work, instead of floating a blanket rule saying work from home is prohibited, there by inconveniencing other employees who use it judiciously, you talk to the person and see what is the problem that person is facing and try to solve it. This is difficult to pull off in a big organization that has thousands of employees but highly doable in a startup.

A startup lets you create an atmosphere based on trust rather than draconian processes. Let us take technology choice for example. Big organizations have lots of rules and regulations on what technology can be used, what cannot be used, how to buy licenses etc. This is made with the central assertion that individuals are not responsible enough, so let us decide by committee. In a startup, you do not need to introduce a process for this, you can trust your employees to make the right technology choices as long as they do not go bonkers with it. If something goes wrong with a technology choice, you can talk to that person and figure out where he went wrong instead of mandating a policy for all employees from then on. Individual responsibility trumps rules any day, it is difficult to implement and follow in a large company but can be easily pulled off in a small organization.

Next time when you use the phrase “We are a startup”, think hard whether you are trying to mask inefficiencies in the guise of being a start up.