Building insanely great Engineering teams

Ekta Grover
Founder
November 10, 2020
5 minutes
Read


One day, while in my 3rd grade, after a craft class, there were bits of paper around all our desks. The teacher who had to teach the next class refused to teach us, till we cleared all the mess from our desks. Naturally then, the kids huddled and threw the paper and other trash near the dustbin. 

Except that there was ONE problem. Most of the trash was around the dustbin - not in it. Technically, our “own” desks were clean, and I don’t know what came to me, but I noticed it (still a 3rd grader), and picked up the trash near the dustbin back into it. The teacher noticed it, and like any great teacher she remarked my thoughtfulness(..and, applause followed). And that was the loudest lesson I learnt about clinical precision and attention to details and about leading without a title and through your consistent actions. 


Great engineering is pretty much the same. So, as I reflect the team we have built at Shunya and what makes me proud of the calisthenics we have done, for a young company fully born & bred in COVID, working insanely virtually with colleagues we didn't even know before - I thought of putting my lessons here. 



Build a strong culture of collective accountability, ownership & trust 

This is so obvious and overstated and yet most leaders only do lip service to the true meaning of it. It was so important at Shunya, that I would often get visibly upset when we hear “frontend is fixed, backend needs to… (or vice versa)” - there was no Frontend and Backend separations.  

No containers. We built a team of full stack thinkers, hustlers and there was only ONE team that was building a solid user centric product. Most leaders I know are shy enough, like we are running “virtual likability” contests, or want to have a notion of balance and control. Balance and control is not about holding your emotions, it is about resolving them to what you your own value systems are. And the value systems are unapologetically yours. What feels right for one culture and it’s shared purpose, may not feel right, even artificial for others.


Efforts != Outcomes. And the team as ONE entity is the unit that makes it possible.



Let your principles be known - so that the team can scale without you 


For us these principles were human centric design, code stability irrespective of the ecosystem entropy(within bounds). and building for mental models, than mere "functional correctness". So, instead of just saying “Move this element bottom right, or make it bold” - we would tell the “why” behind it. For example, when working with a UI/UX designer - who remarked “This is according to Google Material guidelines..” - my response was “Our users won’t know and don’t care about Google’s material guidelines. Likewise , when we would hear the classical “.. But it works on my Phone” - I would remark “Our users will have different phone than ours”. It can often feel draining to a leader repeating the same thing, but if you care enough and are consistent, the team will get it. 



If it matters, do not lower the bar “just this one time”  

This happened to us on a lot of occasions. Our live release technically could have gone a month earlier, had I not insisted on the things that mattered for for users. Whose lives we were trying to simplify. 


Fact is, in a cluttered marketplace, your users have alternatives to get the job done that they did not have before. So, your shiny little tool is nothing more. Getting the job done. Delight comes from the precision of it.  With all the products vying for same attention span, the definition of the craft of MVP has changed. It was not just about some random benchmark of attention to details, but about stability, alignment to the mental models, and virtually keeping the user journeys at the heart of everything we do. 

When 95% becomes a bar, it’s only a downward spiral from there. It’s easy to stick to something ~100% of time, than it is for 95% of the time. 


Teach your team about delayed gratification 

Most of the marketplace operates with 20 ft diggers. Build with hustle and moves on. As a result of which the experience is just 1 year of experience repeated 5 times, and not a 5 years of true experience.


We also tried to closely mimic our hiring for the same. We hired folks, who had stuck their guns to perfecting the craft, rather than moving from one toy project( or Github repo)  to another. We screened for depth, and a humility to know the bounds of their own self and an insane willingness to over invest in themselves.  


Explain your culture(as humanly & understandably) and your expectations

Culture is that unsaid rules that shape the company. And it is incredibly hard to do it in a virtual first setup. Culture is not about some rules that we post in slides, though the words help the founding team remember what brought them to start this in the first place. At Shunya, we often distill our culture in our conversations - like being entrepreneurial means that you think boundlessly and not in terms of circular dependencies, or constraints.

For us being entrepreneurial means, bringing the bad/ugly news is more important than hiding in the closet. It means that we value a mindset of collective problem solving and also accepting our limitations. We always say at Shunya - that which is your very best, do three notches above that.


That it’s ok to miss deadlines, and think long term, instead of taking short cuts to just make it. What collective success means in practice ..and so on. 


Give HARD feedback, and give it often . 


Don’t wait for a big bulk release of pent up feedback. Feedback is about problem solving and not a punitive measure. It's about growth mindset.

Eg - Since we were moving so fast, we often used to have errors due to wrongly merged big blocks of code. Since code stability was important - I wrote back to the team very late night to come back with a plan. By early morning, not only did they do the retrospective , but also rightly pointed that we had not invested in a test suite. We were so busy building during the day, that we hardly got the time to test, so App’s functional stability was an alarming issues and a time drain. So, we prioritised that.

 As a leader, you also have to listen to the recommendations of your team. Not just to make them feel heard, but also show that in your actions when they need help. 



Hire & build for complementary orthogonal skills and build the best Zero to One Onboarding  experience 


For us this meant that we took all of our people through the first assignment, where they had to jump in the complexity of the code. Example: For a few of our folks the first (real) assignments were writing an involved script to delete data of our 1NF DB  - which meant they had to understand the entire data model ; to build a bug bounty and break the app;  a full scale load testing on the pilot box that meant they had to understand how our API’s worked - which first meant that they had to setup a tool(like Swagger) - to see the documentation. 


This helped us solve for many birds with a stone. First - the ramp up tasks were real & meaningful. They were not like some artificial things to fill time. Second - they were great to instil confidence, while being a great mix of stretching and making folks aware of their own limitations, so they could plan the ramp up. Third - it trained the team to see both the forest, AND the trees. 


At first, it feels like a drain, it will slow you down, but that investment in people, pays off - both motivationally and by the magnitude of the contributions, collectively.   


Great Engineering excellence means great processes


In startup, things can drop, because there are no horizontal roles to catch things. Which is great because the information reaches you directly, unfiltered and you are best equipped to handle it. I often say, that people closer to the problem are more equipped to handle it, so we would have folks bring alternatives and own the problem - because without owning the problem, how would they even own the solution ? There are tons of examples of processes that we invented along the way - like how we would do & run design docs, document the bugs, those little interdependent things. 


Processes does not mean writing documentations. It means a shared vocabulary for effectiveness and productivity. For us this meant, asking simple questions - why do we have repeated patterns of bugs, how can we test the app more reliably, how can we have more work life balance, how can we prevent big bulk git merges to avoid red eyes phenomenon and gleaning over them.. etc.


Isolate, debug, and Hire for problem solving  - build a culture of retrospective. Reduce the entropy overall. Have the team come back with patterns/clusters of the mistakes we are making as group and orchestrate a retrospective. Jump on debugging and show them how. This will build a great team that can run without you. 


 People are not great because of you. People are great, because you have enabled them to work best WITH each other. 


Give the credits back when it’s due. And show what greatness feels like. Lastly know your own limitations , admit them, be a strong generalist, learn from your professional support systems and never shy away from putting yourself out there. For us, this meant that we had to keep asking for help from the InMobi and Bloomreach family that I had been part of. And looking back, we couldn’t have done, what we did, if it was not for these support systems. 



Bleed together through the pain of becoming. We are building the future of Education. Come, co-build it with us !