Tag: Decision Making

The “but” decisions

Was talking to a really early stage startup recently. The founders have been building the product as a side-hustle, have a few initial users but are now facing a decision fork. They need to raise capital to be able to leave their full-time jobs and focus on the startup BUT investors typically want founders who are already full-time before they commit capital. How does one resolve this?

I have personally faced several such forks, especially since starting-up 2 years back. I call them “but” decisions – they are irritatingly hard because both sides of outcomes have similar chances of actually happening.

  • Despite many iterations, the product isn’t hitting the expected metrics. On one hand, you had decided that if the desired metrics aren’t achieved, you will seriously evaluate the company’s future. BUT, you also hear stories of perseverance where an extra 12 months ended up changing the growth trajectory of many startups.
  • You are close to hiring someone for a super-critical role but aren’t fully convinced yet on the candidate. On one hand, it could be just the person you were looking for, who ends up contributing really well. BUT, it could also blow up in your face, end up eating valuable runway and adversely impact the rest of the team.
  • You are feeling stressed about various challenges facing the company, and are contemplating discussing it with an investor in the company. On one hand, the investor’s interests are perfectly aligned with yours and advising founders is one of their core roles. BUT, you have seen/ heard of several cases where these interactions have blown up in the founder’s face in more ways than one.

“But” decisions also have other added complexities like not having prior experience to turn to & existential impact in case of an unfavorable outcome. A common advice would be to talk to people who have dealt with similar situations. Again, what I have seen is that you get very divided opinions wherein people in the past have ended up on either side of the equation.

I haven’t yet been able to figure out a perfect framework to make these “but” decisions. Typically, I try and go by first-principles, following a method very similar to what Annie Duke frequently talks about:

  1. Map out various outcome scenarios
  2. Do a macro-filtering based on a) values and b) goals I have set for the particular context
  3. Figure out the upside & downside quantums for each scenario (qualitative and/ or quantitative)
  4. In my head, assign some kind of (even qualitative) “probability” to each scenario, based on what I know at that time
  5. See what the expected payoff is looking like for each scenario

While speaking to relevant experts/ mentors, rather than accepting any binary advice on face value, I adjust the above variables based on their inputs. Also, I try and adjust for few specific biases I know I have been prone to in the past (eg. optimism bias in my case). My better half plays an awesome role in calling my biases out :).

I know these decisions can’t be taken mathematically but the above process at least makes sure I am thinking 3600 about the problem. But even with all this prep & analysis, frequent screw-ups happen 🙂 It’s part of the game – I believe the idea is to get a little bit better at these “but” decisions each time…and avoid risk of total ruin to be able to keep playing the game.

Smarter engineering decisions in startups

Team Workomo had an excellent working session on engineering last week with Prashanth Susarla, ex-CTO of PayU. He shared several frameworks and heuristics with us for taking smarter tech decisions as a really early-stage startup. Sharing key insights below 🎯

#1 Less is more: proactively look for platform elements where you can avoid coding and offload to off-the-shelf services. Look for opportunities where you can cut down your own code. Avoid unnecessarily complex approaches for low-value tasks 🤺

#2 Invest in automated testing: it will yield valuable dividends compared to manual testing. In fact, engineering teams should invest in automated testing ASAP else it becomes part of a broken culture that’s tough to change later ⚙️

#3 Testing is strategic to the product: often teams tend to view testing as low-value ops. Being able to design great test cases is a high-value skill. Break down the most critical user journeys and start automating them. Don’t sweat over perfecting the testing frameworks yet 🛠

#4 Aim for architecture reliability, not perfection: at really early stages, with rapid product iterations and pivots, engineering teams need to build for progress and not perfection. Having said that, keep periodically stress testing your backend for expected traction loads 🏋🏼‍♀️

#5 Define engineering SLAs via highly-specific user stories: eg. a user story could be “95th percentile of my users should not see more than a 5 min delay between updating their Gsuite calendar vs those changes reflecting in the Workomo panel” 🎥

#6 Apply ML to project future loads & requirements: while engineering is building for high-velocity weekly/ biweekly releases, certain core elements require thinking through requirements say after 1–1.5 yrs. However, you can’t build for it right now. So use ML to break down the problem and optimize 🔬

#7 Account for engineering activities in product sprints: core engineering tasks that aren’t always directly related to a specific feature release, still need to be baked into sprint planning & timelines. Helps balance prioritization between feature releases and tech debt optimization ⛹🏽‍♀️

#8 Build a strong engineering culture: that happens as a result of adopting strong habits. A bad habit will often give you speed but destroy value in the long run. Even if you are moving in bi-weekly sprints, always have a 3-month view and a 1-year strategy in place ⏳

#9 Security is important even for a really early product: your platform coming under attack is not a question of “if”, it’s a question of “when”. Think about security as soon as you launch, even in private beta. Imagine a doomsday scenario once a month and prepare for it 🏹

