Success is more than headcount with Alex Plugaru, CTO at Gorgias

Rebecca: Alex, how’s it going?

Alex: Good, how are you?

Rebecca: Excellent. Excellent. Thank you so much for joining me today. I introduced you just a moment ago very briefly, but can you tell me a little bit about who you are and what we’re gonna talk about today?

Alex: Of course. So first of all, thanks for the invite — I do appreciate it. Very quickly about me and what I’m doing: I’m Alex Plugaru, one of the co-founders and CTO of Gorgias.

Gorgias is helping merchants deliver exceptional customer experience. So we are operating in the ecommerce space and we’re making a help desk for ecommerce. Most of our customers are in Shopify, Magento, and WooCommerce, so we’re making a support tool, so to speak. But I’ll tell you more about it a bit later.

Rebecca: Thank you for that. Since this is a podcast that is supported by Swarmia, I know we also wanna just point out that you’re an investor in Swarmia, but you’re also a customer and that’s why you’re here today.

Alex: Yeah, I think it’s super important to disclose these things. I was a customer before, I think for two years before investing a pretty small check. The reason I did is because I truly believe in the company and I think the direction and the approach the company is taking towards engineering productivity, which is a subject I really care about. Thanks for inviting me, I really appreciate it.

Rebecca: Yeah, I’m glad to hear all of that. We’re actually gonna talk about basically none of that today. Really wanna dig in today to your experience as an engineering leader and in coming up with Gorgias, starting as a co-founder and being the CTO today. So you wanted to tell me just a little bit about what was the state of the world when you — you didn’t show up — you founded this and what was the state of the world when you got started on this?

Alex: About 10 years ago I was working for a startup here in Paris. We had a kind of mix of B2C customers, so consumers and companies. I think half and half was the distribution at the time. It was a pretty small company and we only had one support person and I was an engineer in the company. And so we were looking for a tool at the time and we couldn’t really find anything that suited our needs. And I was like, you know what, we we’re using Gmail and I’m just gonna write a Chrome extension to write faster, to respond faster.

And so, I was working pretty much like weekends to build this tool and I published it on Chrome Web Store and I got quite a bit of usage with not much marketing, just through friends and all of that. So it started growing until eventually I realized that this might be a thing and people actually care about it. And so this is how the story started and then soon after I met with my co-founder, Roman, who’s the CEO of the company, and we decided to become a bit more ambitious and really create a fully integrated tool, not just an extension. But really it started like with an extension. We understood the market a little bit better because none of us were experts in customer service or sales or anything. So it was a really good method to learn about the market and talk with people — and so that helped us a lot. This is how it started and now it’s been quite a bit of time.

Rebecca: I know there was a period when a lot of businesses were getting started around Chrome extensions. I wonder how much that’s happening today?

Alex: There are still pretty big ones like Grammarly. But the problem there is that you can absolutely make a business but it has just been very rare to make a SaaS business. I feel this is partially because of how Google looks at their browser and partially how people approach it. It’s really strange to look at a Chrome extension and pay for it. Like our highest plan on the advanced plan is $750 per month.

Rebecca: Nobody’s gonna pay that for a Chrome extension.

Alex: Like who’s paying for a Chrome extension that costs that much? Right. So it’s very different, I would say, and there's some perception around it, but I would say one can definitely build a business, but there are very few examples in the Chrome Web Store which are really big ones.

Rebecca: As a discovery mechanism as you’re exploring a product I think it’s really neat.

Alex: Absolutely. It’s very low friction. There are millions of people on the platform and you don’t need a lot of servers ‘cause the code runs on the client. So yeah, I highly recommend starting something like this if you think of testing an idea and kind of putting it out there. It might be a good platform to check it out. Of course, not all businesses can do that.

Rebecca: It makes me wonder if like Postman had the same kind of journey of like making something that worked.

Alex: And then they became a standalone app eventually, right?

Rebecca: Realized that they could make some money off of it. So tell me about Gorgias today: How many engineers… How big is the company as a whole? How many engineers do you have? And how are you structured engineering-wise?

Alex: Absolutely. So we’re globally distributed. Typically, we have this kind of weird hybrid system where we have a bunch of different hubs. The headquarters is in San Francisco. We have a hub in Paris where I’m right now, we have a New York office and we have a Toronto one. So basically we’re a little bit distributed and mostly around where the customers are. Most of the engineering is located in Europe and, in total, we are about 260 or so people right now. And from that about 96 in product engineering and design, of which 78 is engineering — including the engineering managers like myself. Basically, everyone who has engineering function. I am responsible for the engineering team so I’m the CTO. All the engineers who are working as part of the product organization are reporting to me.

