Why organically growing teams is the best way to build a successful business


Running a tech company is hard. Running a growing tech company is even harder. You’re simultaneously managing all aspects of the company — growth, financial reporting, team management, sales/customer support AND product development.

We run a tight operation at Semantics3. Our entire API platform (all 10 billion offers and 75 million uniques) is (by design), run by a kick-ass team of five core engineers.

MUCH better than Tom Cruise’s team!

This motley crew keeps a complex suite of data pipelines constantly buzzing, ferrying data to a growing ecosystem of Ecommerce start-ups, big box retailers, analytics companies and consulting firms.

Working together can be intense — when we’re not supporting our customers through their integration and launch processes, we’re constantly brainstorming for new features and products.

As the business team lead here, I have a driver’s seat view of the landslide of feature requests, product development and deal-flow support that these guys have to cope with. It’s a tough job, and I often wonder how it is that our relatively small team can be so productive?

Panic does not help (c) Fox

Well, we do have an eclectic team with our Chief Architect being a Computational Geometry expert and our lead API engineer holding a world Chess federation ranking. Obviously everyone is incredibly smart as well, with most having graduated from top universities in Singapore and India.

We’re a multitalented lot

But that doesn’t quite explain the productivity — lots of companies have capable teams, but not all work out well.

I came across a fascinating TED talk by Margaret Heffernan this week, which spoke about the importance of social capital in teams:

In a fascinating study of collective intelligence, Thomas Malone, together with a team of MIT researchers, analyzed groups that proved exceptionally effective at creative problem solving. Their goal was to identify the salient features that made some teams much better than others. What they found was that individual intelligence (as measured by IQ) didn’t make the big difference. Having a high aggregate intelligence or just one or two superstars wasn’t critical. The groups that surfaced more and better solutions shared three key qualities:

These qualities were:

  1. They gave one another roughly equal time to talk. This wasn’t monitored or regulated, but no one in these high-achieving groups dominated or was a passenger. Everyone contributed and nothing any one person said was wasted.
  2. Social sensitivity: These individuals were more tuned in to one another, to subtle shifts in mood and demeanour. They scored more highly on a test called Reading the Mind in the Eyes, which is broadly considered a test for empathy. These groups were socially alert to one another’s needs.
  3. The best groups included more women, perhaps because that made them more diverse, or because women tend to score more highly on tests for empathy
We were all smart enough and had a wealth of different experiences, but no one deferred to anyone; that made us curious about what each could offer. We knew we needed an answer but we also knew that no one of us had it; we would have to work together to craft something we could not make alone. At times we were frustrated, scratchy, impatient. But nobody had any agenda. We all cared passionately about our shared success. In all of this, we’d been lucky; but can’t we do better than luck? — Margaret Heffernan

Having smaller, cohesive teams helps you build social capital, a common mission and success that everyone shares, free of personal agendas. It helps solidify company culture and it enables us to scale more efficiently with new hires being brought into the fold much more smoothly.

Which begs the question — how do you keep your teams “small” as your business grows and needs rise?

In my time here, I’ve seen the company double in size to 17 employees, mostly engineers who focus on our other stealth products.

I don’t believe we’ve had to compromise on team quality or productivity in the process. More often than not, we’ve managed to keep things pretty egalitarian.

I believe the reason is that our team growth has been in proportion to our business growth. When you make a new hire to fill a product gap that meets a business need, the person you’re hiring is of critical importance to the development of your company.

As you build you business in this investment climate, make sure you don’t fall into the trap of purely investment funded growth, where the money comes first, followed by the team and finally, the product/business. Or for that matter, measure your success along the lines of team size. Hiring only when you feel that slight pinch makes every hire that much more valued — increasing social capital even more.

This reflects in the scale of responsibility that the person is asked to shoulder. Smart people thrive under such conditions, often surpassing what they themselves believe they were capable of. If only I had a dollar for each time I felt that one of our engineers had done in a few months what would have taken a larger team several months.

Many companies fall into the trap of scaling their teams faster than their revenue/traction. With the money that’s out there it becomes tempting to hire rapidly, completely out-of-proportion to business growth. This can be risky business, and in the world of startups where things shift around rapidly, it can leave several members of your team disillusioned and unsatisfied.

So far, this strategy of growing organically has worked well for us. Thanks to our efficient cohesive team, we’re able to churn out more features, offer great customer support, and have full control of our API to meet customer requirements. Our API business is profitable (not too shabby, given that we have a small sales team), allowing us to reinvest in growing our team and building new products.

And more importantly, it allows us to put our customers first.

Interested in our API? Call us today!

As always, lovingly made in San Francisco and Bengaluru, by Hari Viswanathan and the Semantics3 Team