Skip to main content

· 4 min read

Cover Image

I recently came across a discussion on an online forum whether funding in startups is like "food" or "oxygen".

This intrigued me.

Why? Let me share more context.

So basically, the question was is fundraising or let's say investor capital like "Oxygen" as in you die if you don't have it? Or was it more like food? You can survive with less food for a good amount of time. Sometimes it may well be healthier for you. And eating more food may lead to myriad issues like obesity, diabetes, etc.

You don't die with less food

If you think about it, you don't die with less quantity of food. You need an optimal amount of food to function at your best. Many would say occasional fasting is good for health.

Especially if you are in an environment like ours, where for many people, availability of food is not a problem.

Compare this to current environment where availability of venture capital is plenty, esp. in today's low interest rate regime. A fair question to ask is - are startups more at risk of "overeating" and developing diseases like obesity, diabetes or more at risk of dying without capital.

It also depends upon what kind of system a startup is. Is it an antifragile/self-regulating system like a human body? Which has systems in place to weather long periods of low food environment, or is it more like a factory which produces more output if you feed in with more input? Does pushing more capital into the startup lead to more output?

Or is capital like oxygen? If you reduce oxygen supply, you start feeling nauseaus and your brain doesn't function at the optimum level. And an increased level of oxygen increases your performance.

Startups - Like Factory or Human Body

To me, startups are complex organisms with many areas of interdepending forces. Capital is just one part of it. The team and team motivation is another big piece on what a startup can achieve with a given amount of capital. Is the org a heavily bloated one or like a fit athlete who doesn't have extra flab on him? What is the market like - is there a natural pull for the startup's product?

Though startups are not really as antifragile as the human body. By defintion, a startup is an experimental business which still needs to prove itself. So, it is fragile by definition. And that's why more than 90% of startups fail.

But even then, capital seems more like food than oxygen. You can survive an extended period of low capital if you have a good team in place and users are loving what you make. Sometimes less capital may be a good thing. It makes you more agile and sharp. Hungrier. Makes your will stronger.

Of course, many founders would say that you need some capital to get started. And I agree.

But as one of our group partners in YC oftentimes told us, raising more capital doesn't mean that you have more runway. Having more capital sometimes leads you to burn it in different ways, try do multiple things simultaneously and distracts you from focusing on the core metrics.

Example from Economics

Cover Image

I recently found a great analogy for this in a presentation by the Norwegian Prime Minister. Norway is an oil-rich country and does well in all economic indicators like per capita GDP.

Such countries face something called The Oil Curse. Oil-rich countries - because they have a good source of income from oil, tend to become overspenders and heavily dependent on oil. Because of this, other areas of the economy suffers, and when oil output reduces they are not ready for the consequences.

This may sound brash but in his own words -

States which earn too much money, tends to spend too much too fast

· 3 min read

I had come across a tweet mentioning something about turpentine and Stripe. I remembered it had resonated with me at that point. But then I lost it.

Today, I went digging for it again. And yay, found it! This is the tweet thread I was looking for.

Written by a Stripe ex-employee, it explains certain key aspects of how Stripe works.

The one which struck me most was: Turpentine!

The context:

Picasso said, “when art critics get together they talk about Form and Structure and Meaning. When artists get together they talk about where you can buy cheap turpentine.” Stripe is obsessed with turpentine.

It's fun to talk about startups in terms of market size, trends, TAM, disruption, etc. Sounds cool, doesn't it?

But as I am getting more experience building one, I am realising that startups are more like knife fights in the back alley, rather than planned invasion. Everyday is a new challenge. You win at things you never dreamt of, and sometimes loose which you thought to be certain.

Who wins is decided by who is the most dogged and has the best tools at hand. And thats why turpentine! At a startup you are always looking for the cheapest turpentine. Anything which gives you an iota of advantage against the rest.

You can't get this by just paddling on the surface. You need to go deep. Really immerse yourself in the problem. What users are doing, where they are finding your product. Then only you find areas which may have been unexplored by others.

