Ben (00:16):
Hello, and welcome to PodRocket. Today I'm here with Allen Chaves, who is the CTO of Klaviyo. How are you, Allen?

Allen Chaves (00:23):
I am doing well. I'm glad to be here.

Ben (00:25):
Yeah, really excited to have you. Klaviyo, another great company in our neck of the woods in the Boston area, so very familiar with your work. But what we could start with maybe, for the folks out there who aren't familiar, can you tell us a bit about Klaviyo, the company, what the products does, and then we can go from there.

Allen Chaves (00:46):
Sure. So Klaviyo is a customer platform. What we did was, we took a customer database, the experiences that marketers use to communicate with their customers, and the channels that they use to communicate and put it all in one platform. What is it we enable? We are enabling companies to grow their businesses. In doing that, form one stack in one place that has both the data and experiences that they need to communicate with their customers. That's what makes Klaviyo so powerful.

Ben (01:18):
Got it. So when I think about like a customer database, the first thing that comes to mind is like a CRM, Salesforce, or another Boston company, like HubSpot. So curious, how does Klaviyo compare to the traditional CRMs that most companies are using to store data on who their customers are?

Allen Chaves (01:36):
Yeah. So that part of our stack, which we call the customer database, as something that can ingest really high volume of data at scale, and then can offer that data up at really low latency to either our application or to an API. So I'm literally talking about, we ingest billions of events, we process that in a way that you can ask any questions that you need about the profiles that you just store in our database. That powers our application, segmentation engine, the flow engine, but it can also power all the applications through our API's.

Ben (02:16):
Got it. And so is that aspect of the product where you're ingesting all that data and providing the ability to query, is the right way to think about the alternative there of, is a data warehouse? Like a snowflake or something you roll your own kind of data warehouse on AWS. Is that more of the alternative that people would use instead of Klaviyo?

Allen Chaves (02:38):
Yeah, that is a great question because we look at what we do in our customer database as a combination of OLTP and OLAP, a data warehouse. So the difference with a traditional data warehouse... No, let me talk about what is similar first. Similar is the fact that we store a lot of data. We never throw in any data. So all the facts in properties or actions that a profile takes, we store. But then the difference to a data warehouse is that we allow queries that have really low latency to ask things like, "Hey, give me the total orders that this one profile had in the last day, month, seven days," for example. And that's super fast, as opposed to a data warehouse that you need to be really writing customized queries to do all of that. So it's a combination of both.

Ben (03:32):
And why does low latency matter? What are the use cases where people really care about how quickly a query like that would run?

Allen Chaves (03:40):
Right. That's so many use cases, it allows... I'll give you one. You have more flow automation, which is the ability to design how you're going to respond to events. If a customer left an item in their shopping cart for more than seven days, you would like to test that, find out the customer is valuable, according to your definition, could be customers that live in New York and then that bought more than a thousand dollars the last month, whatever you define. And then that triggers an action, either an SMS message or an email message. The computation of that query that I just described needs to be super fast. Why? Because some of the communication that you want to give your customer, sometimes you want that communication be super fast after the action they took. Like the item they left in the abandoned cart, you want them to get that in the next second, not in the last next day. So that's one example of, "Hey, I need to be able to answer the question, how much has a profile bought from us the last year, really fast," it's one example.
Honestly what we're really curious about is through the APIs that we just launched, what is the developers are going to do with this? Has the imagination, it is the only limit that you have and what you can do.

Ben (05:18):
Got it. And yeah, I definitely want to hear more about the API's in a minute, but I'm curious in terms of querying, like once I've put all this data into the Klaviyo data warehouse, or what database, whatever we call it, how do queries work? Is it like a custom query format or is it like SQL queries? Or how does querying of the data work?

Allen Chaves (05:42):
It's an API that has query capabilities. Filtering, ordering, etc. So everything that you have access to is through an API that will give you that functionality.

Ben (05:55):
Got it. And so is the API the primary way that folks use and interact with Klaviyo or you were mentioning before, like taking action on queries, my understanding is that's also part of the platform, like sending a text when something happens or taking actions. Is that also part of it?

