Product tour
Product
Capabilities
Ecommerce platforms
Centralize 1:1 interactions
AUTOMATE YOUR WORK
EMPOWER SUPPORT TEAMS
MEASURE & IMPROVE
PLATFORMS
Pricing
Partners
Resources
It's been over 3 years since we've started working on the Gorgias helpdesk. The engineering team started with just me (Alex) and then gradually grew to a team of 5 people. We're a small team, but we've accomplished a lot during this period. Here are some stats from 0 code/customers/revenue in Oct 2015 to this:
Modest numbers to be sure, but we're very proud that people use our product in a big part of their workday and hopefully are becoming more productive while doing so. The whole idea behind our product is to scale customer support with as little resources as possible. Given this, perhaps it's only natural to build our product with a small team as well?
We've been suffering chronically from "not having enough people" - we still do. That forced us to adopt a certain engineering culture that I want to talk about in this post.
When we first started building Gorgias, having just a few people on the team allowed us to progress at a pace where we could collect real feedback from our customers with things that really mattered to them rather than building every feature they ask for. A lot of their asks seemed legitimate, but because we didn't have a lot of people it forced us to prioritize the critical, high impact things first.
Having a small team can act like a barrier that blocks you from building a bloated product.
I want to make more of a case for the above statement, but first I'd like to get a bit more into what we did during the 3 year period.
Once we've build an initial version of the app and got our first customers we quickly realized that building a "second Gmail" is super-hard:
It takes a lot of effort to get to a point where you can compete with the likes of Gmail or Zendesk - both amazing products btw. This was definitely the case for us, for close to 2 years we had only a couple of customers and our product wasn't that good if we're being honest.
So what changed a year ago? To put it simply: our product didn't suck anymore. Or sucked less. It had that minimum set of features and stability that made it attractive enough to our main customer base (Shopify merchants) that were passionate about productivity in the customer support space. That, and the tenacity of our CEO Romain who was convincing everyone that they should use us.
So we started having our second wave of early adopters and all our hard work was finally starting to pay-off!
Now that we had more and bigger customers we were starting to have performance issues, our app was slow, suddenly we were starting to get bombarded by viral facebook posts events or promotional events via an email campaigns, we didn't have enough monitoring in place, our app was pretty inefficient, the main database was a frequent source of congestion. So we started fixing those issues while still receiving numerous feature requests.
Thankfully we didn't actually optimize our code that much before (no customers!) and there were a lot of low hanging fruits at first, but it still put a lot of stress on the team which was becoming tired and overworked and requested to hire more people to build those features and help with the performance issues.
We all agreed that it would be for the best to have more people on the team, but hiring is hard. Competent coders are not just randomly looking for the next gig. SF is also a very expensive city and for a startup that raised $1.5M and a 2 years of money burned we couldn't really compete with other players in town. We've started working with some great devs in Europe, we worked with a few talented interns as well and we tried to get by until we could have more customers and hopefully raise some more money to hire more people.
I could speak more about hiring in the Bay Area and there are a lot of things we did wrong and still have a lot of things to learn, but that's probably an even longer post than this one. But yeah, it's hard to find someone good, it's expensive, etc...
So what is the situation right now? Well, it's not much better. We've raise d a seed extension round from SaaStr with Jason Lemkin and hired a few people in the Growth team, but we still have a hard time hiring in SF or remote. In the meantime we have a small team and want to talk about that.
I think it's important to realize the advantages of having a smaller team and the single most important super-powers that you're forced to acquire is saying NO more often that you would with a bigger team. If you have a bigger team and say no to a feature, new platform, integration, etc.. it's harder to justify the decision. There are arguments like:
... we have enough devs! They are paid to make features, so what's the problem!?
... the data shows that 50% of our customers are saying that they want this or that feature, we must build it!
But do we absolutely need to build that feature? Are the customers going to be a lot less effective with your product otherwise? Is it going to be a big boost for them or just a nice improvement? Once a feature is there you have to maintain it, fix bugs, improve it, etc.. The thing with data driven decisions is that sometimes it can be biased towards some historical practice that might not have a place in your current world.
Now, I'm not saying that you shouldn't listen to your customers, you absolutely have to, but be sure you understand well what they want before taking action and understanding takes time. Having an artificial brake on your enthusiasm might be a good thing.
Engineers build things, the natural tendency is to accept any technical challenge because of ego, curiosity, fun, etc... It takes discipline to say no and stick by it. A small team is making it easier to do it.
When you have a small team you're forced to automate a lot more often some of your workflows. You don't have the luxury to do repetitive stuff so:
People that work at Gorgias come from different backgrounds and sometimes it can be challenging to be on the same page. In some cases our work processes are similar to many other companies:
But there is so much more than just the above processes to engineering:
These things need time to happen to be embedded in your engineering consciousness and if you're the first-time founder (like myself) you also need the time to understand how to operate in this environment.
Never managed a big team so I can't really speak about it's dynamics, but I would expect that because there are more people there is a lot more bandwidth you have to manage, a lot more people have to agree, a lot more politics have to be settled. I don't look forward to that to be honest, the more time I can get away with hiring as little as possible without a big sacrifice of our growth as a company the more I'll try to delay it.
I conclusion I would say that it's totally fine to have a small team, in fact, I'm considering it a competitive advantage that you should try to keep as long as you can.
I made a point in this post that having a small team is a competitive advantage, but I also think that we are ready to grow our team a bit. Yep, we're hiring!