How we learnt to ship 3X faster:5 lessons from the Helpchat experience

Posted on

As the CTO of Helpchat India, I am responsible for making sure that our product ships on time, again and again. Running a 80+ member tech team requires a very different kind of skill set than running a 30 people team. Over the last few months, as we grew faster, it became more and more important for us to design our culture in such a way that it enabled us to ship faster.

In tech businesses, execution is (almost) everything.

Background

Before I jump into what we did, here’s a quick background of why it was necessary for us to go deep and solve this as a problem. The average Indian user is fed up of installing apps and our app helps him save over 600 MB space and about 100 MB of data usage by providing a lot of functionality within one app. And from our research, it is obvious that the average user in India is very conscious about space and data consumption. Here is what the main screen in the app looks like:

If you look at each tile there, there are companies which have spent months building out the experiences in each of those tiles alone. The difference for us is that we do API integrations with different players and don’t have the challenge building the vertical business itself. Our challenge is to build UI/UX which matches the underlying services and add a layer of personalization. Along the way we know that we’ll make mistakes, have to do a ton of experiments and basically improve across so many different categories at a phenomenal pace. All the time also building infrastructure that scales. It’s easier said than done.

To understand the best way to accomplish our goal of becoming “the fastest tech company in India”, we spoke to over 30 different companies of all sizes (the biggest was a 400+ people engineering team, $2B market cap and the smallest was a 25 people engineering team) in India, Silicon Valley, and China. The goal was to understand what were the best practices and then try and apply them to our situation.

Choosing speed over accuracy or reliability or any other goals was a very conscious choice – speed is of the essence in an internet business.

Here are the 5 things that we did:

 

1. Small is powerful: One of the most impactful changes we made was to split our tech team into smaller teams of 5-6 people (3-4 devs, 1 QA, 1 designer) from earlier team sizes of 10-12 people. I would love to break them down into even smaller teams but it’ll take time. Every product manager and category manager sits with their respective pods.

Pros are that every engineer can truly see the impact of what they do and that is the most intrinsically motivating factor. It also helped us to do the rest of the things better (more on that later). The pod lead can even be a young guy of 2-3 years experience who takes the initiative; the “management” overhead is low when his team is just 4-5 people.

Along with the pods, we formed a central dev-ops team and a central infrastructure team (which looks at things like payments, notifications, email infra layers).

While a lot of teams follow a structure like above, we saw that things change when we start breaking down the pods further. Now there’s a 5-6 people team building each of those tiles you see.

 

2. Design sprint between sprints: We loosely follow the agile methodology (no one methodology works perfectly according to me). One of the constant complaints was of bugs, technical debt accumulating too frequently and delays in launching. When we went deeper into these issues, we realised that the key reason is that dev start coding as soon as they get the product spec instead of thinking deeply about how it should be technically designed and coded. And the crushing schedule of 14 day sprints wasn’t helping – a delayed launch would cause too many frayed nerves all around and at the beginning of every sprint, instead of spending time thinking, devs were fire fighting. Another psychological reason was that most devs intuitively feel that meetings are a waste of time and any time spent away from their MacBook was a waste of time. We needed to institutionally support design thinking before any sprint.

We decided to introduce a 3-day mini sprint between two 14-day sprints and ensured that all pod leads and their teams sit in conference rooms and think deeply about how to architect and code the requirements given in the product spec. Once this level of thought goes into things before even writing the first line of code, the whole process becomes a lot faster and stress-free. It also leads to reduction in bugs, technical debts and unexpected delays in launching.

 

3. Product team can make a huge difference: Given the fact that we have a lot of things to build (though honestly every tech company co-founders feel the same), having a streamlined product process which optimises for speed is super important as well. Every experimentation; for example, in a lot of places we are now choosing a WebUI instead of choosing native Android. This helps us run experiments very quickly and the product team has learnt to take advantage of this trade-off. Only when the product feature/UI/UX is mature do we code it in native Android. Another important point that we learnt is that in truly engg driven companies, the ratio of PM:Devs is as high as 1:12 (and devs here doesn’t include QAs). When we first calculated, our PM:Devs ratio was 1:5. Having so many PMs for each developer almost structurally disables the devs from applying their minds and thinking about the product deeply. Over time, we’ll work to keep moving this ratio towards 1:10 (it’s already at 1:7 now).

 