Allen Chaves (06:13):
Yes, so part of the platform is the ability to essentially program an automated flow. As actions happen, you want something to happen. A text message to go out, or you could also say, "Hey, call a web service for me, call an endpoint for me, a web hook on your side." So that allows you to programmatically define, actually it's in a user experience way, you drag and drop actions and say, "If this happens and then there's branching, if it is, yes, do this, if no, do that." And one of the action could be, "Call this rest endpoint in this other system," for example, or, "send an SMS" or "send an email".

Ben (06:56):
Got it. So essentially I can say when that user has left an item in their shopping cart for seven days, then send a text message to the user with, "Hey, you should go back and buy the item, or hit a web hook on my back end," and then I can do whatever with that.

Allen Chaves (07:13):
You got it. Yes.

Ben (07:14):
And, and so you mentioned that the API is kind of a growing area of interest. So could you explain a bit more, what are some of the capabilities with the API and what are kind of your goals with investing more in the API platform moving forward?

Allen Chaves (07:31):
That's right. So if you just peek under the curtains there and look at how we built the technology at Klaviyo, you're going to see a lot of reusable things actually have little to do with marketing for e-commerce which is what we do. The database that we just described is one element. You could imagine doing things that are completely unrelated to what the Klaviyo app does. The flows engine, we call it a flows, the automation engine that I just described, that's another one. Imagine that you through an API, you could programmatically create a flow, that says, "If this event happens, do this, if not do that." So, and this is little, what we're getting to with the API's. The scope of the API's is everything that you do and see at Klaviyo. You could be sending an email, creating a flow, etc, you have access through an API.
What is it that we think is going to happen? We already see a lot of demand for that in terms of customers that want to programmatically access what we have. But again, the imagination is the only limit that you have. We expect creators, developers to use the functionality. We have to create things that we have no idea today where they may go and that's okay. We built the technology behind the covers in Klaviyo that is reusable in a way that we know people are going to take advantage of.

Ben (08:59):
It's interesting. So, typically what I think about, you know a tool like Klaviyo where there's a GUI, and you can create flows and automations and things like that, it's great for teams where it kind of unlocks the capabilities of programming for non-developers, because people can do... It's like Zapier or if this and that, or any of those tools, super powerful. I'm curious, what's the use case for where an engineer would want to use an API to program those flows, versus just if I'm already in code, I could just write the code?

Allen Chaves (09:35):
Well, look what Zapier does, for example, in use case that they can solve, we should be able to solve that way. In other words, you could use this as an automation engine, a workflow automation engine at scale. What I mean by scale is, we do billions of those things. Therefore, we have prepared for whatever you can throw at it. So just think now that the application they're developing needs some workflow capability, you got the engine to do that if you use our API's. You don't need to use any of the marketing stuff that's around it. You just create the automation. So it's very generic use case in that sense.

Ben (10:14):
Got it. And you mentioned kind of you're building this API platform and it will be up to developers with their imaginations and creativity to figure out what kind of use cases are possible. I'm curious how you think about doing what you can to plant the seed in developers' imaginations of what is possible? Like are you doing recipes or documentation, or creating sample apps? Like how are you thinking about kind of putting stuff out there for developers then work off of?

Allen Chaves (10:51):
Fantastic question. So we actually have a team that all they do is work on the developer experience. This is about documentation, send boxes, etc. And then we have people in the market organization, they are our developer advocates, and they are responsible for well advocating for the API's, putting code samples together, so in a way that people cannot start to think what's possible. Because if all we did was, "Hey, those are the API's." That's not enough. We need to start to show people what is that we could do. Keep in mind that I'm talking about generic developers, but we also have 6,000 partners that already are connected with Klaviyo. They're helping customers to interact with our platform. And in many cases, when they have a custom integration, they're using the API's. They also produce code samples of everything they are trying to do, that we can then leverage to give as examples to generic developers. But it's very much in our mindset. We need to continue that way, stretch the platform.
And one more example that I would give is, and then there's some special things that we're doing internally venture teams that we want to use the API's. Those is literally, "Hey, we're going to have really small team inside Klaviyo that is actually developing an application completely different what Klaviyo does today, using the API's. Just one more forcing function or example of what can be done. Early days where we're so excited about that path that we are taking.

