Sachin Rekhi

For years now in the valley we've been shunning the traditional approach to launching a startup: writing a formal business plan, pitching investors, assembling a team, launching a product, and selling it like hell because we've learned the hard way that more than 75% of all startups fail and we needed a more iterative approach that allowed us to learn from our failures and refine along the way.

The customer development and lean startup methodologies evangelized by Steve Blank and Eric Ries brought us a better approach that favored experimentation over elaborate planning, customer feedback over intuition, and iterative design over traditional “big design up front” development. It championed the creation of minimal viable products (MVPs) as well as pivots when necessary to quickly adjust directions.

However I've seen too many startups use the lean startup methodology as an excuse to fly by the seat of their pants and shun almost any structure to their approach to iterating, validating, and finding product/market fit.

During my sabbatical I knew I wanted to make health and fitness my #1 priority. This was important to me as it's something that I've always said I wanted to do, but have never truly prioritized. My career has always been my #1 priority. And I get incredibly obsessed with just that, leaving little room for other such important priorities. This time was going to be different as I had very proactively put my career on hold temporarily in an effort to create some real space for me to focus on health and fitness.

So as I set out to execute on this, I knew I wanted to lose some weight as well as develop a habit of regular exercise that I could maintain for life. The question quickly became well how much weight should I lose? And how much exercise should I try to incorporate? And how was I going to measure my progress in terms of actual results? While there are easily accessible generally accepted health guidelines for both, I decided I'd take it a step further as I was really looking to use this time off to establish health and fitness best practices for life. I also knew that I was now past my prime now in my 30s so the dream of those washboard abs was long gone and instead was now looking to ensure I live a long healthy life. So I decided to analyze the top ten leading causes of death in the United States in an effort to help me produce a set of Health KPIs that I could use as life guidelines to reach not only my physique, energy, and endurance goals, but also to reduce the risk factors where possible for each of the leading causes of death.

Over the last month I've spent time optimizing the financial services, apps, and tools that I use on a regular basis. I arrived at what I call my financial stack based on conversations with friends, colleagues, experts, as well as my own research. Lots of folks have been asking me what I ultimately landed on, so I wanted to share my financial stack as well as the rationale for my choices. Thought it might also be helpful for those who are interested in better understanding Millennial mentality through a case study of one such Millennial and how I went about making my financial choices.

One of the classic pieces of software engineering literature that has had a profound influence on me since first reading it at Penn Engineering is The Mythical Man-Month by Fred Books. Fred initially authored the book in 1975 based on his experiences at IBM managing the development of OS/360. His central thesis is that leveraging man-months, a hypothetical unit of work representing the work done by one person in a month, as an effective way to estimate software projects is a myth. Put more simply, adding manpower to a late software project in fact makes it even later. This is because adding additional people to a software project significantly increasing the communication overhead and more people need to communicate in order to ensure they are aligned and aware of what everyone else is doing on the project. This significantly reduces the incremental output from each added resource.

While this is a well-understood and generally accepted reality, I still see many software organizations using some form of man-months for their estimation and jumping to add additional resources to their team in order to try to speed up their projects. I wanted to share some of the lessons I've learned on how to improve software engineering team velocity without simply adding additional resources to the team, which has all the challenges that Fred describes.

In a recent post Tomasz Tunguz helped popularize the term B2C2B, which characterizes enterprise businesses that leverage winning the hearts and minds of the intermediate consumer, the employees of the company, as a primary customer acquisition channel. This bottoms-up approach to driving adoption & purchase within the enterprise has gained popularity for SaaS companies in the past years, including very successful startups like Dropbox, Slack, and New Relic leveraging the model.

LinkedIn is arguably the largest B2C2B SaaS business out there and I wanted to take the opportunity to share some of the lessons I learned on leveraging this model for success.