4. Business perspective: As founders/senior managers it is difficult to sometimes grasp the difference in level of business perspective that we have and how that impacts our actions, prioritization and how much we also learn along the way. While we’d like the ideal that we build dashboards and get every dev to have a look at it, that hardly works in truth. In addition, business perspective is very different from business metrics (the former is a lot broader).

I have seen that the Socractic method of asking engineers questions about business works very well (“What do you think would the CTR if you do this?”; “What % of our users do you think do X”; “What would be the lost revenue because of this additional screen?”). The look of clarity dawning on people’s faces when they realize the business impact of their work is priceless and it switches on a button in their minds (which we hope will continue).

In addition, we have gamified the process – we’ve created a competition where 2 pods would work closely with each co-founder at Helpchat and think through business aspects of their category in depth. Each co-founder’s pods will compete with each other to answer ANY business question thrown at them.

 

5. Training and introspection: Building the fastest tech company in India is a founder-level challenge in the sense that there needs to be total conviction from all the co-founders that this is goal is important for us to win. As Andy Grove puts it in High Output Management, you can either train people or you can motivate them (there’s literally nothing else that managers need to do). While small pods take care of intrinsic motivation, training is what is left – and training has to be done by me as my role of CTO, Ankur as his role as Helpchat CEO and Avinash as CPO. Unless we do it, nothing else matters.

We’ve designed the training process in the following way:

Introspection session: Every fortnight, at the end of each sprint, we sit down for 4 hours – each pod lead, product manager and the co-founders and we just talk about what fuckups we made in the last 14 days. Each of us. And we force everyone to use “I fucked up at….”. It’s not “we” or “us”. It’s an individual introspecting and then openly acknowledging what he could have done better and also what 2-3 areas they will focus on improving. It’s the most high-leverage meeting because you understand what people are thinking, how they are self-actualizing and what is holding them back. We leave the meetings with 40-50 actionables and over the next sprint we find different ways of accomplishing it. It’s not perfect the first time you do it and but after 2-3 times, people get a hang of it.

Tech open houses: While Ankur does the all-hands meet with the whole company every month, I do the tech open house every three weeks and we end up covering a lot of stuff about why, what and how we are doing things. A lot of my time is spent on telling people things which intelligent people find counter-intuitive (e.g. if your code is perfect, it means you waited too long).

Management training sessions: As you break the tech teams into pods, a lot of young people become responsible for other people’s outputs for the first time. This can be more frightening than most of us might realise. To help people make this switch, Ankur takes the following training session: managing the Helpchat way, doing skip levels, doing a ref check and doing 1-on-1s with your teams.

 

6. Bonus lesson – Build tech to ship faster: We also got the dev-ops, QA head and central infra team to specifically find out about and implement tools/techniques/practices which could help us ship code faster and with more consistency. We recently implemented “Docker Swarm” cluster for our staging environment (25 boxes) with the help of the central infra team and suddenly every dev is able to save at-least 10% of his time because of streamlined staging deployment and environment. Another benefit is that the infrastructure resource utilization is better, which means more savings for the company.

Other optimizations include tooling for code quality checks using SonarQube, automated regression tests at the time of launch using Jenkins, running the code through profiler to weed out low hanging optimizations, DB level slow query logging and automated reporting to the dev in case any threshold is crossed, etc. While it feels like you are slowing down in the short run, in the long run, it helps you run faster.

Conclusion

A lot of the stuff mentioned above is still being tweaked, improved and changed. We’ll keep doing what works and discard whatever loses it’s utility. But this has been one of the most exciting things to go after – building the fastest tech company in India. Wish us luck!

PS: Big heartfelt thanks to all the founders/CTOs/PMs who sat down with Ankur, Avinash or me and openly shared their best practices and taught us (Naveen Tiwari, Deepinder Goyal, Shashank ND, Abhinav Lal, Punit Soni, Niket Desai, Girish Redekar, Sriharsha Majety, Ankur Warikoo among others). It was another eye-opening learning – we say that Indian founders don’t help each other enough. Well, you just have to ask! I’m available on vishal@helpchat.in in case anyone wants to reach out – it’s our turn to pay it forward. 🙂

One thought on “How we learnt to ship 3X faster:5 lessons from the Helpchat experience

Leave a Reply

Your email address will not be published. Required fields are marked *