Emily (12:34):
Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great doves like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show.

Ben (13:10):
So let's talk a bit more about what's going on under the hood. So we have this platform, it can ingest massive amounts of data, it can be queried really quickly. What does the stack look like? What database, what infrastructure have you used to build Klaviyo?

Allen Chaves (13:27):
That's right. So under the covers, we have a ton of different open source technologies. On the database side, we have a bunch of MySQL and Postgres. We have Cassandra and we have ClickHouse. So depending on your use case, which API you're accessing, you are heading one of those things. So this is at the bottom, that's the database. The user experience is built in React, and specifically in TypeScript, is the language that we use. The business logic for either the API's or what the API is calling, is mostly Python. I think we have one or two systems, written in Java, but for the most part, our stack is Python. And I guess the last part is that all of this is running in a public cloud. So we truly use Infrastructure as Code You build it, you run it. Each team has the ability to deploy. And not only that, they also have the responsibility to keep that up and running. In our case we use AWS.

Ben (14:36):
And I'm curious on the backend, not surprised to hear ClickHouse is involved, since it's honestly kind of a revolution in terms of anyone building applications that involve analytics, but ClickHouse is fairly new and Klaviyo has been running at scale for many years. So were you using something else before ClickHouse or is ClickHouse just a new addition that has added new capabilities?

Allen Chaves (15:00):
Yeah, good question. Yeah, ClickHouse is a kind of recent addition last year, and it's solving for a specific use cases that we wanted to have more of a OLAP capability, as opposed to the real time, the real low latency use cases that I talked about. For that, today we use Cassandra. And this is part of what we are trying to do, is just continue to evolve. What do we have and look at technologies, and you're right, ClickHouse came of, in my mind nowhere. And it's such a fantastic technology.

Ben (15:35):
And for folks that are familiar on what is OLAP and could you just explain that concept a bit?

Allen Chaves (15:40):
Yes, so think the best way is a data warehouse, to explain is a data warehouse. So this is about where usually all the data in organization goes to. So you have your CRM data, your product data, your sales data, they all go there. And then there's a team, usually a BI team, Business Intelligence, that is then building queries to answer questions about the business. I think the biggest characteristics there is, one, it's a lot of data that we also do in our custom database, but the latency is not really that important. You're talking about queries as reporting essentially, that if he runs in ours is okay. That's what differs from the OLTP side, online processing side, that it is really low latency.

Ben (16:32):
And so I guess, maybe you kind of answered this question, but do people use Klaviyo for BI applications ever? Or is it really more like you have a subset of your total, kind of data warehouse data in Klaviyo, you're using Klaviyo for things where you need a fast query to take action on, and then you have all your data in your data warehouse and that's where you do your reporting?

Allen Chaves (16:58):
Yes, so we see use cases of people using Klaviyo as a CDP essentially, which is a customer data platform, which has both the low latency case that I talk to you about, and the cases where it doesn't really matter. It's about creating massive amounts of data in ways that are a little unpredictable. So we're seeing more and more, especially larger customers, that used to have a CDP and a different product. And they're seeing more and more that Klaviyo can provide that capability, instead of just relying on a completely different stack.

Ben (17:32):
And a CDP customer data platform, that would be something like Segment, that they might have used previously. And then they realize, "Oh, we can just keep use Klaviyo as our source of truth for all customer data."

Allen Chaves (17:44):
That's exactly what we are seeing is. Yes, Segment is one of the CDP's out there, not a really good one. And we see more and more customers using what we have because they already using the rest of the stack to do their marketing. And they are not finding that because of all the data is already in one place in Klaviyo, and we allow you to access that data in many ways, that they can use that instead of a separate CDP. They would have to move the data that we have into. So we skip that step and just use Klaviyo.