Rebecca: You mentioned like 70 or 80 engineers today — how has that changed over the years? That actually strikes me as a kind of small number for a company that has been around and successful. So what’s your secret? But also how has that number changed?

Alex: I don’t really subscribe to the success based on the headcount. I feel that is not necessarily very representative ‘cause you can make quite a successful product with very few people. There are a lot of examples in the industry where that is the case. I believe WhatsApp has had 20 people, Reddit also. So you can definitely do it with less and I would actually encourage people to think twice: can you do it with fewer people cause that adds a huge amount of overhead? Things don’t necessarily move slower but it adds overhead. If you can do it with a smaller team, absolutely 100% of the time you should.

The way our organization evolved for a pretty long time was with a team of five people. I think the first two years since we started actually working on the company and raised some plans and so forth we were pretty much preserving cash and trying to get to product-market fit. Just for context, there are two aspects of our market: first of all, in the ecommerce, and specifically in support, the budgets are not as big as in marketing or other departments. So typically support has one of the lowest budgets. Their willingness to pay for a product is not that high.

Secondly, there’s a lot of competition. One of the competitors is Zendesk, one of the biggest ones of course. Everyone knows Intercom. These are very high-quality products and it’s very difficult to break into the market. So for us, it took quite a bit of time to find that aha moment for the ecommerce merchants, and we selected a specific niche. So we didn’t go after like “Boil the ocean” type of approach, “We’re gonna support everything!” We said: “You know what? It seems that a lot of ecommerce merchants really need a tailored solution. Also, the total addressable market is quite big. Just for reference: Shopify has about three million merchants today. So it’s a quite good ecosystem to be in and to grow, and they’re still continuing to grow.

In terms of headcount evolution: when Covid hit, we had a pretty big accelerator ‘cause everyone would move online and ecommerce had like a pretty big boost — everyone is aware of that. That provided quite a bit of, basically, tailwinds for us. That allowed us to scale really quickly. I think at the beginning of Covid we were 33 in the company and quickly in two years we became 200. So we grew really really quickly during that period and we raised a bit of cash and there’s learning there as well. I mean, quite a few I could share about that, I would say, the hypergrowth stage of our company.

Rebecca: Yeah, I think it’s interesting ‘cause this is actually my first time working at a startup in about 10 years. And so I’ve worked at much larger places and I look at 78 and that doesn’t feel like hypergrowth. It's really true that going from 30 to 200… it’s a whole different company, right?

And you’ve got Covid going on around you, which is, you know, just…

Alex: And we also switched from a single office to fully remote. A lot of challenges.

Rebecca: Right. How did you decide that this was actually worth it? What influenced that decision to do that big jump in growth around Covid time? I mean, obviously, Covid influenced it, but how did you talk about that as a company and say this is actually the moment when we can use more people and we’re confident we can use them correctly?

Alex: I would say when work can actually be split. When you can be parallel in some aspects of the company, meaning, for example, the way we organize ourselves is sort of like squad, tribe, alliance structure. We don’t really have alliances, we just have tribes right now. Basically, it's the Spotify model where at the leadership of each squad there is the trifecta of product, design, and engineering.

And we have engineering managers who are quite technical. They are expected to also contribute technically from time to time. So I can talk about that as well. But this is how we organize ourselves. So each squad and tribe is responsible typically for like a kind of product function, either a big product function or a product offering with separate pricing and separate go-to-market strategy. The collaboration between these different offerings is not that high. Meaning that there is a separation that you can create.

So if you have this type of a system I think it’s certainly worth splitting it up. There are other ways to split up, but basically, the theory around how to split up a team and why is about the cognitive load. For example, if you take a squad and you say it’s like what is the domain of this squad? How many responsibilities do they have? Do they have like 50 different responsibilities? Like how do they need to do their jobs and so forth?

If it’s too much the backlog just increases and increases and it’s crazy and never gets consumed. And everyone is frustrated all over the stakeholders and so forth. Usually, every manager sees some fracture lines where they can split up and create this cell division and usually they become apparent.

But I think it’s like when you think about cognitive load, usually, you can split it up to three different sections one being what does a team need to do their job? Do they need to know JavaScript, Python, Java, like five different languages or just one? Do they have a huge amount of technologies that they need to execute with or just a few?

