The medium of expression matters
Indian tech teams are ~10X bigger than their Valley counterparts. Why?
In my experience most Indian startup teams instinctively treat technology as the means to an end rather than a medium of expression. This blinds them to the (often deeply counterintuitive) nuances of the medium.
Imagine if, instead of Michaelangelo, someone who treated painting as a means to an end had been commissioned to paint something as technically challenging as the ceiling of the Sistine Chapel. Someone with no interest in understanding the properties and interactions of paints, lighting and the viewer.
Clearly a bad idea.
Yet, we’re comfortable doing the same with software, a medium that exists purely in the mind of the programmer and that is known to be incredibly hard to work with. Worse, you can’t meaningfully “look” at a piece of software and evaluate it; only it’s effects are visible. To cap it all, the entropy of any software system increases at an exponential rate as changes are made.
Software rots insanely fast when changed.
There’s a good reason software projects have a 60–80% failure rate, industry wide.
Like all systems, software development follows certain rules, analogous, say, to the rules of economics. Like, “printing money causes inflation.” These rules often stand in the way of changing the code, especially the rapid change that fast growing startups codebases experience.
An example of such a software development rule is “adding manpower to a late software project makes it later.” This counterintuitive ‘iron rule’ of building software is the topic of Fred Brooks seminal work, “The Mythical Man-Month.”
This is the advantage that startups with (competent) technical founders and/or leadership possess: An instinctive understanding of the counterintuitive nature of these hard problems of scaling technology. The ability to anticipate them. And the willingness to work at solving them.
The hard problems of technology
There is a set of hard technology problems that every successful software startup has to solve over and over, at each order of magnitude of scale.
As someone once told me, “everything changes with every additional zero.”
While it’s possible to learn from other startups’ experiences, each startup’s solution is ultimately unique, a product of the business, the founders, the board, local and global political conditions, the rate of growth, current scale and a dozen other factors.
Let’s list a few of these hard problems:
- Sustainably scaling software is a hard problem.
- Maintaining productivity while adding people is a hard problem.
- Prioritization is a hard problem.
- Parallelism is a hard problem, both in code and product execution.
- Meaningful estimation is a hard problem.
- Rapid iteration is a hard problem.
- Figuring out what to build is a hard problem.
- Defining scope is a hard problem.
- Managing scope is a hard problem.
- Being responsive to users of our software is a hard problem.
- Uptime is a hard problem.
- Finding good developers is a hard problem.
I could go on, but you get the drift.
These problems or constraints lay out the nuanced tradeoffs inherent in the medium. Lots of books get written about making these tradeoffs, too.
Ignoring the nuances of the medium means all sorts of risks compound, as medium and long term decisions start failing.
Most decisions then become tactical, which creates a negative feedback loop. Immediate outcomes start to drive decisions while actual costs of execution remain hidden, and accrue as technical and organizational debt, impacting future outcomes in deeply unpredictable ways.
Now combine this unpredictability with rapid growth and scaling software becomes truly hard.
Scaling engineering
In its first 18 months, GO-JEK’s business grew over 900X, from unknown startup to Indonesia’s first Unicorn.
Total engineering headcount: ~80.
In business terms, my employer, GO-JEK, is the Indonesian equivalent of Indian startups Swiggy, Zomato, Ola, PayTM, UrbanClap, BookMyShow, Dunzo and a few more, all in one app, and with comparable completed order volumes.
That’s the equivalent of at least three Indian Unicorn scale startups, plus half a dozen more Series A/B/C scale startups, all contributing to exponential rates of week-on-week growth.
Currently, GO-JEK handles this scale with a team of just under 150 engineers, across three locations.
Why don’t we have a much larger team? Why do we process 3000+ resumes per offer?
The first lever for scale
Engineering needs to scale? Hire.
Sound advice.
Good, strong hiring is a critical part of scaling technology. But when it’s used unilaterally without addressing all the other hard problems in a balanced manner, technology goes from ally to an enemy.
In India, where there’s a serious signal/noise problem in recruiting — we produce 1.5M engineers a year — hiring as a silver bullet to scaling problems can go bad, quickly. It’s incredibly hard to find a capable engineer, so startups hire two or three average ones. Those go on to hire more average engineers, until the scale of the system starts to exceed their collective capability and everyone hates their jobs.
Yet, all too often, Indian startups have headcount as the only answer to scale.
The worst outcome is a startup where technology is hated, and deploying technology is an unpleasant option, grudgingly adopted. Execution involves a massively bloated, demoralized team of largely inexperienced engineers working obscene hours.
Large amounts of buggy code are churned out daily. Most code written never reaches production. Bugs do, aplenty. This is socially acceptable.
Stress levels are always high, and a lack of work/life balance is celebrated. Working weekends becomes the norm rather than a smell that execution is horribly broken. No delivery commitments are met, and estimates are a joke.
We all know startups going through such a phase.
It’s hard, not impossible
I think the biggest reason this happens is because there’s a misconception that building a world class, professional, engineering organization in India is impossible. That scaling technology almost exclusively means adding headcount, as that’s the only lever that works in India.
That’s just not true.
Building a top notch engineering team of passionate developers, collaboratively building beautiful software products with international standards of technology is very much possible in India.
It’s not easy, certainly. But not impossible.
Let’s stop talking admiringly about Instagram’s 6 engineers and WhatsApp’s 35 (at the time of acquisition) as though those levels of leanness are impossible to replicate.
There are many Indian startups successfully making a serious investment into building top notch engineering capabilities. Not the majority, by far, but enough to prove the point.
