Do you know who Dr K is?
Nithin Kamath, Founder CEO of Zerodha, India’s Largest Stock Broking Platform calls Kailash Nadh, CTO of Zerodha as Dr K.
Kailash Nadh has a PhD in A.I and Computational Linguistics. However, when I read the Zerodha Tech blog by Kailash, Dr K, felt to me like an honorary conferred doctorate than one through the route of PhD because he deserves the honorary one as well. His personal website tells a powerful story of his journey and his contribution to open source.
Take a good amount of time and a tall coffee to read the post published by Kailash on how they have been engineering in Zerodha over the last 7 years. For someone like me who is craving to see the Spotify Types Model of Engineering from an Indian company, Zerodha disappointed me quite a lot with that post.
Why did they disappoint me?
Have you read their post? Can you see what I am seeing? Can you?
To help you see what I am seeing is the reason I am writing this post that is going to be lengthier than their post. Pick up a Venti if you want, before you start reading this one because you may anyway have a sleepless night and you can blame it on the coffee.
Foundation of Zerodha
Zerodha is a bootstrapped, self funded, profitable company and yet a market leader. This itself makes them an outlier. Outliers build things the outlier way. Have you tried their platform?
I have. So, I am speaking not just from the 17 years in Software Testing and Product building background but I have gone through their end to end experience just as their customers go through. I have used their app on my Pixel 2XL and the web platform on my Macbook Air.
I don’t trade regularly but I monitor the market fluctuations. My team and I have this habit of trying every possible software available out there, even apps that are paid, so that we can build oracles to test when we are testing similar products.
Zerodha gave me a seamless experience. Right from the registration process, to their people calling me up and getting me to submit my documents and to onboarding experience on their trading platform, it was very customer savvy. Their UX principle seems to me as -”Keep it simple, visible and actionable to users”. I love it. So do many other users.
Zerodha was a floor away from us. Moolya Testing had an office in Bannerghatta Road, Bangalore at Springboard, co-working space and Zerodha were just a floor away. I have had the pleasure of bumping into their employees in the lift and over hearing (well, in the lift there is nothing to overhear, you just hear) their conversations. They sounded an energetic bunch and certainly had good team bonding. There were no cold shoulders. Once in a while they were discussing how they could prevent certain issues to the customers. This is their foundation. A team committed towards resolving customer pain points in the space of stock broking. Strong DNA.
The positives of being bootstrapped
I know what being bootstrapped for this long means. I have done it. I also know the challenges with it. Some people call being bootstrapped as real entrepreneurship. Some people call it being foolish in a capitalist world. Girish Mathrubootham, Founder CEO of Freshworks once asked, “What do you want to be, Pradeep? Do you want to be a King or do you want to be Rich?” and like anyone else, I answered, “I want to be a Rich King” and he said “That is possible and rare. Make your choice and be happy with it.”
The founding team of Zerodha are Rich Kings and Queens. Rich, not just with money but in Culture. King and Queen, not just in the freedom they have to make decisions but in Leadership.
Analysis of their guiding principles
Their people aren’t looking for jobs.
Tech stacks should follow “right tool for the right job” and should evolve organically.
Isn’t this obvious? While it looks obvious, it is not. I have seen organizations fail by choosing “popular tool over the right tool for the right job”. Sahi is a right choice in certain contexts. I know teams that chose Selenium over Sahi because working with Selenium sounded more cool than working with Sahi, leading to opportunity costs, tech debt and maintenance costs”
While that is on one side, sometimes developers of a certain kind become obsessed with a particular language. I have been a witness to a number of discussions on Java versus Python that resulted in no progress on automation because the debate isn’t over yet.
Why is it tough to pick the right tool for the right job?
It is possible only when :
- there is no ego
- there is an aligned intent of the team to solve the problem
- the focus is on the customer
- the team members are not feeling insecure
- they are there to stay and not job hopping for money
Zerodha got all that right because of their DNA. Read this one:
Be patient and let talent grow.
Startups run at crazy speeds. VC’s pump money to get more and more speeds. I like them. Who doesn’t want to make money fast. Startups running at the speeds they do, don’t have time to let the talent grow. They want ready-made talent. The ready made talent jumps from one company to the next in search of hot cash or for more speed.
They must be stupid to tolerate terrible mistakes.
Everyone has been a hacker or a hobbyist straight out of college. Trust developers and tolerate (even terrible) mistakes.
Since Zerodha hires straight out of college or hobbyists and helps them, it gives them opportunities to make mistakes and learn from it – the team sticks to them really well.
Plenty of successful funded startups don’t have the retention rates that super successful bootstrapped startups like Zerodha have. Also, many startups traveling at the speed of sound today don’t have time to build a strong learning foundation for people who are straight out of college.
The seniors are people who are busy with their own high speed high value targets and don’t have time to coach the youngsters. The youngsters become hackers – which is good – only the self learning types win. Even people like Saina Nehwal and PV Sindhu need a coach to win. With Zerodha they have a coach in Kailash Nadh who has patience, persistence and a long term vision.
In the funded start-up space there are pretty good examples too but rare. Swaminathan Seetharaman, Head of Technology at Cred, Jeyandran Venugopal, CTO of Flipkart, Sriram Iyer, VP Engineering of Flipkart are a few people I have had the pleasure to interact, work and observe their leadership styles closely. They are people who understand tech and people equally well. They have a calm, nice approach to help people recover from their mistakes and help them grow.
They contradict themselves
Always experiment. Experiments have turned out to be major product successes for us.
Ola Play, a service of watching our favorite videos on the move during an Ola ride, was born out of Labs as an experiment by Sriram Iyer’s team. Ola made a significant amount of money with Ola Play even if I look at my own rides. It was an experiment.
Not all experiments must have worked but when it does – it works really well. That is why it is called an experiment. In the space of testing which inherently means “experimenting” – our industry ironically wants everything standardized and little room for experimentation. This has hurt innovation and faster product success for many organizations.
Experimentation nurtured as a culture certainly gives such benefits as what Ola, Myntra, Flipkart and Zerodha has got. Many large enterprises and sadly some startups driven by ROI for every single penny won’t get to experience it.
Notice the contradiction though. Kailash Nadh also writes:
Consider technology costs as engineering challenges. Always optimise where possible and don’t spend what is not absolutely necessary.
You must be wondering how can an organization like Zerodha say “Spend only when necessary” and also say “always experiment”. We are taught that contradiction is bad. Actually, deep inside the contradiction is where powerful learning exists. Zerodha also recognizes that not every line of code they write is going to be ingenious and innovative and has a culture to accept that as a reality. This makes them see what should be innovated (and hence experimented) and what shouldn’t be.
Also being an active FOSS contributor and consumer, Zerodha have kept their experimentation specific to the industry they are in, thereby making more of those experiments yield higher value to their customers.
By opening their API’s for other start-ups to mushroom, they have let others experiment with what they have built.
Zerodha’s Design Principle Can Shock You
Good design is paramount. Building software for humans with no consideration for human interactions and sensibilities is criminal. Keep UIs and interactions simple, typography crisp, clutter minimal, and spacing calm. We keep iterating for as long as it takes to strike the right balance between “aesthetically pleasing” and “easily usable”.
Is this even possible? Repeat of their words, “We keep iterating for as long as it takes…”. Think about PayTM. Vijay Shekar Sharma himself talked about the clutter that exists in PayTM home screen and that is because people kept adding what was required to be added. I am not saying they did bad. Oh, please chuck your, “Is he saying that?” thought from your mind and read it the way I have written.
PayTM is everywhere and they did something remarkable for India. However, they ran too fast. Zerodha’s biggest advantage was they could run the speed they wanted to. So certain design success can only be achieved if you can iterate and you have the luxury of time. Each iteration was an experiment. It is worth their investment because as a user I really feel clutter free experience that is why I am happy with their platform and not looking to register with another stockbroking platform.
Simply put, it takes time to build a clutter free UI for a platform as complex as Zerodha. Organizations hire talent and give them targets too fast to chase. You can hire a cheetah and ask it to chase a high speed target. It will catch it but do you know how much rest a cheetah takes after every run? If you make the cheetah keep running fast without rest time, it will collapse. Runners know recovery is an important part of the run. The run isn’t over till the recovery has finished.
Many talented people fall into this trap. We are systematically being moved from “smart working” to “hard working”. Running once and catching a prey isn’t work for cheetahs. Doing it right after a catch is work. Doing it again and again is hard work. At some point the cheetah doesn’t want to be a cheetah anymore. Starts to look at money instead and migrates on to a new land that at least pays higher for the same hard work.
Zerodha knows how to work with talented people. Giving people time, while supporting them to be at the top of their game.
They just have 1 Test Engineer and they are nuts!
Kunal Shah, my favorite, start-up icon from India once (and also several times) posted, “Inefficiency is the largest employer in this world” and that is so true.
Testing is a culture of the whole team. Business + Product + Engineering + Support. Everyone needs to be involved in testing. Everyone is equally responsible for the culture.
I have been the lonely dedicated tester in small start-up teams like Zerodha and I wanted a different /test/ perspective and missed having a colleague. Pair testing is a powerful approach. If I was a tester there, I would pair test with business, design, product, developers and support teams. I also would love to pair with a tester. However, a culture like Zerodha isn’t going to make anyone feel lonely. An engineering culture like theirs is making everyone a QA and that is great. When they expand – they will need test facilitators and not the traditional testers.
I had a little chat with Kailash Nadh on Linkedin messages to find out that their unit testing culture is strong. I have been an advocate for unit testing from the moment I realized that the number of bugs can grow exponentially when good unit testing is not in place.
Their test engineer focuses on front end testing – writing tests for web and mobile apps. Maybe they can do a post on it. More than that they need to do a post on how they don’t break their tests with code change. They also need to write about how the whole team supports testability.
Build organic, meaningful relationships with non-tech teams within the organisation. We work with small non-tech teams within the organisation (subsets of support and finance) to critique and validate products, gather feedback and data, and to do QA from a finance perspective.
This is their trick. They bring everyone to do the QA. Not just the QA Team unlike many organizations. Non tech teams getting involved to do QA matters quite a lot. Plenty of organizations don’t get this.
Yet, how does Zerodha build quality apps?
Quality is everyone’s responsibility. Not just of those who are called Test Engineers or QA’s. That’s how Zerodha becomes yet another living testimony to achieving quality by making it everyone’s responsibility.
Be extremely particular about quality and consistency. That extra 50 KB of Javascript, or that 100 KB PNG on a web app, or that sudden 10ms spike in mean latency, are not acceptable. No matter how negligible the cost may be, it is a matter of principle of good engineering. It is okay to pause for a bit to do things the better way.
Are they kidding? For 100KB PNG they will pause and think? They seem to have descended from a different planet. On the planet they live in – they seem to find a way to not accumulate tech debt.
Technical decisions, even the ones with business implications, should be made by technical people. Otherwise, in comes the feature-creep, bloat, technical debt, and burnouts.
Just with the above statement – they ruled out many start-ups and enterprises on the planet called Earth. Business drives tech in most companies I know. Last minute feature creep and burnouts are a given.
People are proud of it these days. They even flaunt it on CV’s of “Testing a feature that came at the last minute and yet achieving great release by working all nights and all weekends and not living a life”. Zerodha wants these people to not pride themselves for building and testing a last minute creep.
Last minute features add plenty of regression bugs. If quality isn’t a concern that’s fine. People want a last minute feature creep and yet want quality and yet want no regression. That is not how quality can be built.
Many organizations don’t get this. Zerodha has spent time building quality and building for quality. They set their engineering and org culture to suit for quality to be built in. In most of the other organizations, people are already 10 sprints behind the roadmap (according to business) and the faster they try to catch up the more mistakes they make and the more mistakes they make the more people they need and the more people they need more mistakes happen.
- A team has to settle down.
- A team has to stay.
- A team has to become a family.
- Only then these things can be achieved.
- Many startups that don’t who are not like Zerodha resemble a railway station.
- People keep coming and going.
I have had the pleasure of seeing 5 management changes in 5 years in some start-ups. Everyone brings their vision, half implements something and goes away. They end up with poor quality, heavy tech debt, needing many QA Testers under a waterfall with a mission to catch all water that is trying to pass through and act as a dam (gatekeeping) and hence becoming a railway station where everyone is waiting for their train so that they could leave the place.
Zerodha is not a railway station
Zerodha is not a railway station. It is a village house. A family sticking together. With 30 people – it is achievable.
I think Kailash Nadh would have not been able to write the same post if they had been 50 because someone told me something about the team size and how culture changes when I started my company. I don’t even remember who.
They said, “When you are less than 10 – you are friends. When you are less than 20 – you are a joint family. When you are less than 30 you are a close bonded village. When you are less than 50 you are a crowd. When you are above 50 you are a mob”
Mobs can’t be run like village houses. Tech in Zerodha is being run as a mini org within and still can maintain the culture and achieve this.
Conclusion
One of the many things I have learnt in my life against the education I have had is – to not conclude. However, all conclusions are temporary and as new info emerges these conclusions also change.
Also, I wanted to go further deep to analyze every line in their blog post. It would make this post as good as good as a 25 page document. I guess I have made my key pointers from a test and culture perspective and I feel good enough.
As the title of this post says – can’t other startups and enterprises replicate the Zerodha model? No and Yes. Thankfully. The only way that many other startups can do what Zerodha has done is to re-organize their large teams to small villages. Let the village come up with their own ways of working bonding together.
I think given the time to bond together (not just work together) most teams will think and behave like Zerodha Tech Team. That is why I strongly believe Zerodha’s Tech is not a replicable model UNLESS we change the way we are running our show. Many startups kept talking about disruption. The true disruption was offered by Covid19 to this world. It has changed the way we think and work. Unless a disruption of that sort happens to the way we engineer – the world is going to be wowed by stories such as Zerodha without realising Zerodha engineering is how the normal should have been.
63To the people at Zerodha – your village is beautiful. Stay there.
