I'm joined today by Max and Sama from Temporal. Temporal is a durable execution platform, which basically means that they will help you make sure that certain processes always complete regardless of external factors at scale. We talk about why Temporal is so good at working with enterprises.
Started to get external adoption from a bunch of, big companies like Airbnb, Hashicorp, Box, Core and Base.
Why Temporal pays salespeople on consumption only?
They actually make money when customers actually are using product, and it creates a very good alignment.
And their tips for hiring great people.
Have clarity. Like, how do you excite someone?
Enjoy the episode. Snapchat were, like, using you for their stories to upload stories. Right?
Not to upload, to actually processing because yeah. Because as as as you I I'm not expert on Snapchat stories, but it's a it's a workflow. Right? It's practically every time stories upload, it needs to make quite a few API calls and guarantee that this API calls go through. Right?
So, yeah. So for us, like, is this team called Snap Discover, which basically, as Mac said, every time a story is posted, there is a temporal workflow, which is orchestrating a bunch of backend actions before that story starts showing them in other people's timelines and all of those essentially. So, and that's what helped our temporal kind of helped Snap achieve. So we are in the path of every story being posted on Snapchat.
Yeah. That's absolutely wild. Was it like was this scary the first time you turned that on?
Yeah. Absolutely. And then it's wild and then just now you can imagine essentially New Year's Eve how many of those stories are being posted essentially. So it's like it's in really insane scale also that you have to handle.
This episode is brought to you by Work OS. If you're building a dev tool, at some point, your customers are gonna start asking you for enterprise features. Work OS offers you single sign on, skin provisioning, and audit logs out the box. Work OS is trusted by Perplexity and Vercel, as well as Workbrew, a homebrew management startup that I recently interviewed. I just told Mike that WorkOS is the sponsor, and this is what Mike said.
Yeah. So WorkOS isn't paying me any money for this. I I pay WorkOS money for this, but WorkOS is, like, one of the best developer tools I've, like, ever used. It's the documentation and the experience with building with them is so so good. Like I initially was almost like, okay, this seems expensive. But then I built an integration with them in about twenty minutes that I had spent two days banging my
head off the wall trying
to build it directly with Octo. And then with Workhorse, I then have like many, many SSO providers like support instead of just one. So yeah, like, for me, Workhorse is one of the nicest developer experiences I've encountered in the last like, five years, probably. And it's so surprising because a bunch of
the developer team are ex GitHub and therefore very good at their job. Go to workos.com to learn more. I'm guessing from their point of view, it was probably like quite relieving to just hand it over to you guys.
Yeah. This is where probably the like one of the key value propositions of the platform is, yeah, you build your application and this is a platform which is kind of on one side, it's giving you an amazing developer experience for building those applications in a developer friendly way. But at the same time, it's kind of offloading a lot off of your hands, like scalability, reliability, resiliency, and all of those kinds of challenges, which developers spends like 80% of engineering eventually turns out to be not your business logic. It's about all of those guarantees developers have to build to run those applications in a highly scalable fashion in a reliable way. And this is where Temporal really shines.
You know, like every startup starts with a monolith, right? And then they, because all they care about proving their technology. So they are kind of building those systems and with a goal that The initial goal typically for them is to prove it out, find a go to market fit, and then start scaling those systems. So what typically ends up happening is all of the technical choices typically those startups make during the earliest phase of their career are really different because they have different goals in mind essentially. They prioritize things around finding the go to market fist or time to market and all of those things are much more higher than whether this thing can scale.
But then once they find that go to market fit and they start going into the scale mode, what ends up happening is there you are now typically ripping out the entire system you have built during the initial phases, and then now building it for longevity, reliability, scale, and all of those challenges starts coming in. And then suddenly this is where the entire focus of the company changes into keeping up with that scale rather than adding more and more value. The thing that drives me and Max is these startups, when they are really building their system for the very first time, they focus on, they don't have to rewrite it again. Like they build it, they once they find their go to market fit, it just scales for them, like, very smoothly underneath the covers, and they can offload all of those challenges to us and handle those as part of the platform.
Yeah. But I I
think it's worth mentioning that the reason they pick us at the first phase because it's actually faster to build with us. So it's not only about future. It's if you're building right now and you need to crack practically build application which guarantees I will be guarantees that your transaction or whatever you're doing will complete and requires resiliency, you build with it and you build faster, and then it can scale.
Yeah, because you have like the retries and the sort of all that like logs and stuff like baked in.
Yeah. It's it's not just retries. It's practically paradigm shift. Right? You you build your application as failures don't exist, and and quite a few failures don't even exist. So you just don't think about that. You focus on your business logic.
And, I know you kind of got started. You were seeing, like, the challenges that these big companies have. Right? Like, you both have worked for, I feel like there's not many big tech companies that you guys have not played a part in at this point.
Yeah. I've worked for Amazon for eight and a half years. I've been there twice, so, like, five and a half years and then three years. I was at Microsoft in between for a couple years. Then I spent four years at Uber. Sorry. At Google. And then I moved to Uber where I spent another four years. So kinda and I wasn't a small startup before that in the .com bubble days.
So
and, yeah, in the last five years, we've been building Tuporo from the ground up.
Yeah. And I have a very similar career trajectory as Max. Like, mostly spend my time in those larger companies. Like, I started my career at Microsoft, spend a decade there building mix of developer platforms, tooling and server products. And then I actually worked with Max in back in 2010 at AWS.
That's the first time I met Max when I joined the Simple Workflow team, which Max was leading there. Then actually ended up coming back to Microsoft Azure side of things this time for a couple of years. And then again got reunited with Max at Uber when both of us joined in 2015 within a month of each other.
Was that a coincidence or?
Complete coincidence, yes. Really? Yeah, we didn't stay in touch after I left the Simple Workflow team. The funny story there is I joined, I think in 2015, the Uber opened up a engineering office here in Seattle. And one of the things that attracted me there is Uber was starting started this journey on their microservices architecture.
And to a point where by the time we joined, like Uber was in this phase, somehow they ended up in a place where they had more microservices than engineers in the company. So building any stateful application back then requires orchestrating calls across dozens of those microservices. So that entire microservices architecture back then was powered by Kafka seven underneath the cover as the messaging backbone, and which was becoming challenging. So the Uber was starting to rethink like the messaging as a primitive back then. So that what's kind of pulled me in.
And literally the next month, I saw Max's resume. Max actually even has an interesting story on his side also, which I think you should hear from him. But then I went up to the hiring manager and said, okay. If you really want to build messaging, you need to hire Max, essentially. This is the person you want to bring in. Max, do you want to continue with your end of the story there?
Yeah. Actually, just to give some background, I worked for Amazon. When I worked at Amazon, I was tech lead for the team which practically built their PubSub platform, kind of all the back end, I think, cross communication. And it was well before Kafka was even conceived. So it was at the beginning of February.
And then this engine, the application, like engine which does replication for messaging and storage was used by the simple queue service, I think they still rely on the same design. We probably rewrote it 50 times already. But that kind of so frankly, I was in the middle of all these pops up craze and huge number of services which Amazon runs on the back end. And I was practically a fit for that. So I saw all these use cases.
That's why we realized that kind of just the kind of what we call these days event driven architectures is actually not a good way to build large scale systems at the back end. And we realized we need something like orchestration, and we had multiple iterations. But the third iteration actually ended up being as a public release of the simple workflow service at AWS. And so we worked with Samar there, was tech lead for that project. So and then, yeah, when I joined Uber, we kind of initially we hired practically to build a PubSub system to replace Kafka.
And we actually built project is called ShareMe. And reality what happened is Kafka eight came out and actually was much better product. And then just within Uber has decided to defund the project. So we didn't have enough fundings to keep building it to the point when it actually can be become like it actually 60 team were using that. So it wasn't a toy.
It was actually a production grade system. But at some point, we just moved to this new project, which was called Cadence, that was based on the idea of a simple workflow and where we practically started to think about orchestration, about how you build this doable system, stateful systems. And this is where oh, within three years, we've got over 100 use cases running on that. It was open source. We started to get external adoption from a bunch of big companies like Airbnb, HashiCorp, Box, Coinbase.
And then we practically started to be approached by VCs. We said, why are not starting the company? We actually just true. Me and someone never discussed starting the company before that. We just we are working on the open source project making it successful.
So it never was kind of immediate goal, let's say this way. We kind of yeah, maybe one day it becomes big because we knew it it has to be big because this type of approach and software was needed by everyone. So we clearly proved that that Amazon when we built simple workflow service, it was very widely used internally. Some are built a doable task framework at Microsoft, which durable functions run right now on. And so it was proved that it's ingenious Microsoft to like it.
And then at Uber, we've got so much adoption and interest. And we started so we clearly saw that this is something which can be used by the whole industry. Every company needs it. And we certainly decided to start a company. And it's been five years since then. And yeah, before the Cadence project now is too poor. It's still the same MIT license. So it's open source fully. There is no any shenanigans with the license. So the whole thing is fully featured that you can run it yourself.
Quite a few companies are still doing that.
Yeah. So that that makes sense. Because that was actually gonna be my question was like, how does it work when you kind of start a company based on like some open source work that you did at another company. But you basically just you just fork it. And then because it's open source, it's, you know, you can build a company based off of it.
You technically didn't don't need to fork it, but in that specific situation, we had all sort of legal and practical reasons to fork it. It's MIT license, you could keep the old one, you could fork it, but we kind of, we had to make this decision. One reason forking allowed us to do one thing, it allows us to do backwards incompatible changes because we, for three years at Tuber, we never made made a single backwards incompatible change. So we were running this at production higher scale for hundreds of use cases and without interrupting them, right. And when we say, okay, before can be like, oh, this is our only chance because we absolutely need to guarantee the same profitability.
And we've been doing that for five years since we started the company. But we knew that there were huge number of it thinks it's our chance. And we spent one year just creating our fork. Okay. Obviously, fork was fast. But when we got to the point, we said this is production first one or release is production release. It's blessed by us to be used in production. It took us one year since we started the
company. Yeah.
So we put tons and tons of features there. So and at some point, we kind of realized that we are we are kind of not convergent. And we practically had big kind of work on saying, okay, this is our release. We are not going to do any more changes.
Yeah.
Yeah. Before we release that, that was a challenge. And we didn't.
That makes sense. There's like kind of that balance between like, as soon as people start using it, you kind of like slow yourself down to some extent by like having to make sure that you're not gonna break things and stuff like that. But also, you don't wanna be doing that forever and not get it out there.
That is And we certainly in that year, the we had to do these changes in the backwards compatible way, it probably took us years. So that was certainly great great that we had this chance.
That's really cool. I felt like this is probably like the best possible way to start a company, isn't it? I mean, like, it it's it's such a, like, cheap not cheap, but, like, you know what I mean? It's like you've kind of I think you, Max, you said on a podcast, like, you had product product market fit before you even launched basically because you've just proven this thing. You've built it while you still have like salaries and stuff like that.
You proved it at a big company and then you go build a company from that. It's it's really smart.
Again, it's not that we had it all planned.
Yeah. Yeah.
But it ended up like that. I I think because we were super passionate about that. So we certainly been working on this space in this space for practically fifteen years or more. If you take our pops up background, so that kind of happened organically, we were trying to solve problem. And we found solutions.
And then when solution became successful, the super nice thing about the whole VC ecosystem here in The US is that it allows you to practically if you have something of value, and especially for so called source project, so it's very visible. There is the whole kind of infrastructure around that this financing can help us obviously, we have the best VCs in the world. And they help us lot, especially in the early phases, when we started to build the company. Neither means Samarit managed a single person until we started the company. Were 100% engineers all our lives.
Yes. When we left Uber, summer was staff engineer, senior staff engineer. And the same thing kind of Microsoft was principal engineer, but I never managed anyone. Some are the same. So we certainly had to learn on the job. So
Yeah. What things have you learned about I gotta gotta ask that. What what kind of things have you learned about managing people since you started Temporal?
Wow. That's been quite a journey for both of us. So as for I think, typically, I think another way that I would rephrase that question is, like, earlier phase of the company is, as Max said, both of us know this technology inside out. Like, probably more than half of the code for TAM portal for both back end and the client side experience is written by both of us essentially. So earlier phase of the of the company is, I would say the biggest challenge would be recruiting.
How do you get other people excited and bring those in? And for us to build a company, you need people. And by the way, both of us is being part of hiring engineers almost like large parts of our career. Even at Uber alone, probably we like when we joined the Seattle office, Seattle office was probably less than 12 people. And by the time we left, like, it was over 300 people essentially.
So we were actually very deeply involved on the recruiting side of things and building out the Seattle office for Uber also. But what we after starting the company, what the first thing we found out is that's literally tip of the iceberg. That part of involvement, like I probably I've been part of maybe 400 interviews at Uber alone, essentially, during my like four years there. But that was literally the tip of the iceberg. Like building recruiting muscle in a company, how do you build a strong candidate pipeline?
How do you build messaging to attract the top talent in those companies? And then building up a process to build an awesome customer, like a candidate experience while they are interviewing with you and all of that. There's just so much work that happens on the backend. So I think the very first problem that both of us ran into is recruiting, and it's been quite challenging during the early stages.
What kind of things do you think of like, probably, like, if you were advising another founder that was starting to, like, recruit outside of their network, especially, first of all, are there any things that you would say to them?
Have clarity. Like, how do you excite someone? Like, what's at the end of the day, what people are looking for is, especially when they are joining an early stage startup, is how they can go and have an impact. What does what is your founding story looks like? And can can you excite people on that founding story?
I think that goes a long way. And the other thing is, for one of the challenges that, me and Max ran into our earlier part of our, if you look at our career before starting the company is more about like these larger enterprises. So, we have worked with some of the top talent in the industry. But when you are starting, we're starting a company, especially in those early stages, it's a really different profile of people who get excited or attracted towards that essentially. And so initially we actually didn't had a lot of experience pulling people out of our own networks.
Eventually all of those people followed us later, but then especially during the very early stages, I think, your, what kind of network you have and then the profile for people that typically goes and take that high risk to join a startup is very different. Especially like we had little success pulling people from our network during the early stages.
Yeah, that makes sense. Because I guess like if people are working at like Uber, Microsoft, they're gonna have like amazing packages, probably be quite risk averse. Yep. And you're like, why should I walk away from this unbelievable package that I've got guaranteed to just take a chance on a startup. I hear about startups going bankrupt all the time. By
the way, it's not even about those early people, right? Even I was having this conversation with my partner that she was the first thing she is, okay, why are you leaving Uber to start a
course? Okay.
Yeah. So even it took me a lot of convincing why this is the right thing to do.
I feel like, honestly, working on the West Coast for a big tech company must be like as a programmer, must be like one of the greatest jobs in the history of, humankind. It's like fun, great rewards, like, you know, like, it's it's it must be one of the best jobs ever. So it's pretty hard to, like, get people. Like, if people are in that startup world, like, then it's probably easier to recruit, like, people that are already startup people, I guess, at the beginning.
And the interesting thing about our stories, like, you mentioned, like, oh, people working at Uber. Right? Like, one of the more natural fits for us was all of the people that working on Cadence along with me and Max back then, probably had like maybe 12 people team who was working on Cadence. No one came with us, just me and Max originally, But now probably, I think seven of the top 10 contributors to Cadence is now
here at Really?
Essentially. That's cool. So eventually those people followed, but it took a while.
Yeah. Do you think it was just like building up the trust that you're gonna be around for a while and that sort of thing?
Yeah. So people always by the way, like all of the people in our network has immense amount of respect for both me and Max as technical leaders. But as you said, like, people typically are risk averse, like starting a company, joining the company, there are nerves. But once people start seeing the momentum, the problem that we are solving, how how dominant, like, how broad it is. Like, and it is such a gigantic market opportunity in front of us.
Once they start seeing proof points coming out, that actually helped a lot for us to kind of pull those people in.
Yeah. And actually, kind of like to revert back a little bit, but still on the theme of trust. I think something that, you guys have done really well from the outside is like, you know, getting if you're like, get getting Snapchat for instance to like trust you on such like a crucial part of their infrastructure is like seems to me is just like an incredible achievement. And I guess I want my question is like, is one thing that people use like your open source project, but then another thing that they just like run their whole like infrastructure. They run-in key processes like on your infrastructure.
And I guess like, how how do you how do you kind of like work with these companies and kind of get them to, you know, trust you and to run real important things with with Temporal?
We need to kinda explain the what it means to run a lot of infrastructure because I think it sounds too scary to for people who don't understand. Because Temporal has architecture when we have SDKs libraries. Mhmm. So for example, if you're building Java application or Go application, you will insert just include dependency on the Temporal SDK. And again, if it's Java, it's just will be like Maven dependency, Gradle dependency, just jar in the Go, it will be just the package.
Right? And they built those as part of their application, and they still run the application. Right? The same way like as Kafka consumer and producer is not part of Kafka cluster. They're just part of your application. Right? Or code which use database. Right? The same thing. So we are just part of your application, and you run your application on your premises.
Right? You kind of run it in your VPC, you run it inside of your data center, you can run on your laptop if you're developing. And then the reason back end cluster, like a service, which contains persistence, queuing, durable timers, all these kind of things which Temporal provides. And this service runs on the back end. And our kind of current commercial offering is Temporal Cloud or only run that back end service for you.
Mhmm.
So what it means is that you as a customer of ours, you run it still run it yourself. You own your quote %. You don't need to ship any day. And then you ship data to portal, you can encrypt it using your algorithms and your keys. So what it means is that you yes, you need to trust that company, but you trust it to run that kind of service for you.
But you don't need to trust with you on encrypted data. So it's not like database, they never looked into the data, you don't need to kind of open any ports in your firewall, because you only need to connect to that service, usually for a private link, and encryption and your own the encryption. And I think this is important to understand, because it it kind of happened organically. And so that architecture, and this is where the kind of why we are able to not only Snapchat, but we have big banks, we have very large financial institution, we have like a lot of companies running on our cloud, because their security people look at this architecture and say, it makes sense. There is so much like, our goal is that to prove even if we actively want to hack you for our system, we cannot.
Right? And because because it's one thing to say, okay, trust us, we are good guys. We have all the certification. Sok to type two, we have them, but it's another one saying no, they trust your encryption. Yes, we do trust encryption, our encryption.
So then, and everything is end to end encrypted by you. So I think a lot of that trust came from Yes, as being good partners and being reliable and running the services, it took a long time to kind of people really start trusting us, mostly around the reliability scale. But I think security comes first always, because usually somebody you start talking, okay, you run into poor cloud, no, no, I cannot do that, right? I have API, I have all these security requirements. Interesting.
And then we explained the security model there. Okay, it makes sense. And then there is second step when we need to prove ourselves in terms of can we run this for you reliably? That's scary.
Yeah. That was actually I wasn't even thinking about the security part. That makes total sense that you would, you know, make that in a way that was like can like trustless. I don't sound like blockchain, but like, you know, just this sort of like, even if you wanted to, there's nothing you could do. But I guess like in terms of like the scale scalability and stuff like that, you know, that that's that's just like one thing that I would be thinking like, if if yours if you're Snapchat and then there's like a startup that wants to run, help you with things, like your first four, I obviously, I'm not Snapchat, but I would imagine their first thought is like, oh, yeah.
That sounds useful, but not at our scale, you know, because we're bigger than everything else, you know. They wouldn't even know what it was like to handle our kind of you know, that might be the first fall that they would have. Maybe not. Like, I'd love to hear from you guys, like, if it is like that and if you have to kind of prove that you can scale to that kind of level.
Absolutely. I I think one thing which has helped us there is a a few things. First one is just our background. Yeah. I was taking it for as I I was taking it for the back end for simple queue service. I was taking it for the AWS simple workflow service. Samar led what's the exact name of the team you led at Microsoft?
Azure Service Bus, like in the I worked on this technology for called Event Hubs, which is the large scale ingestion for Azure, essentially.
Yeah. So, Prakrav, we had, like, lot of background there. And then we ran this thing at Uber at scale for four years. Right? So this and again, if you look at them, a lot of open source projects, they start thinking about user, right, user experience, and the backend is kind of afterward.
And for us, because it was kind of few iteration of this project, in different companies, built, we built this open source from the beginning to be infinitely scalable. So it was kind of the just because it was again, few iteration. If we were building the first for the first time, we wouldn't be able to do that. And that's why we build this platform to be incredibly scalable. And all our lives we are running services.
This is how kind of what we do, right? We'd rather run large scale with distributed services, reliability for like within companies, and obviously database for like, when we're building those services for the world. So we had a lot of experience doing that. And we were able to prove to our partners that actually, it's not just like we have, they that's why they trust us initially. And obviously, initially means they get something random you and you do POC and you run it.
And then you get the trust, right? So like, Snapchat took us took them quite a time to, like, fully trust us for all the workloads. Right? So it's not just happens overnight. It's a lot of a lot of kind of it's after year or two or three most companies, we see that our kind of goal, and I think, and it's very beneficial for some companies with the goal will all in, when they start using us practically everywhere when there is appropriate workload.
And from the time like one or two teams in the company use us versus like, it becomes a standard for all new projects and maybe migration for existing projects, then it becomes completely different kind of usage and adoption path. But it certainly takes time, right? But from company learning about you experimenting with you to say, no. We can bet on this technology for every work.
Yeah. And this is the place where at all of the investments we did on proving ourselves to for a higher scale then for example, like Snap, who's been an amazing design partner for us during those early phases, helped unlock a huge market for us. For instance, like Yum brands,
which is Pizza Hut and KFC.
Well, essentially, like every mobile order is a temporal workflow that runs on cloud. So, the interesting thing is, like for them, before coming on temporal, the largest event for them was Super Bowl, essentially here Super Bowl in US. And eventually what they found out is their business was bottlenecked on their technical stack. And they have this thing called, Taco Bell had this, campaign that they run every Tuesday called Taco Tuesdays. Now after porting to over to Temporal, every Taco Tuesday is larger than a Super Bowl for them now, essentially.
Oh, really?
Yeah. And because that is a, that's the unlock that organization got, like, because what's finding what they are finding or the even their marketing teams were bottleneck on the technical capabilities of the platform.
Because like orders were just failing or what was the
Yeah, they couldn't just, they just couldn't scale large enough campaigns to basically handle the transactional volumes to handle those And so that's why I'm saying, like, all of, like, all of the investments on like, we have proven temporal. You do, like like, the unit of scale for us is what we call as state transitions. So we have tested temporal for a million state transitions per second. And we can even push it further if we want to. It's just that we've been running that test.
The cost of infrastructure became so large that we couldn't run
it like
beyond that. Yeah. But like we like, if there's a use case out there who's willing to tolerate that infrastructure cost because of the value it brings in, we can scale pretty far along essentially.
Wow. Do you guys run on top of like AWS or? Today,
there are two key parts to our system. One what we call as a control plane and the data plane. So when users are running their workload, it's mainly driven out of the data plane. So originally we started with AWS for running both control plane and data plane. Now we support GCP also. So now you can have a customer power their data plane out of either AWS and GCP.
Yeah. Okay. Cool. So you're as scalable as AWS and GCP are in the sense of like what capacity they have.
As as yeah, exactly. As long as we can get keep on getting more capacity and hardware, essentially, compute and storage from AWS or GCP, we can keep scaling linearly.
Yeah. It also allows us to go to multiple regions because we have customers which practically require the to have presence in multiple places, 10s of Amazon regions. So we, it helps us, because it's very, very common to say, Oh, my data cannot leave Europe, for example. Right. So you need to make sure that their namespace what we we kind of sell namespaces.
Their namespace, when they create a namespace, can pick a region and cloud provider. So it's very important for all this data governance. Because even if it's encrypted, right? There are laws which say this data cannot take, for example, Europe.
Yeah. GDPR and all that sort of stuff. Yeah. Great stuff. Yeah.
And actually, just digging in because I I just think this is really interesting. So I I know you mentioned that you'll do like kind of like roll outs like you'll start to say to people, just trying to run this part with, you know, with temporal and then like scale upwards. And then obviously, you guys have like the dream background of like, you know, you actually did this already, you've proved it, you've got the credibility. I was wondering if there's anything else that you kind of, any kinda like tips you have for like other founders that are just starting to work with these big companies. The kind of things that big companies care about that, you know, they may not have seen if they've not worked with these kind of huge scale companies?
So every company is different. Maybe I can start and then Max, you can share your experience there also. For us, essentially, the thing that worked for us, I think open source specifically played a big role for us because, like, especially for a developer product. And these engineers in those companies, they like to play with the technology before basically making a decision that, oh, this is a platform they are going to use for whatever problem or challenge that they are tasked with. So open source for us kind of played a very critical role for getting that broad awareness.
Or not only just broad awareness, getting an ability where people even just paying before even paying anything, they can try the technology, get a feel of the developer experience, get a feel of basically how they can run this thing if it needs to be in production themselves. And I think that kind of played a big role. And as you said earlier, that like both me and Max have been banging our head on this problem for almost like twenty years now, essentially. And so that credibility that we kind of brought in that, oh, these are the people who's kind of this is the fifth iteration of the technology stack they have built is seeing staying in that problem domain. So for us, I would say open source and the credibility and building similar systems in the past in these larger places were the two key factors that kind of helped us get that initial traction going for us.
I think one thing is also hire salespeople. Because because a lot of initial engagements were on a technical level, because we're engineers, we know how to talk to engineers. But these are complex organizations, right? We clearly saw that after we've got real salespeople who understand how to talk how to obviously just do paperwork and all these things, that good things started to happen much faster. So yes, and we have a super technical sale, right?
So our salespeople are not kind of like the car salesman stuff, right? Like they are all they are all about solving customers problems, right? One thing is, for example, they are compensated via consumption based service, right? So people pay for what they use. Yeah, our salespeople are compensated on consumption.
So they like they cannot go and like make a bunch of deals at the end of the year and get a lot of money right there. They actually make money when customers actually are using product and it creates a very good alignment. So we hear all the time from our customers that we find our salespeople super helpful, which is not common, you know.
Yeah. They can't just sell vaporware then, basically. They can't get paid for selling vaporware that just sits on the shelf.
Absolutely. Yeah. We cannot do
So not vaporware. Sorry. Shelfware. That's the word for it, isn't it? Shelfware. Exactly. Exactly. Yeah. Yeah. That's really cool. And then what what are like you know, like, I felt like sometimes some my, you know, developer friends, don't always understand that, like, salespeople, it's actually a skill and there's actually a lot to it. And what do you see the best salespeople at Temporal? Like, what kind of characteristics and how they work do you see?
One funny anecdote is we do these surveys with our customers where we have them rank essentially like different parts of the organization that they interact with. Sometimes for example, even our engineers at temporal, they are pretty involved. If you go to our Slack channel, it's like the even Max all day, essentially sitting in Slack and answering customer questions.
Go Max.
And so we have them rank different organizations here at temporal that they have interaction with, like, and the organization that ranked the highest was our sales organization.
Really? Yeah. Wow.
That that and as and I think all of that is because of the alignment that Max mentioned is we have very technical sales. We are a very technical product, but I think the alignment that we have created that we are successful or those sales person will be successful if our customers are successful. Because that's why they are driving consumption on top of the platform is that they understand the technology, understand the value proposition of the technology. And then they have built an application on top of us and which is like functioning properly and then driving consumption. So there is so much upfront work that our salespeople do and then consumption is the most lagging indicator of that essentially.
So that alignment that we have created is just like is this is what I think like the all of the results into the interaction that our sales have with our customer base is because they are fully aligned. They are just figuring out like being there. It's not they are not there kind of just sell stuff that what they don't need essentially. They are genuinely there to understand what are the problems, what are the challenges they are facing, and then how they can be helpful to solve those challenges. As long as you create that alignment between customer and sales, I think that's what that's what defines sales here at Amparo.
And it brings different people. Right? It just also brings different people. Right? So the salesperson who is not good at that, right, who doesn't want to kind of walk very long time to kind of make sure that customer is successful.
And because it is a lot of work, they just don't join, right? They these are different type of salespeople. These are salespeople who care about like, it's it's a kinda nurturing these relationships. Yeah. And it takes time, and it takes effort, and it takes a very different kind of skill set. So, yeah, it certainly attracts very different type of people as well.
So, like, they call it, like, hunters and farmers or something, don't they? And the the game of, like, this, like is it what kind of mindset have they got?
Yeah. We we have we actually have both teams. We have teams who we are quite close new logos, which are hunters, and they still have the same. It's because, again, you don't close the deal and just for the sake of it. Right? You solve for real problem. Nobody nobody will sign up for a new vendor unless there is a good use case. Right? Yeah. And and this the same thing for new logo team, they still need to find workloads.
They still need to make sure customer success from production. It's not just, doing paperwork.
Yeah. The only difference there would be new logos team, like we incentivize them. Okay. The initial land of a use case, the size doesn't matter as long as you are bringing quality logos or customers essentially and make them successful on us. That's what they care about. But then we have the growth team which is driving more awareness, more education, more activities in those accounts to drive much more broader awareness to for us to win win more workloads or do expansion in those accounts.
Because having new logos is like you're banking that if you get someone with their foot in the door, if you get your foot in the door that eventually that will lead to like a lot more down the road.
Yeah. I can give you an like, let's say a larger organization like Microsoft, like if a developer there, like, is already sold on temporal, but then the friction which exist on those organizations to bring a new vendor in is so large typically that the developer says, oh, let me run it myself. Like I don't want to go through the process of dealing with procurement, legal and all of those things to bring on a new vendor. So so that's why for us new bringing on new logos is a lot of work, but every time we close those especially those strategic logos, then temporal becomes a vendor. We remove that friction in that organization.
That's huge. Okay. We're coming towards the end. I just wanted to ask one last question on on that. Like, Samar, you mentioned that, like, you have, like, technical salespeople.
And I guess, like, my question is, like, it's like a definition of a technical salesperson because obviously, like, that you have, like, a great spectrum of, like, what technical means, you know, like so I kind of wondered, like, what level of, like, technicality is, like, really useful, you know, like, what kind of stuff?
So I can give you a little bit of structure how sales is organized, and then then there are different people who play different roles as part of that structure. Is so we have, of course, like sellers Mhmm. Like, which is account execs and which are supported by what we call as solutions architects, which are like literally the majority of those solutions architects are actually heavily coming from a developer background. Interesting. These are the people who are actually build like massive applications themselves.
But at some point of their career, they decided that they want to be part of like selling rather than building new software essentially. And because they want to they love those and the profile for those people are there typically love just talking to users or customers and solving their problems essentially. And so account execs and these solutions architects typically tag team. Whenever we are have an opportunity going with a customer, these are the two people that tag team where the account exec is kind of playing more of a role of a quarterback essentially, who's kind of navigating or who figuring out what's the organization, who's a good key decision maker here, and kind of orchestrating which are the team which is interested. So this is a team which is kind of running the strategy, but then the solution architect is the one who is kind of supporting that by providing technical.
These are the people who can go technically deep, even to a point where even help those people do code reviews, design reviews, figure out POCs and then help build those POCs along with the customer. And then we have a third part of the organization, what we call as DevSecxess. DevSecxess, typically the way it runs is provide support and it runs like post activities also. Is like once an account is now there's an application build, and it's now running on top, how do you support those? And if more questions or things comes along the way.
And so these are the people who are kind of now backing up the field teams once an application goes in production. So kind of our posture, sales posture kind of mainly consists of those three organ like three different kind of personas dealing with both presale and post sales part of the customer journey.
That's really, really helpful to understand actually. Yeah. Okay. So guys, I just wanted to ask you last question before we do a kind of wrap up. But are there any dev tools that you're very excited about outside of temporal or that you just started using that you wanna give a shout out to?
I think AI stuff is certainly something which is interesting. I think in its current incarnation, it it's useful, but not super useful. It's still kinda very smart autocomplete in most cases, at least what type of application we are building. But one thing I see is that there is this low code, no code movement. You know that.
Right? It's been around for a long time. And we have tightly involved in that because a lot of low code, no code projects and companies use temporal as a backup. Right? So you can you're building your local application, you want it to scale and run the library, the temporal is the best technology to make your kind of local or no code application to run at scale with minimal effort.
So we have a lot of customers and users in the open source who are using that. So I see the AI is kind of this new low code, no code of my my camera x on hands moving to smart, you know, AI. Yeah. So and the the idea is that these these days I see I've been this kind of replacement for local no code, because it can generate kind of business logic pretty easily. And nice thing about this temporal there because temporal practically what we never said actually what temporal is, right?
Temporal allows you to write your business logic directly. And we take care for practically reliability concerns. So your application doesn't need to think about how to make your application reliable. And this is exactly what AI is good for, right, to write your business logic without thinking about other things. And, so we see a lot of conversions there. So, yeah, I'm excited about kind of next generation of local, no fault tools based on AI. Let's say it's
Super cool. Super cool. Thank you so much, guys, for joining. That was really fun. And, yeah. Thanks, everyone, for listening.
Thank thanks for having us.
Thank you.