Ben (18:13):
And how do I get data into Klaviyo? I imagine I can send it in with an API, but then are there also integrations or ways to pull data from other systems?

Allen Chaves (18:23):
Yes, so if you go to Klaviyo.com, you're going to find we have more than 50 integrations with other softwares that we use to get the data in, which is really about the two things that I talked about for the most part, which is facts about profile, who you are, what your shoe size, if that's important to you, and then the actions that person took, which product that person visited, which order that person placed. And that's what we store across the board. Those are two examples. We are super generic. You can store anything essentially. And those are two example facts and actions.

Ben (19:05):
Yeah, that was going to be my next question is around how Schema works. So you kind of gave an example that sounds like it would fit well with a eCommerce platform where I have people accessing my site, people take action, they view pages, they view items, they add them to their cart. Can you use Klaviyo with a Schema that's for, let's say a B2B SAS, where you have users, but you also have organizations and people are in organizations, like, is that a use case? And then, is it even more generic beyond that?

Allen Chaves (19:34):
Yes, so the short answer is yes. And more and more we are seeing those use cases come up, which is making us more and more generic. But something I said earlier is important, which is we built that part of this stack, not thinking about marketing or e-commerce. So it's built in a way that is generic, is not a marketing database. So we see more and more opportunity to continue to expose that functionality to customers, if it is not there. And we see customers using it that way today.

Ben (20:07):
So, one of the things we talked about briefly before then I think would be super interesting for our audience is, you mentioned that a recent project is that you're revamping your whole user experience and front end and putting in place a new design system. So could you kind of take us through, start to finish, like at a company like Klaviyo, which has significant scale, what does that project look like and how you kind of think it through and yeah, kind of take us on that journey?

Allen Chaves (20:37):
Yeah, that's a great question, because it has been a fun journey to be. And we're trying to solve two big business business problems. One is making our product even more usable than it is today. So it attracts people that don't necessarily need to be a market expert. That's problem number one. Number two is, we actually see a lot of traction outside The US. So we want to be able to localize and internationalize our software. So all of that in, we need to revamp the user experience. And we wanted to revamp in a way that is, A, put a design system in place. So we have a design group that is the one responsible for actually designing the design system. But then what we did was, we actually created a front end platform team and what they do is they shepherd that technology transformation of going from what was server side rendering to a React type script. And how architecture that work, how the build system works, and how to help the teams onboard into this new stack.
So this is being a separate team actually is more than one team. We have a team that is responsible for the component library, which is tied to design system. Another one is the web platform, which is concerned about build system, how to onboard developers, how is that you structure your code in order to do this in a React way.

Ben (22:08):
And are you still have in the middle of this process or have you launched the new front end and the new design system?

Allen Chaves (22:15):
Yeah, so no, we are not complete. But we are not waiting to be a hundred percent complete before we deliver. So what we're doing is literally page by page, delivering new pages that then use the new stack with the new design system and the new technology. So it's a little by little, we believe that we're going to be done by the end of the year.

Ben (22:40):
And I'm curious, are there any, now that you've kind of gotten significantly into the middle of the project, any learnings or any things you would've done differently, had you known before going in?

Allen Chaves (22:51):
I think one thing is paying attention to that skillset, which is, it is very easy to say, "Hey, all our engineers are full-stack, which is good to start with, but then you start to see a specialization. So I wish I had paid more attention to that on the get go, which is how do I get people trained or hire people that have more experience with React? So they are used that paradigm of the code is running the browser, it's calling endpoint's on the server and it's completely disconnected. And then they stack, that involves React type script, etc. So that was a learning, I would have put some training in place and see that as opposed to identifying the problem later and then having to do it.

Ben (23:40):
I want to step a bit in a different direction for the last few minutes of our episode. So in your career you've been CTO of a couple of different companies, senior engineering leader at a couple of different companies, and you joined Klaviyo about three years ago, is that correct?