I would say the absolute must to do the job is like the intrinsic cognitive load. So they need to know for example JavaScript, Python, or whatever. And then there is the kind of extraneous stuff, which is like: I need to know the CI, how to deploy, the product, how we create process functions, and so forth.

This is something that is extraneous to work and the value that is being created. Absolutely important still, but like do you really need to know how the operators work?

Rebecca: Right, hopefully not!

Alex: And then there’s the kind of business knowledge, like the domain knowledge: Do I know what the customers want? What would the stakeholders expect? Should I notify the support team before releasing these things? Do I have an awareness of the world?

When thinking about splitting teams and separating work and adding headcount, I think it’s important to think in terms of cognitive load and dividing these different cognitive load types and see how can I bind the intrinsic ones. Meaning like that the team should only know five different technologies, like JavaScript and maybe a little bit of this, a little bit of Postgres, and so forth. How can I limit or minimize the extraneous ones? Like we shouldn’t necessarily know so we create abstractions and so forth and templates and all of that type of stuff to reduce the extraneous ones. And how can I maximize the domain knowledge, product knowledge, business knowledge, customer needs, stakeholder needs, and so forth, right?

So this is usually how I think. There is an excellent book called Team Topologies, which goes into a bit more detail about this. And I think this is the method that we’re using to scale our team. And of course, in the book there are discussions about platform teams, complicated-subsystem teams, and so forth but this is beyond the scope of this podcast, unfortunately. We would need to talk a very long time.

Rebecca: So when you made the decision to start growing, did you know all that? Or what mistakes did you make along the way? What did you have to fix along the way?

Alex: Well, just to put things into context I’m a first-time founder. I haven’t done this in the past. I’ve been working in the industry for quite a bit before starting the company, of course, but really this is also the biggest company I’ve worked for, ever — most of my career I’ve been in very small companies. So definitely an unknown territory. I think what helped me avoid certain mistakes — not that I didn’t do a lot of them, like every founder — even experienced ones of course make a lot of mistakes.

There are basically three ways I tried to gain knowledge and avoid common pitfalls. I tried to speak with people in the industry who are close to the level that I am. So for example, some of our investors are from Datadog — really excellent guys — but they’re a public company. So like whenever I get to speak for five minutes with Olivier, he’s like, “Man, I don’t know at your level what you should do, it’s just way too early”.

So I think selecting peers closer to or maybe like a level up. Say, if you’re at seed round, try to reach out to a couple of Series A and Series B people and try to understand what they’re doing and what to avoid that stuff, and so on. That’s one thing. Second, if you’re lucky get an executive coach, get it if you can. It really works. I think it’s really great to have this type of support. It’s very hard to really deal with a lot of stuff day to day and there’s a lot of up and ups and downs in startups. So if you can absolutely do it. If you’re on a personal level, get therapy if you can, definitely helps.

I would say it’s an unnatural state to be a founder. In the history of humanity, there weren’t lots of this sort of situations where you grow super fast. So we don’t really know exactly what is a good approach; I think they’re still discovering the dynamics of being a tech founder. So there’s that and of course reading books, blog posts, podcasts, right? Like listening to all of it, getting all of the resources that you can. I would say these are the ways to do it.

In terms of mistakes that I made I would say the biggest, in engineering specifically, and the thing that affected the most, I would say is, the fact that we hired engineering managers, who didn’t really have a lot of very strong technical skills. Basically, they weren’t senior engineers in the path. They moved to management a bit too early, in my opinion. And so they are extremely good at people skills and managing backlogs and so forth.

But the satisfaction from engineers was very low, because it’s the classic story: my manager doesn’t know my job, he cannot really understand, or empathize with my struggles, or help me get unblocked. And so I would say my philosophy is that the engineering managers, no matter which level, need to know how to code and need to be technical. Of course, I don’t expect them to be at the principal level, it’s just not realistic to expect that, but they need to be pretty good engineers because, otherwise, it's extremely hard.

Rebecca: So tell me about today. Today you’re on the other side of that growth, or I’m imagining it has slowed down a little bit post-Covid, and you’re not in the hyper phase. What does your job look like today? Why are you there? Why do they pay you money?

Alex: I think it’s important when you’re a co-founder and when you’re still to separate the roles that you have a clear understanding of when are you operating as a co-founder or one of the board members of the company, and when you are actually fulfilling a job. I think writing your own job description is a good exercise to do. When I did that exercise, I realized there are typically two types of CTOs in the industry. There’s the architect: the individual contributor, but not really the manager archetype where this person is pretty much the top individual contributor in the engineering team. And they usually hire a VP of engineering, which is basically the people management, work structure, the strategy, and they usually collaborate closely together with the CTO.

