Why do most Software Composition Analysis (SCA) tools (for lack of a better word) suck? Here's what I've found:

• Shift-left Kool-Aid: It's true, you want to catch security vulnerabilities early in the lifecycle. But the goal is automation, not just redistribution of tasks. Your SCA tool enables developers to detect new vulnerabilities, and even suggests what version to upgrade to — but doesn't give any information on how to make that decision. Ask any developer and they'll tell you upgrades aren't that easy.
• Lack of context: Raw vulnerability data isn't enough. The "realistic" impact of a CVE goes beyond just the CVSS and EPSS scores — it depends on the context of the application, the environment, and the data it processes. Most SCA tools don't provide this context, and leave it to the security team to figure out. This is how you end up with hundreds of vulnerabilities in your backlog, most of which are irrelevant.
• No baseline analysis: Most SCA tools don't provide a baseline analysis of your application's dependencies. This means you can't tell if a new vulnerability is introduced in a pull request, or if it was always there. Breaking CIs on every commit is how you make developers hate security.
• One-size-fits-all remediation: The "upgrade to the latest version" advice is a lazy way to remediate vulnerabilities. It's not always possible, and sometimes it's not even the best solution. In my research, almost no SCA tools show you alternative remediation strategies, or even the impact of each strategy.

At DeepSource, we think this is a valuable problem to solve. Modern software is built on a complex web of dependencies, and the security of your application is only as strong as the weakest link in this chain. We're working on a new kind of SCA tool that challenges the status quo. I'm excited to share more about this in the coming weeks.

As founders, even an incremental change in your productivity can mean a step change in your startup's overall productivity. Founders are often the bottlenecks, after all. There's so much advice around "unblocking your team", but I think just getting more things done might be a better way to improve the rest of the team's productivity.

So I've started worked in serial since the last few weeks. Every Monday, I assign a broad focus area for each day in the week, depending on the most impactful work I can do for the company at that time. I try not to complicate things by planning too much — a broad focus every day is enough. I create all-day events for each focus area without blocking the calendar, so I can still have other meetings during the day. Every day, apart from the meetings, I'm only working on the focus area.

It's been only three weeks since I've started doing this, and it has already been the most productive weeks for me this year. I've been pleasantly surprised how much I was able to get done across several completely different areas of work.

Maybe this Elon guy is onto something.

I've been working on startups for almost 10 years now. During this time, I've cold-emailed a lot of different people for different objectives — angel investors, potential customers, Fortune 500 executives, founders, VCs, potential hires, you name it. And then there are follow-ups, sometimes tens of them.

I learnt very early on that I needed to get better at cold emails because, well, I sucked. Over time, though, I've gotten better. These are some of my principles.

2-3-1?

The goal of a cold email is simple: get a response. Any kind of response. It might sound obvious when spelled out like this. But usually we tend to expect more, much more.

Maybe they'll book a meeting right away? Let me add my calendar link. Oh, they'd definitely want to look at my investment deck. I'll attach the 12-pager. Oh, and the 6-minute product demo? Yeah, how can I not?!

It didn't work for me. So started learning from the cold emails I was receiving, trying to find a pattern. I arrived at this format which works well for me.

Salutation and signature aside, the format lays out a simple formula for the body: 2 sentences for the hook, 3 sentences for establishing the key facts, and one question at the end.

Every Sentence Counts

The reason the 2-3-1? formula works for me is because it forces me to cut out the fat from my writing. If I can write only 2 sentences in the hook, it better be a freakin' awesome hook. These restrictions make me think harder before I frame my sentences. This has a nice side-effect of sharpening my propositions.

I try to aim for a reading time of around 30 seconds for the entire email, which is a reasonable time you can expect a very busy person to spend on a cold email. Here's a handy tool to calculate that: Read-o-Meter. You only need to do this the first few times, and your mental read-o-meter learns pretty fast.

If you're looking to get better at writing, I'd start with Paul Graham's essays on this topic: Write Simply, Briefly, and Usefully.

What You Say >> How You Say It

Over lunch the other day, I asked a founder friend how many cold emails they receive (around 15 every day), and how many emails do they actually respond to (~1-2 every year maybe).

I'm sure you'd hear similar, or worse, numbers for any of your friends. The simple reason behind this is most cold emails you get are written with poor context, with people somehow trying to sell you things you don't even need. Which is also why most advice on cold emails doesn't work, because they focus more on how to write than what to write.

Your cold emails aren't going to work if you're not adding value to the receiver in some way. The only exception to this is when the receiver is paying it forward, so they're probably going to to help your regardless. I've found that the previous two principles work only when I'm reaching out to the person with something they will find relevant.

You'll end up sending fewer emails if you stick to this principle, but you'll most definitely have a better conversion rate.

Still, when meeting founders we haven't met before, or when joining a new group, we often paint a rosy picture of what we're going through. This is not deliberate or disingenuous — rather, it's second nature as a result of being in front of investors, customers, your team, or potential hires all the time. As a founder, you're always selling.

Exposing our vulnerabilities is difficult, especially when meeting new people who you assume are all doing better than you. This greatly diminishes the value you can get out of being in the group — since you're not showing others the reality, it's impossible to ask for help. I picked up this trick from a friend of mine to overcome this. When joining a new group of people (and I'm using founder groups as an example because I've been a founder for the last 9 years), start by sharing what's going wrong. Make it part of your introduction.

It feels good to lead with "we're doing $Xm in ARR and grew Y% last quarter", but "we're doing $Xm in ARR and grew Y% last quarter, but we've had a lot of churn last month and I'm still not confident we have PMF" is going to help you get better advice — and empathy.

If you're working in a team, your work will most definitely go through at least one round of review by your peers or a supervisor. Assuming you care about the quality of your work, you'd better the first set of critique as early as possible so you have time to iterate and make things better. This also gives you time to align your work with the person who's vision you're following.

There's another argument that applies to everyone who's creating something, regardless of whether you're working in a team or not. When you pick up something new, the initial few days is when your excitement about the vision of how the final product should look like is the highest. You're constantly thinking of ways to do things better, putting in the work to get something up, even if it's nothing substantial.

Excitement, however, is a depleting resource.

If you let your ideas stew without any execution or without putting out the first draft in front of the others, your excitement slowly starts to decrease — up to the point where procrastination has completely replaced any will to ship whatsoever.

Things go downhill from there. Only one of these two things can happen now:

1. You get excited about something else and the first task you picked up stays on the back-burner. This happens to most of people's side projects.
2. For projects that cannot be put on the back-burner forever but need to be shipped on some deadline, you still need to work. But now that your excitement is gone, you're no longer striving to do it the best. You're just trying to somehow get it done. This scenario is even worse because that's how you end up shipping sub-standard work that you're not proud of.

For most people, scenario #1 is generally acceptable. But no self-respecting creator wants to fall in #2.

If you work at an early-stage startup, you would be accountable for delivering things end-to-end more often than not. Sometimes the task at hand is something you know how to do well. Most of the time, you're treading unfamiliar territory. To be successful as a contributor, not only does your output have to be of excellent quality, but also it should have finality.

Vision and execution

All creative work involves two broad phases: visualizing what has to be done (or vision) and then actually doing it to bring it to life (or execution).

