6 month mark at Shunya & what we have built

Ekta Grover
December 16, 2020
10 minutes

Over last 2 months, I got a few texts -"You wrote about the 30, 60 and 90 day journey, what after that?" So much happened after the first 90 days, almost like being thrown off the 16th floor and somehow landing up straight!  These last 3 months in particular have been rewarding. Entrepreneurship is much like that. 

This post is a fast forward version of behind the scenes account of journey. Hope there will be a lot of lessons you can learn, too. Would love to hear your comments. Write back to us at hello@shunya.online.

Our first MVP launch 

We started building the product early June, with the target MVP launch in mid August. Even though we had spoken to 60+ teachers PAN India, I still did not have the confidence that the product narrative would fly, so I felt the least overall risky decision was to engage with freelancers. The hardest part for any entrepreneur is to convince themselves of the real need vs articulated need and the timing , which is an interplay of market dynamics. 

We started building the product with 2 freelancers, one on Android and Backend side each. The best decision was sourcing the freelancers from strong referrals, which meant we could extend the leap of faith - and have hard conversations, and productive design discussions. This also made sure we did not have to petty time sheet management, which can be heartburn dealing with such engagements, and budgetary overflows. 

By end of July, though the contract was still for “scope of work”,I realised that we were way far out, and we had all underestimated the effort. This, along with fairness and reciprocity forced me to rethink if we should be building an in house team sooner. Along the way, I was also talking to a lot of mentors, prospective customers, Investors and Angels to get a view of our positioning, developing the product and market. This signalled that now was the time to beef up the engineering team. We hired our first FTE third week of July. This still gave us time to ramp him up, while the freelancing team could slowly fade away.

We shipped a solid MVP on Oct 5th, and looking back there were many shortcuts we could have taken to accelerate the public launch, but most of them would have been shortsighted local minima decisions. For us, I strongly felt that extra time investment was needed. 

Building a solid team in house 

The best decision was to not add all the Engineering team(or even other functions) at the same time. We kept sourcing profiles, but hired only when it became clear what the current competencies and gaps in the team were. With every hire, we tried to add different life experiences, orthogonal thinking, while having core Tech skills overlap. Cultural fit was the overarching trump card(More on this later)

At first, it was only 1 each on Android and Backend, and gradually we an entire team over 3 months. Subsequently, we kept raising the bar. We did 3/4 interviews and depending on the publicly available tech footprint of the person, we pre-screened by take home assignments or by their previous work as the leading discussion. Also having realistic, but monotonically increasing expectations on the ramp up made sure we took folks through an increasingly level of complexity.  

More on how we are perfecting the Engineering processes and scaling the team here

On building a brand & perfecting our hiring process 

We realised that since we were not a “brand” yet - there was only thing we could do. 

Invest in people and create a pull for the external world, by their own growth. By focussing on giving them the most amazing ramp up experiences to the point there was disbelief about the kind of things they were doing as freshers. While screening for cultural fit, growth mindset,  strong learnability, consistency & strong self directed learning - I learnt to pick very subtle cues on maturity of the prospective candidates. We also let them talk to 2 Engineers in the team- so they would know what they were getting into. 

We choose to not oversell the job, and let them come at their own decision points whether Shunya was right for them and whether they could see a very different version of themselves in the process. Often this was also a mix of their Financial responsibilities. In fact, we choose to defer engaging with some very promising candidates because I felt that it would put them in undue pressure to subconsciously look at “funding” as an event, for the pay cut they were willing to forgo for participating in Shunya’s dream and the bullish vision of the alternative future it is trying to create.  

As opposed to other startups that oversell, and create an urgency (more like being a Gunpoint), we spoke as equals. We sent proposals and then we spoke and close. Overtime, we build an autopilot of screening processes that helped us focus on the most promising candidatures.

The most important criteria from all this was “You have to WANT the job!” and the WANT was an axis of ambition and not desperation. In fact we weeded many profiles where the core motivation was “Experience letter”.

Every month, we run anonymous surveys as a team, to identify areas of their own growth and our collective growth & progress as a team. 

And here’s what emerged from those. More than affirmation, it was a belief that we were doing something right, to build our People and cultivating the excellence for ones’ work. 

On building the culture 

Culture is not soft thing - it is the very reason we exist. It's a self-protective organism and is always looking for feedback around itself, and then just leans into - basis the risk-reward equation. -- Steven Slap

Growing up professionally, I was very influenced by a blend of four cultures - Netflix on building a pro-team, freedom with responsibility, Amazon on customer(user) centricity, Apple on great design & that Engineering is more of an art than design and InMobi, to lead with Authenticity & soulfulness. 

In many ways, those lessons seeped in the ways, we took decisions. On things we spoke about. And that, what you as a leader ignore speaks equally loud as the things you endorse. In that ignoring the hard conversations head on is even louder endorsement - that can erode the culture. 

I often say that we are not a sugar water company and that has helped us have many hard conversations. What amazes me is how the team takes it all in the stride and keeps upping how they co-build things together. Every sprint, is better than the previous one, with more purpose and enthusiasm for the journey we need to take, together. 

I often say that a good coach should not be likeable, but one that can push you into the future self. We stay true to that purpose and we are blessed to have people who see their future self in themselves. 

Demo time - Fire up the horses!!

