08 July marks 8 months since I started working in Saleswhale (08 November 2017), and also the last month that I will be here before enrolling in college. It is an opportune time to look back and reflect on my growth as a software engineer and to collate the lessons that I have learned so that I may remember them in my future endeavors. Actually, given the stark contrast between academia and industry, I am quite certain that I will gradually lose sense of the things that I learned, especially those regarding working in teams and software engineering best practices.

The experience of working at a seed-funded startup was similar in some ways yet drastically different in other ways to what I had envisioned. This post will detail the lessons and observations that I have gleamed from the working culture of the company.

The 80/20 Rule

The 80/20 Rule, or Pareto’s Principle, states that 80% of the effects comes from 20% of the causes. This means that we can find a way of only expending 20% of the effort to achieve 80% of the results. In our engineering team, the earlier core features of the product that we worked on were all those which can produce disproportionate impact, in line with both the product vision and customer requests and feedback. As a pre-Series A startup it is imperative that we find as many creative ways to maximize our limited resources as possible. Our culture encourages us to pilot and experiment with ideas, even if they are unscalable, and then to further iterate and refine on them if it proves to be promising. As far as possible we want to make the easy, high-leverage wins first. The V1.0 of our product features represent the bare minimum of what is constituted as usable, so that we solve the most pressing of our customer pain points, and begin to smooth out the rough edges by progressively incorporating customer feedback and our product vision into subsequent releases. By directing our efforts in this manner to do the things with the most disproportionate impact first, we are able to stretch the output our resources to its limit and be able to deliver much more and much faster than if we became fixated with nailing every single small thing right.

However, the caveat is that the 80/20 Rule is also subject to the law of diminishing returns. As our product has matured to around one year old, the easy wins are no longer so easy to find. Our recent releases and subsequent features scheduled in the pipeline are all extremely logic-heavy without much precedence in the industry to draw inspiration from. It should stil be noted though that although the problems that we are tackling are becoming increasingly challenging, the way that we handle them can still take advantage of the 80/20 rule. Always strive for simplicity.


When I first joined Saleswhale, the one thing that I was very surprised about was that there was no over-time culture here at all. My impression of startups, especially early stage ones, is that employees all put in crazy hours and are potentially even expected to work on weekends, and be on call all the time. On the engineering side, whenever a product release could be potentially delayed as a result of unanticipated obstacles, bugs found during testing, or an unforeseen increase in scope, the decision was never for everyone to start working overtime and push it through to the last mile, which I thought was reasonable drawing from my experiences of many last-minute group projects with everyone working around the clock. Instead, the approach taken was to either perform a partial release with a subsequent version planned right after, or to push back on the release date.

Seemingly counter-intuitive, frequently working over-time can actually harm a startup more than the benefits that it brings. Each additional hour put in has less marginal utility due to the limitations of human concentration, and eventually there will be more downtime from employees due to sickness and the need to catch up with their own lives, family and friends. Frequently employing the use of over-time will also promote a culture with a lack of accountability and poor project planning and estimation. Going over-time will be seen as the cure-all whenever things fall behind schedule, which often backfires because even by then the estimation of the project completion date is already far off.

Ultimately, delays are a result of incorrect project estimations, and this is a difficult skill to master. It takes experience and domain knowledge to be able to accurately estimate the time taken for a feature, and research has been shown that most people under-estimate the time required.


One of the things that I like most about Saleswhale was its culture of openness and transparency. The various departments (engineering, sales, customer success) always sought to over-communicate with each other, surfacing any potential issues before they arise. It has helped to foster a strong sense of mutual trust and accountability. One of my favorite events is the monthly Town Hall, where the CEO will present on the company performance in the past month and the KPIs that we aim to hit for the next, followed by sharings by the heads of each department on their key milestones and metrics. Engineering will share on the product features that we released, the engineering support tickets that we have done, any internal tools or enhancements that we built, and what we will be working on next. Sales will announce the numbers of leads reached, meetings booked, and accounts closed. Lastly, customer success will detail the accounts that were converted from the pilot trial to an annual contract, account upsells and expansions, customer churn, and the upcoming accounts ready for renewal. By being completely open and honest with each other, each of us have an accurate depiction of how well the company is doing, and to raise suggestions for improvement if necessary. We have been through many tough and trying times where things have been going far less than ideal, but the knowledge that each of us will ultimately be directly accountable for our performance to the rest of the team has helped bring us through.

I realised over the months that one of the best ways to make bad news palatable is to always seek to over-communicate with your stakeholders. Let them know honestly how things are going, be it good or bad. Things happen on a probability scale. Surface potential troubles that have a chance of occuring so that the other parties are mentally prepared to accept this risk, even if they ultimately do not occur.

There will be many more posts about the things that I have learned in Saleswhale to come. Hope that you have found this post insightful, and let me know what you think in the comments below!