Take The Thinker by the famed French sculptor Auguste Rodin for example. Imagine how The Thinker would have come into existence. Rodin visualized the sculpture in his head and then actually brought the Bronze masterpiece to life. If you're working solo like Rodin, you absolutely and in all entirety own the vision and the execution.

If you're working in a team, accountability is often divided. Sometimes one person has the vision and also does part of the execution. Most of the time, the people who have the vision and those working on the execution are different.

Ask yourself, "Did I leave any spots?"

Finality means the executed version is as close to the vision as possible.

To excel as someone doing the execution, you should strive to achieve the vision as ultimately as possible. This also means that if you're the one who has the vision, you explain your vision as clearly as possible. A team that consistently produces excellent output is also where the people who have the vision and those who execute that vision work well together.

As someone who's executing the vision:

• Make sure you understand that vision as thoroughly as possible. Then, execute as thoroughly as possible.
• Pay attention to details so you don't leave any spots. Learn how to care about the minutiae. Break down your tasks. Look at things in smaller chunks so you don't miss the essentials.
• Be sincere. Before you push the work off of your table for review, ask yourself if you've done enough. If the answer is no, in all honesty, you need to put in the work. Don't stop until you've realized the vision.

To create great things, great vision and excellent execution are equally important. If you find yourself in either circle, seek finality above all.

So I tried to answer what makes the products I absolutely love different from the others that I still use but don’t care about a lot. I realized that all the products in the first category invariably have some bit of magic, while the others, remarkably, didn’t have any.

This post will explore what makes a product magical and replicate it in a product you are building yourself.

Anatomy of a magic trick

To understand what characterizes a magical product, let’s first define what magic is. This will help us put a framework on how we can think about our product.

Let’s take the example of the Hat-trick. It’s one of the most simple, classical magic tricks where the magician produces an object (traditionally a rabbit or a bouquet) out of an apparently empty top hat. What is the essence of this trick that makes it magical?

When you’re sitting in the crowd, and the magician performs this trick in front of you. The magician pulls a rabbit out of their hat. Assuming that you already don’t know how this trick works, since, well, it’s not really magic, you are amazed. "Whoa! How did that happen?!"

The essence of this magic trick is the following two parts:

• Preconception: When you came into the theater, your existing knowledge that you came in with didn’t allow for a rabbit to be pulled out of an arbitrary hat. That’s not how Physics works, after all. Reality doesn’t allow for objects to appear out of thin air. You’ve learned this from living your life in the real world so far.
• Stupefaction: At the beginning of the magic trick, you probably didn’t expect this to happen, assuming this is the first time you’re watching the trick. The magician didn’t announce that they are going to pull a rabbit out of the hat. They just did it.

If the above two properties — preconception and stupefaction, don’t hold valid for the trick, it won’t be a magic trick anymore.

Magical products you’ve already seen

A computer mouse! Yes, people like you and me who grew up with the mouse as the primary way of interacting with a computer probably never thought of the mouse as magical. But Andy Warhol did. The first time that the famous pop art icon used the mouse in the paint program on one of the first Macs, he exclaimed, "I drew a circle!". Magical, don’t you think? Preconception, as in Andy didn’t imagine something like that was possible in the physical world — and stupefaction when he could use something like that to create an actual circle on the screen.

I’ll take another example that’s easy to relate to. Superhuman, the popular email client. The first time I used the Send later feature, it was magical.

Preconception: I didn’t imagine that the software would interpret saying "tomorrow 10am in san francisco" correctly.

Stupefaction: It actually worked!

A recipe for magic

Magical product experiences, as opposed to purely aesthetic design mumbo-jumbo, don’t just delight users. They also simplify the product for them. This is worthy enough to chase because users prefer simple products that just work rather than complex products.

So, how do we build magical product experiences anyway?

Start at the destination

When thinking about a new product feature, set aside technological constraints for a moment and first think about what the ideal end state looks like for the user. If you leave aside any technological constraints and solely focus on this, you’d end up with what your magic trick achieves.

The rabbit should appear from the hat.

In Superhuman’s example, the Send later feature's final destination is that the software should correctly guess the time in the correct timezone that the email should be sent at.

If you’re able to establish the destination well, you will fulfill stupefaction — the second part of our magic trick. The user will probably not expect this outcome from the product, even if they have a fair idea of the end goal.

Map the shortest path to the destination

Once the destination has been clearly defined, think about guiding the user to that destination via a path of least cognitive effort.

If a rabbit has to appear from the hat, the easiest way of making that happen is to, well, pull the rabbit out of the hat. The simplest way for the user to tell the software what time the email should be scheduled is to write it in plain English. What makes the Send later experience magical is that the user can write in half-complete phrases, and still, the software guesses the precise time and the timezone.

Conversely, think about a dropdown menu next to the text box to choose the timezone. While the destination is the same, the experience isn’t magical at all. The path to the destination is too complex.

Simplicity is magical.

Put in the work

Beware, for we’re talking about simplicity for the user — and not for implementation, which would invariably be more complex than usual if you’re optimizing for simplicity for the user.

A magical product experience simplifies things for the user but makes the technological implementation more complex by multiple orders of magnitude. A text box and dropdown would take far less time to implement than a full-blown natural-language processing engine that parses “tomorrow at 10am in san fran” to the correct time in the correct timezone based on the city’s name. (obligatory XKCD)

Further reading

1. Anticipatory Design: How to Create Magical User Experiences
2. The Next Big Thing In Design? Less Choice
3. What magic can teach you about interaction design

I love it when potential hires ask me such thoughtful questions. It gives me a peek into how they evaluate a new job opportunity, especially with an early-stage startup. It also allows me to tell them more about my own thinking and explain the company’s mission slightly better. Questions about hiring are my favorite because it involves a certain kind of meta-thinking when you’re having this conversation in the hiring process.

Post-mortem of a bad hire

My co-founder and I have made our fair share of hiring mistakes in the past six years of our startup life, including, for the most part, the first startup which I had started right after college. Every time we’ve had to let someone go, we’ve sat down and introspected why we had to come to that stage. I am a strong believer in the notion that there are no bad employees, only bad hiring managers. So if I’ve had to let someone go, it was because of my fault and mine alone. Obviously, there are exceptions to this rule, but you know what I mean.

We concluded that most of the bad hires we’d made fell into one of these buckets.

1. They were hired out of desperation. We had bitten off more than what we could chew and got overwhelmed with deadlines, which led us to conclude that we need more people, and we need them soon. So we said yes to hiring without too much diligence or everyone saying a strong yes for them.
2. They were hired for something that we hadn’t figured out how to do ourselves first. There was a pattern for this one and something that we repeatedly did. As tech founders, marketing and sales didn’t come naturally to us. It was easy to think that this one person can come in and do things magically. Well, guess what? It rarely works.
3. Hired without having a repeatable process in place. This is a corollary to the previous point. But even if you’ve figured out how to do something, it isn’t easy for a new hire to perform well if you haven’t systemized the process.

Our hiring principles

If you think hiring is difficult, try asking someone to leave.

We realized that the best way to optimize for good hires, especially in the early stages of a startup, is to hire deliberately. Of course, there would be situations when you can’t afford this — but beware that it comes with a trade-off of the possibilities of making a bad hire being greater.

We’ve come to put some principles in place that help us we’re not making the same mistakes again:

1. Hire only after writing the exact job description and getting it reviewed internally.
2. Don’t hire for a position if you expect them to deliver or take accountability for critical projects or KPIs within 3 months from joining.
3. All of the founders should be on the hiring panel. So should at least 2 team members they are supposed to work with, in addition to the person they’d be reporting directly to.
4. Only hire someone when there’s a strong yes from everyone on the hiring panel. No exceptions.
5. Trust your gut.

These are some very general principles that would apply to all early-stage startups — with some exceptions, of course. As more people get involved in your team’s hiring process, it is worth reiterating to them these principles. After all, explicit is better than implicit. Hiring is too important to be left to individual preferences.

Until you take an in-depth look — which is when you see how this change was a long time coming and shouldn’t have surprised a keen observer, I’ve been watching developer tools closely for quite some time. Pricing changes of platforms like GitHub are of particular interest to me since the company I run is a complementing service used by developers.

To understand how the pricing change was a long time coming, and how it probably doesn’t really impact GitHub’s revenue in the long run, let’s take a few steps back and see how we arrived here.

GitHub’s approach to product and pricing

GitHub’s business model has always been charging users and teams for private repositories. The product is entirely free to use for open-source code, which brings in massive activity from developers. Once you’re hooked to using GitHub, there’s a high chance that you’ll pay for storing your private code too. Neat.

Historically, GitHub has never had feature gating of any kind — the free and paid plans get almost identical capabilities. Therefore, the value addition to customers has always been the ability to use GitHub for private code. Since the launch in 2008, the pricing was based on the number of private repositories and had multiple tiers for different brackets of repositories allowed.

That changed in 2016 with the announcement of unlimited repositories — switching the pricing model to the number of users. The value, still, was using GitHub for storing private code.

This product strategy (of having no feature gates) and pricing model (free for open-source, paid for private code) proved to be very useful in acquiring users fast — who could quickly get to see the value on open-source code and then swipe a card to use private repositories. The simplicity of the product and a singular focus on no-frills source code hosting and better collaboration tools further accelerated the growth.

Comparison with Bitbucket and GitLab

Quite the opposite to GitHub, Bitbucket and GitLab have always had feature gates headlining their pricing strategy. Both these platforms have had, unlike GitHub, a free tier for private code. But their pricing has been, in general, complex. For instance, Bitbucket still offers enforced merged checks in their most expensive plan; and GitLab offers the merge approvals only in the paid tier, and multi-group user boards in a higher paid tier. GitHub had been the first mover in providing most of these features and kept all these features available to all tiers.

A shift in the user’s perception of value

GitLab’s meteoric success in the past couple of years brought into light a new trend, however. GitLab went full ballistics with feature gating, with as many as four tiers of pricing — and tried to attack the entire DevOps category with different product features aimed at various verticals and under different plans. This strategy was new, utterly opposite as compared to what the largest incumbent GitHub was doing, and would have seemed foolish to any observer at that time. And why not? After all, GitHub has been the reigning leader of the category, kept its product simple and focussed, and built an extensive API to play well with complementing services like CIs, issue tracking, code verification, automated deployments, monitoring, release management, etc. GitLab just attempted to do everything, all at once.

But it turns out, GitLab has been a visionary. Their experiments with embracing feature gating uncovered something very unconventional: hosting private repositories alone is no longer the core value for the customer.

The world has changed a lot since GitHub’s founding in 2008, and organizations are now embracing workflow automation more and more. The success of CI / CD platforms like Circle CI and Travis CI, the more recent roaring success of dependency vulnerability detection platforms like Snyk, and growing adoption of automated code quality and verification tools clearly meant that engineering teams from companies of all sizes are looking at automating everything in the software development that can be automated — and they’re looking for 3rd party services to do that, as compared to building things internally.

Enter, $MSFT

It’s mid-2018, and Microsoft announced that it’d acquire GitHub for a whopping $7.5B in stock. Things had not been exactly rosy at GitHub before that, and the company had struggled to make money despite having built the most influential platform for developers and engineering teams in the world. This story is something every investor dabbling in developer tools loves to quote (in addition to Docker), but that’s a tale for another day.

With a new leadership under Nat Friedman, GitHub quickly figured out what it had been missing. GitLab had just crossed the $100M ARR mark, and Atlassian’s ~1B ARR saw some decent growth coming from Bitbucket. GitHub had the largest and fastest-growing, user-base of developers from across the world — what would it take to convert that into massive revenue growth?

The Big Switch

It’s almost like GitHub had this epiphany after the acquisition. It realized the shift in the value chain of software development tooling. It realized that it already had the most massive distribution platform for developers — with 40M+ developers and 2.9M+ organizations — and they no longer needed just private repositories and collaboration tools.

So GitHub switched the gears to build everything else, just like GitLab — almost. Soon after the acquisition, it went on an acquisition spree, gobbling up Pull Panda, Semmle, Dependabot, and the latest, npm. It also added CI / CD capabilities after refreshing GitHub actions — which, as you’ll see later, will go on to become a significant part of its strategy.

In a matter of fewer than two years, GitHub switched from being the best code hosting and collaboration platform for developers to trying to be the single platform where software development happens. I’m tempted to use the term OS for Software Development here, but I think the analogy has already been overused.

GitHub Free: embracing the inevitable

Given the detour we took so far, making it free for all teams and developers seems the natural progression for GitHub. It realized that much more value could be created by selling value-add services on top of source-code hosting, backed by a massive distribution base it has already built. If you look at the latest pricing, this becomes as plain as day.

GitHub has realized what features add the most commercial value for its customers and also has been pushing for more adoption of GitHub actions — for CI / CD and ad-hoc pipeline integrations.

Embracing feature gating, it moved all essential features to the free tier except for those that teams can’t possibly live without now — like required reviewers (which is something that GitLab did from the very beginning).

Another evidence is decreasing the free action minutes from 10,000 to 3,000 in the team plan. This signifies that GitHub has seen growth in people adopting GitHub Actions as their primary CI / CD if they’re on GitHub already (bad news for Circle CI) — so the change in pricing based on minutes makes total sense.

Soon, we’ll see GitHub adding or moving more additional features only in the paid plan. This is a double whammy — GitHub gets to say it’s free for anyone doing software development in the world, but it’s making sure people who can pay, would pay.

So yes, GitHub Free has had GitHub lose a lot of revenue in the short-term, but my educated guess is, it’s not a lot. And all that loss would be offset by new teams jumping on board from other platforms like GitLab and Bitbucket and eventually converting to paid in the mid-term future anyway. In the long-term, GitHub Free makes GitHub more revenue.

The math for GitHub Free

Let’s talk about a team of 10 developers who are on the Team plan. The team also uses GitHub Actions for CI / CD on all their projects, stores built packages using GitHub Packages and also generates a lot of artifacts through GitHub Action runs. It is common for a team of this size and decent activity to use at least 5,000–7,000 build minutes every month.

What were they paying before

$25/mo (for the first 5 users) + $9/user/mo ⨉⁢ 5 users = $70/mo 
$0 * 7,000 minutes (free build minutes) = $0
Total: $70/mo

What they’d be paying after GitHub Free⁢

$4/user/mo ⨉ 10 users = $40/mo
$0 * 3,000 mins (free build minutes) + $0.008/min * 4,000 mins = $32/mo
Total: $72/mo