Allen Chaves (23:56):
Yeah, a little over under three years, yes.

Ben (23:57):
And when you joined, how large was the product and engineering organization?

Allen Chaves (24:02):
Yeah, so it was about 50, I think. Just the engineering. What I run is the engineering team. So I have somebody else who runs product and somebody else who runs design. All of us reporting to the CEO of the company.

Ben (24:19):
Well, 50 people still a good size engineering team. And I'm curious when you join a engineering team, that's already at some amount of scale, what is your process for getting up to speed and learning the tools and the organization, and building the relationships with the people. How do you think about all that?

Allen Chaves (24:38):
Engineering leaders, for me they have to pay attention to and be really good about three things. One is people in work, is about how you develop people, how you hire the right people, how you think about their work. Number two is, how is that you get better at the process of developing software and deliver customer value at scale. And then the third one is, I call it technology evolution, which is how is that you are thinking about the technology that you want, in a way that you evolving them, not only to react to a use case that came up or actually pushing the envelope to know to the boundaries what's possible. So when I join a company, I'm trying to learn all three aspects of this. So countless one on ones, which remain to this day, so I understand the people aspect. And I also have that report with the organization, I understand. It's not only about my direct report. It's about the entire organization, how easy they're thinking about this. That's number one.
Number two is the process. As you grow, we doubled the engineer organization every year that I have been here. And I'm going to double it again this year. How is that you grow by maintaining the culture of the company, which to me means autonomy to the teams, so they can be independent and develop what they need to develop without having to rely on many other teams. This is about API boundaries, is about understanding the context and understanding the mission that they have and how that aligns with the company. So this is all about, "Hey, let me understand how the process works here and how is that we can continue to evolve the process in a way that matches those principles."
And then the third aspect, really quick, is the technology side. Deep dives, as soon as I joined, I on purpose did not ask help in setting up the developing department. Of course I don't quote during the day, this is about me experiencing what the developers is experiencing the day to day, and being close to that, because the conversation is much easiest to be had if you are that close to technology, the developers I've seen day to day.

Ben (26:50):
And one of the things you mentioned that I thought was interesting is this idea of making sure you're delivering customer value at scale. So could you elaborate on that a bit?

Allen Chaves (27:03):
Yes, so what is it that makes engineers tick? We could say it's the technology, which is true. We could also say it's the coworkers, it's true. You're learning from them, but it's also about the ability to impact customer lives, and the more customers you impact the better. So this is about how is that we put something in place that allows developers to just iterate quickly. So this is about quality. How is it that I guarantee quality, so developers are not worried about breaking something in production? We have close to a million customers. If you are in that situation, any corner case will be exposed when you deliver code, unless you have a process that is guaranteeing the quality during the process. So it's this, what are the necessary safeguards, and they need to be low impact and low overhead, that allows developers to do what they like best, which is "let me see the impact that what I did is having on customer lives". And that is what we are searching for. Looking for at Klaviyo.

Ben (28:14):
Well, Allen, it's been super interesting learning about Klaviyo and really enjoyed our conversation. For folks out there who found what Allen was talking about interesting are, well, you already said you're doubling the size of your engineering team, so it sounds like you're hiring. What's the best way for folks to learn more?

Allen Chaves (28:35):
If you enjoy a culture where collaboration is one of the number one things that we do, that learning is something that you want to do forever, going to be learning from really great peers and contributing too... and you're interested in interesting technical problems, this could be large volume processing of events, it could be completely revamping our user experience, it could be developing services at scale that are used by then many, many developers, it could be infrastructure, we have a place for you at Klaviyo, because we are in the midst of really interesting projects as the company grows. The best place to find is we have our career website Klaviyo.com. You should be able to find it. We have all kinds of roles and labs of seniority, and we are really looking for great people. So please, give it a try.

Ben (29:34):
Well, thanks again for joining us, Allen.

Allen Chaves (29:36):
Oh my pleasure. Thank you.

Kate (29:52):
Thanks for listening to PodRocket. You can find us, @PodRocketpod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.