At the end of the day, in a fight - no matter who you are. You have to win the fight on that day. There are lot more details in the real world, then a plan on paper would show you.

A map is not a territory.

And thats what gives a startup an edge. Because the team has the will to win. Because they know they will die if they don't put their best fight. Because they refuse to say "ENOUGH".

· 2 min read

Dev communities thrive on meetups. These are places where you come to know about interesting things other people are working on, people working on them and build a professional and social network.

Before COVID hit the world, all my Saturday mornings were infallibly reserved for meetups. And Bangalore, being the tech hub it is, gives you a good buffet of meetups to choose from.

With coming of COVID though, things are a lot different. We are confined to our houses and dev communities are trying to figure out new, interesting ways to interact online. In this context, I was pleasantly, surprised when I came across a DevOps meetup which is organized on Animal Crossing. If you are not aware, Animal Crossingis a popular social simulation video game. Here is what wikipedia has to say about it:

Animal Crossing is a social simulationvideo game series developed and published by Nintendo and created by Katsuya Eguchi. In Animal Crossing, the player character is a human who lives in a village inhabited by various anthropomorphic animals, carrying out various activities such as fishing, bug catching, and fossil hunting.

I am pretty excited to see how this meetup will turnout. If you want to attend, just for the heck of it, here's the link

· 2 min read

I recently stumbled upon this interview from Andrew Ng, arguably one of the guys single handedly responsible for making Machine Learning popular and accessible.

In his interview, there is a beautiful excerpt which I want to highlight. When asked:

Do you have any helpful habits or routines?

He answers: Reading 6 research papers a week seems like a lot, but I think if one can read even one research paper per week, that will germinate lots of new ideas.

Especially for folks who operate in technical domains like I am (my startup is in a domain called observability, this practice would give them new ideas to think about, and possibly innovate on.

While entrepreneurs don't have the luxury to engage in deep research and compare results, they could learn a lot just by grokking through the research papers and at least understand what the basic concepts are. And then let the human mind do its magic 🦄. May be on some opportune day, when you are talking to a customer, hearing his issues and wondering how to solve it, one of these ideas will present itself before you. Boom! 💥

Adrian Colyer, who has been CTO at VMWare and currently is venture partner at Accel, has actually brought this idea to practice. He runs a blog - The Morning Paper where he discusses interesting computer science research paper every week.

There's also a meetup group which discusses research papers periodically and has chapters in many cities of the world. Fortunately they also have a chapter in Bangalore. I will try to attend one their meetups, once in-person meetups are back again, hopefully 🤞

So, which research paper are you picking today?

· 3 min read

Splunk recently released Remote Work Insights - Executive Dashboards. An organization can create interesting dashboards by collecting data from tools like Zoom, Okta and the VPN software. This can enable executives to figure out how well their remote tools are working and where people are spending time.

For example you can create dashboards like

  1. Number of Zoom meetings active in the org at a time, classified by type of meeting (Scheduled meeting, personal meeting room, etc.)
  2. Duration of zoom meetings and a histogram of its duration - This can suggest how long are meetings going, how much time an individual is spending on meetings.
  3. Are meetings getting extended from their scheduled time - Can help executives figure out if time in meetings are being utilised well. Zoom meeting etiquettes training can be introduced to check that.
  4. Single Sign On systems like Okta can tell which apps are people using most. This could help executives detect which SaaS tools are actually being used and which are lying idle. This can help rationalise their SaaS spending.
  5. Integrating with VPNs can also tell number of people logged in via VPN, location from where they are logging in, etc.

Splunk Remote Insights - Dashboard Now, Splunk had to face lots of flak because of this. People got enraged that this is a corporations trying to extract work from their employee, that too when everybody is struggling on their own. But if you look carefully, I am not sure that is the objective. They are not trying to monitor if people are doing their jobs. They are just trying to figure out if people have enough access to do the work, are they facing any difficulties, etc.

It is very similar to how you monitor an app or service. Remote working tools like Zoom, VPNs, etc. are providing a service. How do we figure out if they are working well for the employees? If certain location shows high number of failures in VPN logging, there might be some issue with the VPN provider or network of that area. If people are spending too much time on meetings, then there needs to be some sort of training to be more productive over Zoom.

Since, this is a new experience for many teams, monitoring the tools more closely only helps to figure out issues and solve it.

This is what I call "Tools Observability" and we get more remote friendly, this will get more important.

· 2 min read

Today I attended a SaaS Virtual Happy Hour meetup organized by Nathan Latka of GetLatka. It was a really fun event. The attendees were SaaS founders and investors. Every few minutes you would be paired with a random person in the group and you will chit-chat for 3-4 minutes.

There were ~70-80 people who were live for ~1 hr event. I met 5 people from different corners of the world. Poland, London, New York City & Germany. Two of them had recently been to India. One even has a dev team in India.

It was curious meeting people from different parts of the world whom I would not normally meet. You could say that 3-4 minutes was a very small time to chat on any thing in detail - but it was good to get to know about the other person.

The session was powered by this SaaS product - https://icebreaker.video . Do check it out.

A remote only world is creating new platforms and formats of interaction. It is also making the world flatter. Since, there are no local meetups now, I can now attend any virtual meetup, webinar happening around the world.

For someone who is building a global SaaS product, this is really a blessing 😀

New formats of virtual interaction are emerging with extended lockdowns :)