For small teams that are deeply integrated with GitHub, which is something GitHub is betting on anyway, they’d be paying more now. As the team grows in size, yes, the total cost would see some decrease as compared to previously — but there are high chances that more features could go behind more pricing tier, just like GitLab.

What GitHub Free means for other developer tools

I’ll be honest here — this is not particularly good news for complementing services that engineering teams use in their workflow. Since GitHub has become so ubiquitous amongst tools bought by engineering teams, it has also become a reference point when it comes to pricing. When purchasing a tool that works on top of GitHub (like a CI tool, or code review automation tools), it is prevalent for customers to compare the pricing with GitHub — “Why should I pay $30/user/mo for this tool when I’m just paying $9/user/mo for GitHub?”. Well, this pricing change is just going to make it worse for everyone. The pricing change by GitHub is the last nail in commoditizing source-code hosting in the industry, and like other players, it has now stepped into the value addition game with features on top of the core workflows.

Embrace the Free tier

Here’s the silver lining. The fact that GitHub is betting on primarily selling value-added services proves business value validation for every developer tooling company out there. If the biggest player in the market is moving towards them, they’re already sitting on a gold mine. Which makes sense — since we’ve seen increasing adoption of tools that automate parts of software development and save developer time

From a pricing perspective, it makes sense for developer tools who’ve been pricing per user to embrace the free tier, and give at least some user seats for free — if not all. They’ll also need to identify which of their features add the most value, and ruthlessly put everything in the free plan. This will not only help improve adoption but also help focus on the features that add the most commercial value.

GitHub just validated the larger trend in the developer tooling market, which GitLab and others had already foreseen. Others will need to catch up now for better or for worse quickly.

Seek what they sought.

2019 has been a life-defining year for me. It certainly has been way better than how 2018 went by, but you won’t know that because I didn’t write a 2018: In Review. I was too busy fixing my life which had been a shambles. But it’s okay. Better is a relative term anyway.

Jumping off the cliff, yet again.

I know, I know — it has become quite cliché now. I’m guilty of using this metaphor way too much, but this is precisely what has punctuated 2019 for me. At the end of 2018, I moved on from the company that I had founded right after college to start a new one. I practically moved on from over 4 years of hard work for zilch, and started from square one again. This time, a little wiser.

Jai and I put all that we had into it, borrowed what we needed to fill the gap, and flew to San Francisco in April after we had launched DeepSource in March 2019. The next three months would determine the future of the company, and we knew that.

We hit the ground, and we did it hard. Starting with practically zero connections in San Francisco and the Valley, I reached out to anyone and everyone who could help us. Many didn’t return calls and messages, but a few did. I’m immensely grateful to everyone who extended a helping hand, lent an ear and gave advice — you know who you are.

Soon, we onboarded Uber. Bingo. Turns out, people did want what we were building and it was not just in our heads.

We also convinced some trusted advisors to get associated with the company, officially. Here’s Brad, who saw DeepSource from the time it was merely an idea, when he wrote us our first cheque.

We also traveled to Cleveland and presented DeepSource at PyCon US.

And I got to meet Guido! Talk about dreams coming true.

Heck, I even learned how to cook spaghetti!

Assembling the pack, yet again.

We came back to India in July after being almost satisfied with how the trip had been. It could have been better, sure. But I wasn’t complaining. What seemed like the hardest part now seemed relatively easy. I’ve always maintained that hiring is the most important part of building a company. A company, after all, is defined by its people — it’s success determined by how badly these people want that success. Hiring mistakes can be fatal as I had experienced first hand, and I didn’t want to make the same ones I made the last time.

Some of my ex-colleagues left their cushy jobs to work with us at DeepSource. These are some of the smartest people I’ve known. Nothing feels more humbling than having them put their faith in me yet again. This is something money can’t buy.

Some familiar faces, and some new ones. I’m so proud of the team we’ve put together.

Thankful, yet again.

It’s surreal how some people stand by you through thick and thin, all the time. These are people you can trust, and if you have someone like this, hold them dear.

I’m grateful for some people in my life who did the same this year. Thanks for all the love and support — in more ways than you would know. I’m not going to name the names, because you know who you are.

2019 has been good. It has been the year I put everything I had on the line yet again and tasted some success. But it’s just the beginning, and 2020 holds many great things. 2020 is going to be better.

But better is a relative term anyway.

Now, the most common reaction of leaders when they hit the second scenario in a sudden stroke of realization is panic. Since the damages have accrued over time, it becomes almost impossible to get a grip on the situation. Now instead of looking at a solution inward, which is where the solution is most likely to be, the leaders start looking at the easier way. Outward.

All organizational problems have a solution inward. But looking inward for a solution mean deep introspection, which often leads to discovering one’s own faults. It involves uncomfortably probing into the hot mess that your organization is right now, asking difficult questions, and taking the hard decisions.

Looking outward is easy. You get to turn a blind eye to all that’s wrong and put all your hope for a better tomorrow on a shiny new thing which is guaranteed to solve all that’s broken right now.

This shiny new thing takes many forms: a new product line, a new strategy, or a new hire. We’ll talk about the last one.

Enter the Messiah. The new hire who’ll seemingly solve all problems and more, magically! The leaders fall in love with this new hire who’s supposedly going to save them and the company and put unrealistic hopes and expectations from this person. I’ve been there. So have a lot of other founders, especially first-timers. I’m here to tell you, it’s the worst mistake you’ll ever do.

Never hire when you’re desperate

The magic never happens. Consider the following reasons:

1. A startup is a team effort, and it is incredibly rare — almost impossible, for someone to just drop in and solve some intractable problem. There is no rational argument that can support this premise.
2. In desperation, it is common to make bad hiring decisions, primarily because you end up looking for a messiah rather than a proper fit. Instead of empirically and objectively judging someone’s competence, it is very common to look at signals — fake indicators of virtue. What works for others most definitely wouldn’t work for you.
3. By bringing a messiah, the leaders most definitely end up disrupting the existing order in the team. In times of crisis, the last thing people should worry about is that they’re going to report to someone new from tomorrow.

Anand Sanwal, in his brilliant SaaStr Annual talk, mentions the Messiah Hire Fallacy as one of the screw-ups to avoid at a startup. This is something that a lot of startups end up doing. For some, the consequences are grimmer than others.

By the time we are actively conscious, which is when we start thinking for ourselves, our worldview has formed around this supposed duality. We start thinking about everything in terms of good and bad. The moment we have a new experience, we rush to classify them into either of these buckets. People, experiences, actions — they can either be right, or wrong. Rarely is there something in between.

A direct result of this is we start thinking in terms of extremes. We fail to acknowledge the continuum that permeates our existence and start believing in discrete functions. It becomes impossible to imagine there’s any other option apart from believing in God or not, for example. We think we fall into either of these buckets: rich or poor, successful or unsuccessful, beautiful or ugly, happy or unhappy.

Most importantly, we think there are only two ways of following an ideology — to follow it completely, or not follow it at all. We quickly associate these two options with, you guessed it, right and wrong. And the gavel of judgment bangs.

The truth lies in the continuum

Turns out, this approach of looking at things in either black or white is incredibly prohibitive on our abilities and the possibilities of what we can do. The mental block of trying to either follow something completely or not at all is exhausting and not very productive. It hinders our ability to improvise and forces us to think in discrete values instead of fluidity. There is a whole world of possibilities in the grey.

