Learning from Engineering Org Growth at Flipkart and Rubrik

There are way too many startup events these days. And they’re mostly focused on the business of technology such as online retail, online education, SaaS and so on. What we don’t have is enough events on topics such as engineering management to help build organizations successfully.

And we got an inkling of this gap when we got 4x the number of registrations we thought we would get for our Lightspeed Knowledge Series event in Bangalore last week. We brought together CTOs and VPs of Engineering exclusively to discuss and learn about building and scaling engineering organizations. The goal was to provide (hopefully) actionable takeaways on hiring, scaling and culture.

Amod Malviya and Ashish Gupta have scaled engineering orgs from zero to several hundreds. Amod is founder at Lightspeed-backed Udaan and was CTO at Flipkart from 2010 to 2015 — he grew the engineering org from near-zero to about 1100 engineers. Ashish is VP Engineering at Lightspeed-backed Rubrik and was formerly VP Engineering at Flipkart from 2012 to 2017 when the engineering team went to about 1200–1300 engineers.

What struck me during the talk was that engineering management is not some monolithic one-size-fits-all approach. Successful management includes actively managing a volatile mix of talent, processes and systems. And a healthy dose of experience is required to scale an engineering organization while avoiding common mistakes.

I’ve written down some of the takeaways below and taken the liberty of including some notes that Amod, Ashish and I had put together in the our preparation for the talk.

• A high-quality problem should help the company scale infinitely by reducing dependence on manual work and should be exciting to top-class engineers to solve.
• An example would be pricing and inventory planning at an ecommerce company. In this context, a regular solution would include a workflow system that transfers tasks from one person to another. Decisions are still being taken by humans. A high quality solution could include an intelligent, horizontally scalable system which does a lot of pre-compute in making a pricing decision with higher-level inputs such as business goals.
• Start with a high quality problem and use it to attract high quality talent. There is then a virtuous cycle that develops between the problem and the talent. If it is not a high quality problem, then understand that and fit the caliber of engineers to the type of problem.

• Don’t avoid going to non-IITs. Spend time on these non-IIT campuses getting to know people and you’ll always find great people.
• The first 25 employees came through founders’ own network of friends and certain colleges where they kept a tab on smarts kids on campus (not necessarily the most academically brilliant ones).
• Keep your eyes open for professionals and students who contribute regularly to open source projects e.g. on Github — track the number of contributions andquality of contributions. Also look at new age platforms like Interviewhub and Udacity.
• Leverage Quora: You can keep track of good contributors on Quora. You can also write on Quora — here is a question that somebody asked about Flipkart’s hiring practices and culture — this got a lot of developers to come to Flipkart.
• Failed founders or early employees at failed startups are great employees, especially early on in a company.

• Look for combination of battery, storage and compute in your candidates.
• For freshers, look for battery. Focus on hunger and attitude rather than purely on skill.
• For engineering managers: look for people persons, not for technical skillsets.

• You build credibility by being hands-on in the first 12 months which also helps build rapport with the team.
• Once you hit 25 direct reports, you reach a breaking point. That’s when you bring in an additional layer as an engineering manager or project manager.
• Be mindful of the Dunbar number of 150. People can comfortably have that many relationships. Beyond that, there is a breaking point in any organization.
• Try and promote from within.
• Break down each problem area further and further as you grow. Assign engineering leaders to these broken-down problem areas.

• There is a cultural issue at engineering orgs in India — people are assigned to a product (e.g. landing page) rather than assigned outcomes (e.g. growth, engagement, conversion) and so lots of stuff gets lost in translation. This leads to people being assigned to product workstreams and hence inflated number of engineers.
• Having tons of parallel workstreams is a problem. When you have 100 workstreams, you need 100 engineers and then managers on top. This does notwork for product orgs and results in linear scaling of engineers with revenue.
• Put product, business and engineering in a similar org, otherwise easy for everybody (esp on business side) to throw out tons of business ideas and results in a ton of backlog in the org and over-hiring of people. Setting up culture of engineering org as being a services supplier to business is a very bad idea.

• If there are engineers who want to join to focus only on cool, bleeding-edge technologies (i.e. AI/ML etc.) either don’t hire them or talk to them about the real world problems you are solving and see if they get passionate about that and buy into that vision. Hiring somebody just to work on specialized technology areas ends up with a bad fit with most organizations. Also results in force-fitting tech into solution.
• Think problem first. Don’t worry about the technology to solve it. It is risky to be bound to a single tech (Java>J2EE>SQL>big data>ML>AI) — the shelf life is getting shorter and shorter and engineering capability is getting more democratized.
• Advanced Technology Groups (ATGs) or R&D teams need to be set up when its right for the business. ATG is needed much sooner if you’re finding new antibiotics versus if you’re build a food delivery app.

• Question the why part of the problem you are solving with engineers. Unless engineers know that well, it is difficult to have a motivated engineering team in the long run.
• Engineers join an org based on how challenging the work is and if they have ownership of the work.
• Let engineers make decisions. Most organizations don’t allow this — most are heavily top down. When engineers make real decisions on technology choices, they have a much steeper learning curve and become much more than individual contributors.
• An example of this is Qubole in India where 90% of the engineering staff is in India even though it is a US based startup. Many of the product decisions get made here in India. This attracts a high quality level of talent.