Building virtual first teams is SUPER hard. And by that I mean TEAM = Entity working singularly towards one goal, so clear that they can recall it when woken middle of night. Anyone who tells you, its not, is either lying, or doesn't know the difference between getting work done & building a Team.

Let alone build them when its a fully fresh and one of the things that kept us all focussed on the launch - was the Demo’s we did. When we moved closer to the launch, we released multiple APK’s that we all tested, then met as a team and tracked down all bugs.  Over time, folks started to see demo's a collective sport and this also helped us build user centricity and a culture of joint ownership.

Looking back, just in August, we had so many of null pointer exceptions and app crashes, that I personally found it challenging about how we would lead the team. It was a very vulnerable phase as a company, and that was when I activated the InMobi & Bloomreach Mafia - to help me focus on the right things. I soaked myself in Engineering design, better planning, through negative scenarios, visual communication (Remember we are still virtual!!) and then injected the best of all this accelerated journey to the team. Even now, after every release we do collective retrospectives, take a pause as a team to reflect on what we could do different to build Software better. 

It’s often too easy to go with a “feature by feature” , as opposed to looking at cluster of patterns and then applying those patterns to better engineering. Having the patience to allow for delayed gratification that often comes from the pain of having looked at the forest, than individual trees.  

My 2 cents - If you want to do anything meaningful, do not be afraid to put your real self out in the world. It's easier being consistent & authentic. We need it more than ever in a world that's moving a neck-breaking pace and being disrupted.

Increasing quality of our micro decisions as a team

I realised that our collective outcomes will be a least common denominators of the actions we as a team would make without me. This was also very important - and here a bit of letting people come to their own conclusions came handy.

Few practical anecdotes. The app had images that would be shared between teachers and students. When selecting the image, it did not show the “thumbnail” of that which was selected. Since our phone is the most personal thing as a user, I let an Engineer run the demo from his phone, projecting over zoom. 

When selecting images, he realised (as a user) that he definitely did not want to attach “personal” images unintentionally. Case was made. And the team made the changes it had to. 

Likewise, the images that we captured were very low quality from the Android library we were using. On decreasing the compression ratio, high bandwidth was the tradeoff for high clarity. We researched a bit of external libraries, the What’sapp compression methods (Its the gold standard on this) and through trial and error, we were able to get the best of both worlds. The best and most intuitive decision was to make a small standalone app to test just this experimental feature on hand. 

It had two benefits - It broke the problem into byte sized unit that could be easily tracked and  it increased the confidence of the engineer,  and motivated him to narrow the focus.

It built a culture of testing, hypothesis and experimentation. Now when we make tech choices eg - designing a chat functionality via sockets, we truly build things very lean. The art of the game is to spend time in designing, than directly jumping on code. A lot of companies, do not get this process right in the beginning, and it makes the reviews even more harder, and bugs more difficult to track. 

We had countless such examples, where the team the runway and autonomy, so long as we were aligned on the principles. This gave the team their own maturity. So, assuming I was with them debugging, handholding 

Change the Engineering problem to be a real user's problem

There were many occasions, most notable of which was a Dynamic link feature we were developing. The issue was, with patchy internet, it came in the way of onboarding. We tried a few things, moving the preloading to a different part in the app , so the end user experience would look less jarring. Except that it was not consistent.  

That’s when an external perspective of ex-colleagues mafia as the support systems come handy. We redid the entire feature in less than 3 hours, changing it from Client/Frontend construct to Client-Server architecture. Knowing when to ask discriminating  

Brand communication, positioning et al

I often say that writing is thinking. And often as an entrepreneur living your dream - talking to a lot of people will help clarify your own thoughts to you, to get perspective on things that matter. 

Its all about details, simplicity, and comprehension for whom that messaging is meant. We are still miles away from communicating our place in the world, and the alternative reality we want to co-build. 

Here are the few videos we have produced, so far. A full blown post on how we are getting better at this, after we have exceeded our own expectations!!

Looking at Ads!

Over the last 1 month, as a team, we started to looking at ads & what connects. This was personally a very enlightening moment. Having spent a good deal of my time in AdTech, I had NEVER looked at ads, beyond the Data science aspect of it. Here is the CTA, here is the text, color tones etc. It was more of an art, putting yourself in the shoes of the user and asking yourself, wil this intrigue me to take an action ?

This simple question, helped us establish - what we now call our Marketing playbook - and we tried to infuse and course correct this in every touch points. Those little details on typography, the amount of whitespaces, the CTA, the iconography. This takes time to first develop a POV and then coach the team to build on top of it. 

Looking back, a few things came handy. For example - the trips to Italy, I took back in grad School in 2011 and ended up spending 10 days, more like a crash course in Art. By the end of the vacation, I had spent so much time looking at renaissance art, in Florence, Rome and that I just wanted to spend the last day in Venice - not thinking anything. This absorbing ourselves in bursts of “activated context” , with a period of reflection and pause, both on technical and open ended strategic problems is something I find liberating. It helps you become a strong generalist and accelerate your learning in new contexts. 

This personally, reinforced to me that all life experiences come together. the exact same kind of distinctive learning we are trying to power with Shunya.

Chai pe Charcha 

We have these bi-weekly catch ups, where we meet as a team. Rest is self explanatory :)

Phase 2++

Growth Hacking, Rapid experimentation & PMF 

There are 4 tracks that we are exploring on finding our fit at scale. More about it, at the 9th month mark !