If we break away from the compulsion of either following or not follow something in its entirety, we suddenly have a lot of room to grow. Amidst two choices of doing something, it’s possible to carve out a third solution which can possibly take the best parts of either of the two extremities.

Once we’re at peace with not following any extremities, we get to see how liberating that is. After that, it’s very easy to get used to this balance. That feeling, as I’ve personally experienced, is life-transforming.

Balance as a way of life

In our everyday lives — personal and professional, we face these kinds of choices in plenty. Every once in a while, when taking a decision, two prominent choices will present themselves, possibly among many others. Naturally, and intuitively, your mind will rush to classify them as right and wrong, inevitably implying that one of them is the one you should choose and not the other one.

But next time that happens, pause and think — what if none of them is right or wrong? If you come to terms with that fact, it becomes easy to find your right choice that aligns with your principles.

That, I will argue, is a pretty good way of living our lives.

Truth will not make us rich, but it will make us free.

I had started DoSelect with my college room-mate right after graduating in 2014 as we moved to Bangalore, the city of dreams for anyone who wanted to build a startup. With a head full of ambitions and a wallet bereft of cash, we built a world-class technical assessment platform from scratch, helped numerous companies make their hiring funnels more effective, and added value to products of many partners in the last four years. Starting from absolute zero, we were able to achieve something that the entire team has been proud of.

Personally, I evolved with the company. Apart from learning to build products, I also learned the various intricacies of the human condition while hiring colleagues and managing teams. I had never worked in a team before but I came to understand the true meaning of leadership, loyalty and trust when I got to lead my amazing colleagues at DoSelect.

It is not our abilities that show what we truly are. It is our choices.

As the adage goes — change is the fuel of nature. When the din of glamour has faded, the sound of truth becomes deafening. Over the period of 2018, through all our ups and downs, slight swerve at times, I came to discover that there had emerged a fundamental misalignment between myself and other stakeholders of the company.

I began to seek an answer to whether I am doing justice to myself by doing what I am doing. We had shifted lanes to a path that would no longer take us to a place which I had envisioned for the company the way I wanted to, for all I could have tried. In retrospect, it occurs how we must all, at one point, face the choice between what is right and what is easy. It was time for me to move on. I decided to part ways with the company. As of October 31st, 2018 I am no longer associated with DoSelect in any capacity.

I’ve had the privilege of working with some of the brightest people in my team, for most of which DoSelect was their first job. Many of these colleagues have become trusted friends and advisors. I will be eternally grateful to all our investors who trusted us early on when nobody else would and helped DoSelect come thus far.

It has been an extremely difficult decision because I had lived and breathed DoSelect for the past four years of my life. But the decision was easy too because I knew this is what I really wanted to do. I will be immensely grateful to my parents, my brother, and my close friends who stood by me and helped me get through this. I cannot thank everyone associated with DoSelect enough who put their faith in me till the end — you know who you are.

What’s next for me?

I am building DeepSource, along with my ex-colleague and trusted friend Jai. We have a new mission — helping developers ship fewer bugs.

While shipping software and managing engineering teams for four years, I battled with numerous problems related to developer tooling and processes for maintaining the health of code. I’ve witnessed our own team battle from increasing technical debt. Many of my peers who run their own startups and manage engineering teams had something similar to say.

I believe there is a better way of doing this. Developer tooling has been an area of great interest to me personally, and I’m super stoked to be able to work on something which is so close to my heart. I’m excited for what’s about to come, what we build, and where we reach. The best way to predict the future is to create it. Here’s us taking a shot at creating the future, one in which tools to deliver reliable software, faster are accessible to everyone.

Thank you for reading. I wish you have a great year ahead. Onward and upward! 🚀

It’s times like these when you actually get to experience the blissful dullness of a small town — not during a festival where everyone’s dressing up and trying to reach somewhere on time — but this. It’s the onset of winter, with a wee-bit of chill in the evening air. Everything, and everyone, seems so calm.

Stay too long at a stretch in a city like Bangalore and it calibrates how soon you expect things to happen. I book a cab and expect it to be at my door in 10 minutes; or order food online and start getting antsy if it isn’t there in 20. Or an Amazon delivery in a couple of days.

Not here. Not a chance. The arc of time has a longer horizon here, and everyone seems to be okay with it. Happily okay, not compromisingly okay. I feel that alien, yet refreshing. Calming, even.

I had taken my mum shopping, and I realized to my utter astonishment that the place (it’s a one-kilometre stretch bustling with shops on either sides) hasn’t changed at all since the last I visited it and have since tried to preserve it in my memory from about 10 years ago. Same old shops, same old typography on the hoardings, same old people, same old air.

It’s funny how deeply we have been conditioned to expect how soon we’ll get to see change. Maybe it’s a fool’s pursuit to be in a rush all the time. Maybe things do take time. Maybe it is what is best for us.

In addition to these, I’ve realized that second-order metrics provide a higher-level view of a company’s progress over a longer time horizon. These metrics are introspective in nature, as opposed to outward facing like the metrics I mentioned earlier. They’re not very straightforward to measure but are very easy to understand nonetheless. And they uncover a number of things that the first-order metrics will miss.

What the engineering team is spending time on is one such metric. In most product startups, what the engineering team’s building can be categorized into two broad buckets: optimizing existing stuff, and building new things.

When the company is in its nascent phases and doesn’t have a product-market fit, nobody really knows what’s going to work. So they speculate what could work, and the engineering team spend their building new, speculative things. As time passes and the company gains users for these speculative things, the product inches closer to a market fit. The focus of the engineering team now must gradually shift towards optimizing these existing products as opposed to continue building new things. The ratio of time spent on optimization vs. building new things keeps increasing as the scale of usage of the product increases. And this becomes a necessity as well: hitting scale opens a Pandora’s box of problems that didn’t exist before. The code that worked well for the MVP a year back must be refactored and cleaned, lest it hold back the new people who’ve joined the development team. You must work on adding a robust caching layer now, and yeah — you’re probably going to need to rewrite that subsystem in Go because the existing implementation chokes up when concurrent requests burst. ¯\_(ツ)_/¯

In mature product companies, the engineers spend 70%-80% of their bandwidth in optimizing the existing products that serves most of their user base. Most of these changes are invisible to the users, even the internal non-engineering teams. These changes, one could argue however, are what sustain the product growth. The rest of the time and effort goes in building new, speculative things — hoping that some of these might cross in the former category in the near future.

A visible proof of this is easy to detect: take any popular application that you’ve been using for a long time — like Gmail, Facebook, or Uber. Now think about the last time you had noticed a major change in the existing UI or workflows, or addition of a new feature. Although you might notice, the one essential thing that you do in these apps has somehow kept on improving. If there are changes, they are in these core workflows to make them better.

Here’s another way to look at this metric: it can indicate the business progress of the company and provide an early sign of impending trouble. If the engineering team is regularly working on new things and not spending time with the existing code base, it clearly means non-adoption of existing products and non-achievement of product-market fit yet. If these new things are major new products, then each of these can be termed as pivots. It’s normal for companies to try multiple things before finding their fit — many great companies have taken up to 3 years to achieve it. But a recurring pattern of jumping on new things is generally a sign of serious trouble.