Rebecca: Right.

Alex: And then there is the CTO who is just a manager. I’m the second type. I’m managing other managers, who manage managers who manage ICs. I’m pretty much fulfilling the management aspect and I’m contributing as an IC, but extremely low, and usually it’s like changing a CSS somewhere or fixing a small bug somewhere else.

The reason I still do this is because I would like to see how the entire process still works. I feel there’s still a responsibility for me to understand from the beginning: how the code gets pushed from an idea, to an issue, and into production, what are the different steps, and how long it takes.

So that’s pretty much like the developer experience aspect of it, the reality is I’m not contributing that much but I do read code. I think even if you don’t code a lot, like if there’s an interesting PR around a technology that I’m curious about or it’s very important for the company I do get involved and I look at it a bit more in detail what’s going on.

Rebecca: I miss reading PRs. You’re right. I should do that. Just for fun.

Alex: Just make sure that when you have a lot of people if the CTO starts commenting on PRs and you don’t have a very close relationship with them, it can be triggering for some people. Just be mindful of that.

Rebecca: Yeah, it’s so interesting. I was at Indeed and got to see Indeed grow from 250 engineers to over a thousand, and that executive fear was real. I met my boss who was VP of Engineering and he was just a guy, but when we had quadrupled in size, people didn’t look at him as just a guy. He was like “Ooh, the scary VPE.”

Tell me, have there been other cases where you’ve had to realize your visible presence here is not helpful?

Alex: So this is a hard question to answer to me because I would say I’m maybe biased here but I would say at Gorgias we have a pretty transparent and direct culture. I think this is also the case in engineering. Usually in engineering teams, engineers are by nature a little bit more like “either the code works or it doesn’t” like what is your Datadog dashboard, right? What about Sentry errors? I don’t wanna say there’s no stochasticity but there is a lot of more matter-of-fact of type of things.

At least with the way when I do skip-levels with like a lot of engineers on the team, I get pretty, pretty interesting insights about what’s working and what’s not working. So, certainly, I think it’s important to remind people and also share not always your own concerns but basically share your thinking, share the context that you’re seeing. I think you’ll become a lot more approachable when you share basically your thought process around a specific decision and everything, and people can make their own decisions. And of course, ask for feedback like: I think this is what we should do, is there a better way? And kind of continue that debate.

I think the other part is that if there are a lot of new people that can be the impression that you’re not approachable. So I would say maintain the contact, do continue doing skip-levels, and don’t stay in your ivory tower and look from time to time somewhere. Be present, there’s no magic to it in my opinion.

Rebecca: How often are you doing those skip-levels and how far down the layers are you going?

Alex: So thankfully I still manage to do quite a bit. My system isn’t very sophisticated: I have a spreadsheet, the dates, and how long was it is since I spoke with someone. And I have the notes of course, like with everyone I speak with so before I do a skip-level, I do that. Sometimes I have some specific interest because of whatever the objective of the company is or the engineering team objective and so on. So I do more often skip-levels with some people.

For example, right now we’re in the process of revamping our analytics stack so there’s a lot of things around data pipelines and all up with databases and a bunch of different stuff, right? So of course, I will spend a bit more time there. I will maybe do a couple of one-on-ones with people, maybe even for a longer session, and talk about the technology and the challenges that we’re facing. So I would it depends, but typically I try to do them at least once–twice per year at the very minimum.

Rebecca: One of the things that were really interesting when we talked kind of to prep for this episode was you shared a really detailed framework of how you think about approaching software companies.

I’m just curious if you can talk a little bit about your takeaways from being a co-founder and what is there to learn from that, that isn’t specific to the ecommerce industry but is specific to the software industry.

Alex: So I like to illustrate this with a thought experiment. Basically, imagine that you have a company that is fully automated, the product is fully automated, the sales, the marketing, everything, and all of the operations of the company are completely automated. I call it a 100% software company. Obviously, that type of company doesn’t exist yet, although, with Auto-GPT and a bunch of stuff we’re getting closer and closer. But that’s not truly a reality that we have today. But I think it’s still a good and valuable framework to consider when building something. But what is automated today? Ok, payments: we talked about Stripe just now, like payments pretty much like once you’ve implemented it in the product, this is an automated process.