· 2 min read

I was recently watching a TV series, Billions. It is broadly around the life of a hedge fund manager.

In one of the episodes, Connerty, who plays a US attorney engages a performance coach to improve his performance. He is going through a rough patch professionally and wants to win more rather than lose.

For one of the sessions, he was swamped with work and sends an email to his coach suggesting that he couldn't come for the session today. This infuriates the coach and he comes rushing into his office. What he says to him is rather profound.

Connerty said to him that it was impossible for him to show up as he is swamped in work.

To which the coach replies:

Are. You. Dead? Because then, may be it would have been impossible for you to show up. There is always a story to tell yourself. You say that word impossible to me again one more time, and I will kick it out of your mouth along with your teeth. It is true. Many times we tell ourselves why something is not possible, why we can't do it. Why something is so hard. But the fact is that unless we are dead, we can always do something. anything. Its all about the story we tell ourselves.

So, next time, when you are telling yourself why something can't be done. Think again 🙂

· 2 min read

As we start building a devops tools business, understanding the user is everything for us. Our users are developers and site reliability engineers who make the software in production, work as it should.

The important point to understand about developers is that they are very curious by nature and always trying to learn new things. They operate in a domain which is very dynamic. The tech flavor of the season changes every few years and they need to keep updating their skills to stay relevant.

Also, they smell any marketing or selling from far. You just can't "sell" to developers. Period. They will only use your product, if it makes life easier for them, saves time or peaks their curiosity. And that's where the role of developer advocates comes in.

Developer advocates help other developers learn about the product by writing blogs about it, giving demos in meetups or helping people with their use cases. They are not trying to sell anything. Rather they just want their product to be easily understood by other developers. They also play a huge role in giving user feedback to product teams.

This roles is pretty new in the Indian SaaS ecosystem. I don't think we have as much experience about it, as we have for inside sales or landing page optimization.

I have created a public twitter list, where I am adding some great dev advocates I came across on twitter. Would love suggestions on who else to add here.

Looking forward to learn more about how can we help developers be more product and do their tasks with ease.

· 3 min read

I run a business which builds products for application monitoring. There are many use cases it solves like:

  • Finding how much time are your applications taking
  • Which component of the software is slower compared to the other
  • Which applications are giving high error rates
  • What could be the root cause of the issue
  • Can we generate proactive alerts, before the issue actually happens

Screenshots from SigNoz - Monitoring applications While this seems like a very specific use case for monitoring software, the underlying constructs are more universal and applicable in many other domains. It's just that these techniques are first being applied on software monitoring.