While this might sound not so peculiar in particular, let that sink in for a moment. What does it actually mean when someone says they want to do everything? They probably say ‘no way’ lesser — if not never, to things that come their way. The flip-side, as any observant by-stander would quip, is that they almost never bring things to closure. It would be safe to say that the most common assumption — or conclusion behind this trait is sheer lack of patience to stick to one thing.

I had discovered I was one such specimen of our species long ago. To be honest, for a fair portion of my life I’ve quite enjoyed doing a boat-load of things concurrently. Diversifying allocation of brain-space has historically brought tranquility to me in troubled times — but that’s an exception and not the norm.

“For a better part of your life”, one of my mentors had told me, “you must strive for laser-sharp focus on a handful of things”.

“You must figure out what you really want to do at the moment”, he had said. I came back home to mull over it with a troubled mind. I have never had to choose things to do. I just did them all. All the time.

So I did a thought experiment. I asked myself, if I were akin to a machine that shuts down every night and erases memory of what happened today in favour of a totally blank slate — what are the things I’d probably not do today. Then I repeated the same for duration of a week, a month, and a year. I wrote everything in my journal. I was surprised.

For instance, I was struck with an incredible realization this year. The societal machinery has us believe through countless instances of the rhetoric that hard work is truly tied to success. And trust me, I had internalized this ever since I was a kid. Until early this year, I consciously used to work 16 hours a day, glued to my text editor, genuinely believing this would translate to my company’s success inevitably. As a result, inadvertently, I completely ignored everything else which were equally important to the company’s success. A shift of perspective actually helped me realise how untrue that rhetoric is, and why success cannot be a function of parameters of the singular.

I’ve discovered that it is good to take a pause and reflect on the things that you care about once in a while. Even if you’re doing what you love, zooming out to see the bigger picture helps you reiterate your purpose. This also allows you to judge if it’s the most logical use of your time and effort — since you might be missing out on doing some other things that you really wanted to do, against something that you love but probably can do with doing it less.

We have very limited time left of whatever meaninglessness our lives are. Not being in control is not very efficient.

Us humans, we crave attachment. It’s all Chemistry really — but then, what isn’t? In reality, this undying desire for human connection drives a great number of major decisions in lives. These decisions come to define our being, and we end up living a life shaped by things that have not been in our control at all. When things go wrong, we conveniently find the other party guilty, or shift the blame to a third factor altogether, and in the worst scenario — ourselves. The emotional duress we are into at that moment flips off all logical reasoning and we spiral into despair. What a sad state of affairs!

Needless to say, I’ve been through quite a few heartbreaks myself — romantic and platonic. You fall enough times, and you start finding the root of the weed to kill it. What I’ve realized is, expecting the other party to hold up their end of the promise, however strong the perceived bond may be, is highly illogical.

Here’s why I think so.

When you make a promise, either explicitly verbal or unspoken, both the parties involved are in a specific state of being — say A1 and B1. These states of being are affected by numerous internal and external factors around everyone; personal and professional. After some time has passed, both people’s state of being has gone through numerous and humongous change because of the sheer pace of life today, and our constant state of moving from one thing to the other all the time. People’s priorities change, their aspirations and goals take a different turn, or they might have re-discovered their true passion for painting instead of that 9-to-5 desk job. Or they might have fallen for someone else, like they had once fallen for you. Or it could be something that’s much less obvious than any of these but way more profound. It could be either of these people, or both at the same time, or none of them yet. What happens between (A1, B1) to (A2, B2), thus, completely determines the fate of your relationship at the time of consideration.

Considering this perspective, who’s to blame then? Even if the other party left you for someone else and your soul’s hurting, the chances of you having left them for someone else are equally probable — logically speaking. This might seem implausible to accept when it actually counts, but it’s a perfectly reasonable premise in the retrospect.

Personal tenacity to handle severe emotional distress varies greatly from person to person. The most important thing in the face of such adversity is to somehow sail away from it at any cost. While it is immensely helpful to have an external support system that help you weather these situations, everyone has to be their own saviour in the end. Thinking rationally and not letting your emotions guide your course help you move on without much, if not completely free of, baggage. So you’re ready for the next thing that’s coming your way.

The society has unreasonably high impact on our personal lives, whether we like it or not. And through various inroads into our psyche, it tries to weigh heavy on expectations on the way we are meant to live. That doesn’t necessarily have to affect our major life decisions if we are headstrong and don’t give in to every thing the society expects of us. There’s no badge of honour in being the most socially accepted person. Everyone needs other people in their lives. But the extent of impact we let them make if things go south is completely on to us. Let’s try to keep our personal happiness in front of what’s generally expected out of us.

We go to the grave alone in the end, don’t we?

“I need to finish that Douglas Adams too”, I mutter to myself. I realize I have bookmarks put midway across almost half of the books in my mini-library. I’ve never been more proud.

Murakami it is. The Wind-Up Bird Chronicle. I take out my journal on the side, pick my favourite roller ball-pen. It’s going to be a long night.

I wonder how the Writers think. Mostly, I wonder what the Writers think about.

If you’ve ever read a really engaging piece of fiction late at night, a surrealistic one, you’d feel me here. After you’re down a couple of pages, you take your eyes off the book and drift into imagining the vivid scene you just read. You can imagine how Toru Okada might have felt sitting inside that well with that warmth throbbing on the blue mark on his cheeks. Could that hotel room be real? That’s some fucked up shit, man. Phew.

I wonder how the Writers think. Mostly, I wonder what the Writers think about.

Think about how the Writers are able to express the intended emotion with the most precise words possible. Are all the Writers absolute literary geniuses? Or is it the other way round — that you can only imagine the emotion the words have conveyed? Hard to tell, if you ask me. Let me jot that phrase down in my journal. Could be useful somewhere else.

I wonder how the Writers think. Mostly, I wonder what the Writers think about.

Have you ever wondered why you feel unusually bittersweet every time you finish a great book? You miss the freedom.

Real world, as they say, is too real after all. Time is not all fluid, but discreet. Day to day. Weekend to weekend. Year to year? While reading that story, the fluidity of time comforts you, lulls you into a sweet, sweet nap. Your consciousness drifts away into multiverses of possibilities, maybe one where Kumiko would still be pining away in Toru’s love. Heck, do you really want to come back? You fall asleep.

I wonder how the Writers think. Mostly, I wonder what the Writers think about.

Do you ever want to wake up?

Prior to the 1930s, résumés were merely a formality. For the job positions that would open up, word would spread mostly through print advertisements or word of mouth. People would queue up at offices to present their applications for these jobs. While talking to their prospective employer over a cup of tea, candidates would scribble their necessary personal and professional information on a sheet of paper and hand it over for record-keeping.

Over a period of time, as conventions moulded into norms, employers began expecting this record in prior to their meeting with potential employees — aiding the résumé in becoming a mainstream convention and a pivotal aspect in the hiring process. The upcoming century saw numerous re-modellings in the résumé’s format while its fundamental intent remained the same — of informing potential employers about an individual’s personal, educational and professional details, and the skills that would add value to the job position they’re seeking.

The résumé, which started as a trivial medium of transferring information, went on to become a definitive record of a person’s professional profile — and eventually saw itself transform into the single source of truth. Much of this success could be attributed to the absence of a better repository of relevant and organised information. This was an era during which storage of information used to be extremely centralized, and its dissemination, non-trivially expensive. Employers and recruitment outsourcing agencies had begun maintaining hordes of these static documents of declared data about prospective hires. The competitive advantage in hiring the best people was coming from the ability to collect more résumés.