If you use payroll software: once you set it up, it’s automated, and so forth. There are examples of different functions in any given company in the world right now, which are already somewhat automated. So when thinking about starting a company, it’s like what are the different functions, how big are those functions in the company, and which parts of those functions can be automated with software? Because that’s like the nature of what software does: it automates work, right? So that’s the purpose. And we selected support because it’s a big one, all the companies have it and it’s very repetitive, meaning that it’s ripe for automation. So that’s the reason why we selected this industry. But of course, it doesn’t necessarily mean that that's the only one. Obviously, there are tons and tons of startups that do marketing automation or running your Facebook ads and stuff like that.

So yeah, I would say this is the kind of philosophy that we use to narrow down where we are. And what’s interesting is that like even when you select a specific area, like a specific cross-section of all of this, that cross-section is actually like a fractal: even if you go in one thing, there’s like new software creates the capacity to serve it.

So for example, we are serving the ecommerce industry, like a cross-section of the support industry as a whole, it’s very small compared to the global one. But now we have about a hundred integrations, which are businesses which like partially run on top of our platform. Basically, it’s like new software creates new opportunities and there’s always space.

So if you’re thinking there is oversaturated B2B software or there are too many social networks — maybe there are — but I would say there’s always some niche and there’s always a door that can open up. It depends on what you want to do of course. If you’re content with 10k MRR, if that is your goal, absolutely you can create that. You can be a one-person company, be very successful, and be content with that. If you wanna build a billion-dollar business in revenue or something like that, you obviously need to cover a little bit more space. But I would say there’s definitely more and more capacity being created even today.

Rebecca: I’m just curious, does that lead you to seek boring problems or is there some other takeaway here?

Alex: That’s a great way of saying it. Something that is typically boring is something that actually everyone needs. Like do you wanna see your lawyer every day? No, but you better have it if you have a problem. Or a doctor, or something that’s very valuable for a lot of people.

Personally., what motivates me a lot in terms of building software and products is that this software is used very often. Basically, I want users to use a product that is something very important to them. I don’t want to build something that is maybe used once every quarter or something like that. Like that’s not something that motivates me and so having a tool that is used daily by a lot of people is really motivating.

The reason for this is that I get a kick every time we do a small improvement: people notice. They give us positive feedback and that keeps us going. Essentially, it keeps us motivated all the time to get kind of good, positive feedback. In fact, for me, it’s like even the negative one. If I get it I’m just like “Yeah, the product is great, but tell me what doesn’t work!” And then you start pulling, and that’s like to me it’s very motivating as engineers like, okay, this is the edge case we didn’t really think about. How can we figure it out, and so forth?

So I would say, if you are thinking about starting a company, at least from the point of view of an engineer — and I don’t think it necessarily applies just to engineering — choose something that is useful for a lot of people because I think that will keep you motivated because you’re gonna see that you’re impacting people’s lives in a positive way. Usually in B2B, there’s a lot of competition. People go from company to company, they churn and transition to somewhere else. If people use your product, it means you build something pretty good because there are alternatives, right? It’s like if they didn't feel like your product is good… So you have the money because they’re paying you, and that’s kind of their vote that says your company’s doing something valuable.

And there’s like also the founder-market fit. For example, we didn’t have a founder-market fit. We kind of grew into it by… I mentioned at the beginning of the discussion the Chrome extension where we found a very low-cost way of learning. And so this is how we acquired a lot of knowledge about the market. We had very little funds. And so if you can find a way to learn quite quickly, then you should absolutely take that path. If you do not have a ton of industry knowledge, like we didn’t have.

Rebecca: I think that’s neat that you have still been successful without the industry knowledge. I also think my “choose boring problems” was a little tongue in cheek too, because as you’re pointing out these problems aren’t boring once you get into them.

Alex: By the way, I love customer service. I feel like this is the best approach. If I were to go to another company I would just go and do like a month of customer service as an agent, I would know exactly what’s wrong with a product, with the processes… I would get to know the industry basically by talking with customers. I feel like it’s such a powerful way.

And usually, customer service is, almost like 90% of the time, the only moment that a human communicates with another human. Of course with automation that is decreasing, basically, the company scales even more and more. But that connection, that touch is pretty valuable and I think it’s completely underrated as a whole. I think we are approaching customer service in our industry in general in the wrong way but that’s a different discussion.

Rebecca: That is a whole other topic, but I think it’s really interesting because I agree. I think it’s an underutilized resource when you’re trying to figure out what the heck you should be doing and I could talk about that for a long time, but as it stands, we have used up our time. So Alex, thank you so much. This is a treat to chat and we’ll hopefully talk again soon.

Alex: Thanks for inviting me, appreciate it.