#10 Finally, the best engineering teams are driven by humility: while looking to build any feature or platform, teams need to be incredibly honest to themselves about their present capabilities, what risks can they take, what plans can they pull off & take decisions accordingly 🧗🏽‍♀️

What are some engineering best practices that have worked for you in an early startup environment? Would love to hear your thoughts.

Note: this post first appeared on the Workomo blog here.

Decision-making learnings from India’s James Bond

I have always been fascinated by Ajit Doval, current National Security Advisor (NSA) to Prime Minister of India. At least from what I have been able to research, he is India’s first NSA to have also previously been an intelligence agent & ground operative behind enemy lines for decades. This makes his talks on defense strategies & decision making really fascinating, as he speaks from his experience on the ground, dealing with extremely high-pressure, high stakes situations.

I recently came across Mr. Doval’s interview called Talking Point. Similar to the Art of War by Sun Tzu, which has fascinating leadership & decision-making insights from ancient Chinese military knowledge & strategies, Mr. Doval gives some interesting insights from his intelligence & military operating experience, particularly around tough decision-making.

Here are some key takeaways from this interview:

  1. What makes a decision tough? — a decision is tough when its consequences are “large” —quantum of impact is large, or impacting large number of people, or consequences remaining for a long period of time.
  2. Objectives (why)→Decision (direction) →Option (how to execute) →Execution — this is the full-stack framework for tough decisions.
  3. Clearly articulate your objectives for taking a decision — take out all adjectives and adverbs, only have nouns and verbs. Make it as simple and crisp as possible. eg. “ I am taking a decision to [ACTION] on [SUBJECT] on [SCHEDULE]”.
  4. Do an objective analysis of your capabilities before taking a decision & choosing optimal execution option — what resources are at your disposal? What is your level of understanding of the subject?
  5. Do an objective analysis of your state-of-mind before taking a decision & choosing option— am I angry? Am I fearful for my life? Am I fearful for my family? It’s almost impossible to take objective decisions under any sort of heightened emotional state.
  6. Each decision option has a cost, associated time and probability of achieving your objectives — you need to choose the option which is most effective on cost and time, while having sufficient chances of achieving your objectives outlined earlier.
  7. Frequently, decisions are right but option chosen is wrong — important to differentiate between the two (my interpretation is that decision is more about direction while option is more about executing on the direction). Wrong options typically get chosen due to lack of experience, knowledge or sufficient preparation.
  8. Manage your fears by articulating them clearly — once you do this, in most cases, you realize that the fear isn’t as big or binary as you thought. Then, mitigate the specificities of this fear via hard-work, preparation and using your knowledge/ expertise.
  9. More important than obsessing over how to take a decision, is being prepared to cope with what happens after a decision has been taken — human brain has limited capabilities and we aren’t crystal gazers. In most cases, vital decisions are taken under stress, anxiety and uncertainty. Given nobody really knows whether a decision is right or wrong, it’s more important to think about how you will cope with the aftermath, in case the decision doesn’t pan out the way you expected.
  10. Assume that the “as-is” situation will unexpectedly change after your decision — be mentally prepared to cope with a new set of reactions, externalities and realities. Trust your capabilities and resources.
  11. While taking vital decisions, work out a “worst-case scenario” and prepare for it — first, figure out if you can survive the worst-case scenario. Second, work on bringing down the cost of this scenario, to bring it to an “affordable” level where the risk becomes worth-taking. Doing this requires time, preparation and knowledge.
  12. More important than making the right decision is making the decision right — you need to use your commitment & hard-work to ensure that once the decision is taken, it delivers positive results.
  13. For decisions with potentially massive impact, always have a “fallback position” — having a contingency plan is crucial.

In addition to these widely-applicable insights, Mr. Doval also talks about his execution style. I found these points interesting so also including them below:

  1. Solo — prefers being a solo operator. In an intelligence mission, risks go up as dependencies on other people get added, especially due to potential Prisoner’s Dilemma in case the mission blows-up. He might totally believe in a mission, while someone else might be doubtful. Hard to achieve success in a doubtful state of mind, particular as an operative agent. He doesn’t like to expose other people to risks that he, personally, is willing to take.
  2. Surprise — doesn’t use the same operating strategy/ style more than once. This forces him to articulate a fresh set of assumptions every-time, and validate them again. This takes out any historical bias from decisions.
  3. Speed — if you are fast, even if the enemy knows about your mission, you can still beat it say even by a few secs, achieve your goals and escape out of the situation. Key is to strike fast and get out fast.
  4. Secrecy — in any type of situation, being able to hold vital information and secrets within you is critical.

While we consume majority of our content from successful founders, investors and business gurus, it’s important to diversify sources of knowledge and refer to learnings from other disciplines. Personally, I have found 2 such diverse areas very useful for both professional and personal learning — 1) creative arts (movie directors, artists, authors etc.) and 2) military (navy seals, intelligence ops, historical warfare strategies etc.).

Let me know if you found this piece helpful, and what non-venture areas do you refer to for fresh insights.