In an ironic twist of intentions, quantity, and not quality, had become the drivers of success.

And this had worked well. In the 20th century.

The Age of Information

The Internet’s invention around the 20th century’s withering years, and its viral mainstream public adoption at the turn of the 21st century brought about a tectonic shift in how we consume and publish information by democratizing access to its means. The scale was huge and its embrace has been growing exponentially ever since.

Today, on an average, the working class spends 3.26 hours every day on the Internet, creating and consuming an endless stream of information. Correspondingly, the rise of social platforms has created more avenues for people to share data about themselves online, intentionally and inadvertently. We see ourselves documenting every significant aspect of our personality and our profession on the internet for anyone to see.

A great amount of indirect and implied professional information about us comes from our activities on numerous social engagement platforms. Take into consideration the various popular forums such as Github, Stack Overflow, Hacker News, etc for software developers; Dribbble and Behance for designers; Kaggle for data scientists, Hacker One for computer security researchers — to name a few. Communities like these have become deeply ingrained in our professional daily lives. We find ourselves actively contributing to the growth of this two-way stream of data, befitting our skills, interests and our proficiencies.

Leveraging this massive repository of public information to paint a better picture about someone’s strengths, weaknesses, and their personality in general, fulfills the original intent of a résumé. In the same vein, it aids in better decision-making, backed by data that can be proven with facts and isn’t merely declared.

This begs the question — why do we still need a written document reiterating a small subset of this information in a vaguely restricted and highly non-standard format? Résumés don’t need to remain the central source of information anymore.

Why are we still holding on to the floppy disk?

A relic of the past

In the present day, the platforms that help people find jobs and help employers discover people rely on algorithms that match an abstract job description over a repository of résumés — often collected over time, hoping to unearth a few that are actually relevant.

Fifty years ago, when the information and insights about a prospective hire could fit on a single piece of A4 paper, this process might’ve been the go-to mechanism for effective hiring. However, today, this process is bereft of objectivity, due to the sheer subjectivity of both the job description and the résumé. As a result, it becomes sub-optimal by definition.

The underlying résumé parsing and matching engines that drive the aforementioned platforms apply Natural Language Processing to convert abstract information to workable data points. With résumés as their primary data source for recommendations, the effectiveness of these platforms is limited by the quantity and validity of data points about a person.

The way we discover and match people with jobs must keep up with the blitzkrieg and magnitude of data available about people publicly on the internet. Otherwise we’d still be dwelling on the inefficiencies of the past.

Towards a data-driven future

Better job matching that works in favour of both the employee and employer can be achieved by exponentially by improving the quality and quantity of data involved in the matching algorithm, while refining the algorithm concurrently.

The days of job boards, résumé repositories and résumé intelligence engines are numbered if they do not fundamentally reinvent their core workflow around the primary problem they had set out to solve.

Better matching of people with relevant jobs consists these components:

Better candidate profile

There’s an immense amount of data publicly available about everyone, and in different contexts. Leveraging this data to extract direct and implied information while creating a comprehensive profile would enable better decision making. The information you interact with would be backed by facts, and not declarations or opinions.

Better matching algorithms

Natural language processing and Boolean searches can only get us so far. The number of vectors in the algorithms we use must scale with the number and quality of data points in the candidate profile, hence enabling better contextual match.

Better job descriptions

Abstract and poetic job descriptions do well to impress a human being, but fare poorly when it comes to machines. The best recruiters involve a huge number of other vectors as part of their job description when evaluating a candidate, and the machine should not do it any differently.

Data, as they say, is the new soil.

If you take a look at other life forms on Earth, chaos is the norm. Uncertainty and unpredictability defines how all creatures live. Pop out of an egg or a womb one fine morning, then either live all your creature-years fulfilling your daily loop mindlessly, or die the very next day. No decisions to make, no hearts to break. Oh, what a life that must be! Think about your dog, or your neighbour’s cat. Or the fly you just did squat. How many decisions must have they taken that changed their lives? Or how many hearts must have they broken?

So yeah, we’ve found order in our lives, courtesy the society and all the rules and constructs we have woven around how to live in it. There are rules on how you are supposed to behave. Even if your moral compass is all fine, there are unspoken rules and expectations laid down that you must adhere to, or you’ll be ostracized.

We’ve been raised to feel at home and at peace with this order. But at times, the civility of this loop breaks and you end up being out of sync. You’ve messed up, you did not follow the rules to the word. Maybe because this time you did not give a damn. You didn’t listen to that voice in your head that tried to make you succumb and eat what you really want. Good job! But now, you’re out of sync. There’s nowhere to go, because the others want to stay in sync too. They cannot truly feel what happens when you’ve broken the loop, unless they break it themselves. You have nowhere to go.

Where would you go?

Everyone needs a place. It shouldn’t be inside of someone else. — Richard Siken

I’ve been at such a juncture multiple times in my life. Many a time, when I feel I have nowhere to go, I go to my refuge. The one that I’ve built for myself over the years that holds me safe when there’s a shitstorm going on outside. It’s like my underground bunker to prevent me from all that nuclear fallout. Then when the fallout ends, I come squeaky clean, stronger than before.

For me, my refuge have been things that have comforted me at some point in my life. Books, movies, songs, places. Whenever I’d feel miserable, I’d go back to one of these things and cut off from everything else. However insurmountable the heartbreak might seem, I’ve always come out clean on the other side. I’d re-read few chapters of Murakami or the Hitchhikers Guide to the Galaxy, re-watch Harry Potter or Interstellar, or The Man from Earth. I’d listen to Radiohead on a loop for hours. I’d watch Sarah Kay perform Point B. I’d listen to Carl Sagan talking about a Pale Blue Dot — which sounds almost like a surreal sermon in fact. I know I’d come out clean, healed.

What does your refuge look like?

A lot has been said about how startups are inherently and fundamentally different from traditional businesses.

A ‘startup’ is a company that is confused about: What its product is. Who its customers are. How to make money. — Dave McClure

I find this notion deeply resonating with Jean-Paul Sartre’s border-line uncomfortable, nauseating ideas about life. “Man,” Sartre had quipped, “first of all exists, encounters himself, surges up in the world — and defines himself afterwards.” If you’ve ever had a tryst with building a startup from ground up, or have been a part of a team doing that, you will find resemblance in this quote. The inception is all but the very start of a long, tumultuous struggle for validation of your ideas that you perceive will solve a real problem in the world. But the real definition of what your startup does should be dynamic, adjusting to the ever-changing nature of the original problem you set out to solve. A year or two in the business, assuming that you’re actually trying to build one, you’d realise that most of the original ideas and hypotheses that you started with are either completely unfounded, or precisely on point. Both these things are equally good for your startup, because now you can answer, “what’s next?”.

The basic tenet of existentialism, the school of thought Sartre founded, is that there’s no clear path laid out for human beings. That after being born, we are thrown in this mind-boggling pit of chaos which we call life which doesn’t come with a user manual, and you are supposed to get through it purely based on your learning until one moment before. This thought might be nauseating to most of us, but it most generally makes a lot of sense.

“We do not know what we want and yet we are responsible for what we are — that is the fact.” — Sartre

How does this help us build better startups?

When you are an early-stage startup, you are essentially in a perpetual state of figuring things out. I like to call this the perpetual state of work-in-progress, which could be a re-phrasing of Dave’s quote about startups. When you start building a startup, you first find a problem and envision a solution that would solve this problem in a way that creates value — that’s your point A. How big your startup will eventually be depends on how big and pressing the problem is, and how valuable your solution becomes for the users you’re solving for — that’s your point B. This can be considered a general rule of thumb for both B2C and B2B startups.

The journey from A to B defines the impact your business makes. This journey is characterised by the decisions you make, big and small, inward and outward. The one thing that never changes is that the problem you set out to solve will constantly change with time. Affected by numerous factors, the nature of your one big solution must change in its scope to adjust for the dynamic nature of the problem you’re solving.

Adjusting your startup’s vision and execution constantly, thereby, is a manifestation of Sartre’s philosophy. Assimilation of this notion allows us to re-invent ourselves multiple times while calibrating for change. While this sounds pretty straight-forward and common sense, it is substantially difficult to actually put in practice, especially when you’re trying to assemble your aircraft on your way down from the cliff.

Life is a comedy to those who think, a tragedy to those who feel. — Jean Racine

The human psyche is an amazing, devastatingly complex thing. Ever since we dropped out of our mother’s womb and into this world, every moment of our life — every single one of them, shapes both our physiology and psychology. Right from when we were toddling, to when as independent adults we are supposed to take life-changing, path-altering decisions. Add the 8 seconds long attention span we have, thanks to the endless stream of notifications and buzzes pervading every living second of our being, to the mix and you have the perfect recipe for an emotional time bomb.

As a result, we are emotionally the most vulnerable today — hiding our fears and insecurities behind our 5-inch mobile screens, finding validation in swipes, likes, hearts, blue ticks; basically anything that shoves instant gratification into our face. In such conditions, being a hopeless, hapless romantic could be stressful. Or in most cases, downright depressing. Trust me. I’ve had first hand experience.

I had started reading Stoic philosophy lately, studying letters of Seneca and writings of Zeno of Citium, the founder of Stoicism. The Stoic school of thought is very wide in it’s scope and extremely difficult to practice to the word. In a nutshell, it outlines a way of living and thinking, characterized by endurance of pain or hardship without the display of feelings and without complaint, and indifference to the vicissitudes of fortune and to pleasure and pain.

Basically, the stark opposite, and comfortingly so, to the kind of life an average millennial lives today.

So, how would a Stoic handle this melting pot of emotional potpourri that we go through everyday?

Love is a one-way street

We tend to fall in love too easily, and too often. And unless the receiving end is an inanimate object, reciprocation of that love is what drives us mad. I’m not talking about just romantic love here, but all kinds of love. At any point, we are involved in a whole bunch of relationships — with our partners, our siblings, our best friends, our not-best-but-still-pretty-good friends, our parents, and so on. In most of these relationships, there is a component of love involved.

The expectation of reciprocation, and with the same amplitude, is one of the main reasons of our distress. So, the Stoic will just get rid of that.

Get rid of the expectation of reciprocation all together. Why? Because nobody’s obligated to love you back. Not one soul. The very realization of this fact relieves you from so many things. You are free to love anyone, everyone. It’s not about you anymore. That feeling is liberating.

Tell someone you love them just so they know. Expecting reciprocation, thus, is not rational.

Life is kind of unfulfilling

Midnight in Paris has been one of my favorite movies of all time. In fact, it’s been my go-to movie whenever I am in emotional distress. If you’ve not watched it yet, I strongly recommend you do.

Another basic tenet of Stoicism has been the acceptance of the fact that life’s not very fulfilling — even if you try to do all the right things, apparently take all the right decisions. You only have control over a very little part of even your own life. So a Stoic would stop trying so hard to write a perfect story. He would rather try to write a fulfilling story instead. Perfection doesn’t guarantee happiness. Fulfillment always does.

Reading Stoicism and trying to follow parts of it has brought a great transformation in my personal life over the past few months. I hope to understand this philosophy in more depth — and I’m excited to see what other changes I can make to my professional life as well.

I have never been an introvert — quite the opposite, as you might know if you know me. But I’ve always found solace in stories. There’s something surreal about fiction — any kind of fiction. The way that our brains are wired and put together, fiction sets something off up there; and you lose all material sense in the world and start living in that imaginary world for a moment or few. I, for one, love being subjected to that. I find it comforting.

I read fiction because it fuels my imagination.

If you do something creative as part of your day job, you need an inlet and a healthy supply of that creative juice. Coding (which is what I do for most part of my work) requires imagination, and most of coding is done when you’re not at the desk. So you need to keep those cogs turning all the time. You never know when you’ll hit the solution of that problem that’s been bugging you for most of your week. Reading fiction and letting yourself immerse completely in the story, if only for a few minutes everyday, gives your grey cells the essential fodder.

I had picked up Kafka on the Shore by Murakami a few months back. It took me almost two months to finish the book, since I could only manage a couple of pages everyday — but I savoured each and every line of that book. Cross my heart.

I read fiction because it makes me stop and reflect.

The books which would be the most valuable to you would compel you to put them down every few pages — and think about what you’ve just read. You’d either need some time to absorb the scope of what you just read, or you’d wander off to your own chain of thoughts set off by it. Either way, you embark on this journey of self-realization every few pages, and then come back to the story only to get some more.

Reflection like this, according to research, is a vital part of the learning process. You think about things that are unreal in the physical world — but they’re already flesh and bones in your mind. There are no rules, and there is no box. This makes easier to comprehend complex constructs of ideas, philosophy or emotions.

I read fiction because it pays off to.

Reading fiction, and difficult fiction, takes a lot of patience and perseverance. a 700-page book is a lot of reading material, and even more so when you have to put it down every three pages for a mental detour or daydream. But it’s always so satisfying when you reach the end of it. Sometimes you feel sad (as I do at the end of every Dan Brown book I read, because it has ended), but you’re always satiated. This is true with most of the work that we do. Hard work always pays off, whatever the fruits might be.

I’m currently reading a few books at the moment, a mix of fiction and non-fiction: The Wind-Up Bird Chronicle (Haruki Murakami), Letters from a Stoic (Seneca), The Magic of Reality (Richard Dawkins) and Love, Loss and What We Ate (Padma Lakshmi).

No matter what our job titles, our jobs are all the same — to make the product better for our users. Every day. So let’s do that.

That is indeed a profound thought. The author of the article is a project manager at a SaaS startup in the Silicon Valley.

Just today, I was reading “How Google Works”, a book by Eric Schmidt and Jonathan Rosenberg. They assert, the most important reason for Google’s success has been that they’ve been able to attract the best minds of the world, smart creatives in Google-speak, to come work with them. They say they did this by building the culture where these smart creatives will thrive.

This got me thinking. Startups are only about people — your users and your employees. If the founders just focus on these two aspects of their company, success generally follows. I’m not saying this, Eric Schmidt is.

The surprising thing is, no one ever talks about this. Everyone talks about getting the product market fit, getting initial traction so you can raise funds, keeping the clique up so you get noticed by that investor. No one gives advice on how you can hire the best people for your company. While the former are important, it turns out the latter is critical.

As a first-time founder, it was one of those “Aha!” moments I had when I was out of internet for one good hour and I used that time to complete the book.

Hope the internet goes out more often! (Or not. I need to read more books.)