Let us take a more real world use case. Suppose you are in charge of delivery in Swiggy or Uber Eats, wouldn't you like similar monitoring graphs. e.g

  • How much time is each delivery person taking to deliver the orders
  • Which components in the overall delivery chain is taking more time? Are delivery executives taking more time in reaching restaurant, or are restaurants taking more time to cook the food? Which part of the chain is becoming a bottleneck?
  • Which restaurants are telling that ordered dishes are not available?
  • What is the root cause of the issue? How do we know which part of the chain is cause of the problem
  • Can we get proactive alerts if something is about to go wrong in the delivery chain. e.g If less delivery boys have logged in on a day in a zone, if some restaurants are facing any issue.

Aren't the above points as good as monitoring a delivery business? They map one-to-one with what we do currently with applications & cloud infrastructure. It is a thing of wet dreams for a ops manager in food delivery companies. Of course, some parts of the above are already being captured in some analytics dashboards, but it is not to the level of sophistication of software monitoring. Root cause of analysis, proactive alerting, are still a matter of dreams. Business Processes like Delivery should be monitored Monitoring is a much broader concept than we realize today. Rather than just software stacks, we can monitor business metrics, we can monitor utilization of resources in any factory. This is what control systems was when factories were new things. Researchers would devise new & ingenuous way to monitor different machines & components in the factory. Any process within an organization can be monitored in a continuous way.

"So, why it is not already being done?", you ask. Well the key pre-requisite for setting up a good monitoring system is granularity of data. You should have high granularity of data on a continuous basis for each component of the system to get meaningful insights from monitoring.

Unfortunately, most meat space processes don't satisfy that requirement. Monitoring is actively being applied in software and applications, because that is one of the few places where we have good granularity of data.

But, as we are moving to a more data centric world, when each of our activities are tracked or logged somewhere, I am sure that the day is not far when we would be able to monitor processes in meat space also. Monitor different real world processes. Monitor business metrics.

Heck, why didn't the author get an alert when his cheese was moved? 😆  We would have escaped going through a whole book on it.

· 3 min read

I had introduced the concept of effectuation few days back in one of my earlier blogs. For your reference I am attaching the blog link here.

Today I will be discussing about one fo the concepts in effectuation theory - the effectual ask. When we want something from someone, especially for an entrepreneurial venture, generally we take the following 3 approaches:

  1. Visionary - We paint the picture of the goal we want to achieve, tell the other person our vision for the world - and expect him to align with the vision and hence, help us in what we are asking for. The only problem with this approach is that: we hope that the other person agrees with our vision. What if he doesn't? In a way, this approach depends a lot on our prediction of what future the other person will resonate with. And hence, there is a high risk of failure with this approach.
  2. Adaptive - This is a person where we just request a person to help us, hoping that because of his kindness or sympathy - he will agree. This is a very weak approach, since we don't have much control on what the outcome of the ask would be.
  3. Causal - This is the most common approach which people take. They want to ask for a favor from someone, in return for doing something for them. Quid pro quo. This approach is generally a decent approach, if we are able to accurately know what the other person will respond to. Though, more often then not, it is difficult to figure out what the other person is really interested in. What if our offer is not interesting to other person? And many a times, we don't even make the ask - as we don't know what quid pro quo should we offer. This is certainly not an ideal scenario.

The Effectual Ask Effectuation theory asks us to get rid of all these shackles. Rather than trying to figure out what the other person want or just appealing to their sense of kindness, why not just ask them what would it take for them to help us. This is called as the Effectual ask.

This makes the barrier to making an ask very low. You just have to go to the other person, tell them what you want and just ask them what would it take for them? You don't have to figure out the right quid pro quo. You don't have to make a pleading request. You just have to ask. Agreed, that this is not as simple as it sounds - but when you don't have many elements known, I think it is a good strategy. How would you know, what the other person really wants.

What this does, interestingly is that it lower the bar to asking, and in words of Steve Jobs, may times all you have to do is just ask what you want. Very people actually do that.

Here's a video of Steve talking about this: