Video size:

0:09 Miko Pawlikowski

Hello and welcome to another episode of Conf42Cast: Your Podcast From the Neighboring Galaxy. My name is Miko Pawlikowski and today my guest is Ganesh Datta, the co-founder and CTO at Cortex. How are you doing Ganesh?

0:24 Ganesh Datta

Great, how are you?

0:25 Miko Pawlikowski

Doing great. Thank you so much for coming. And for those who are watching on YouTube, this is a really cool hoodie. I recommend trying to get one.

0:34 Ganesh Datta

Thanks for having me.

0:36 Miko Pawlikowski

No worries. Alright, so our little tradition. First things first, if you could live anywhere in our Solar System, wher would it be?

0:46 Ganesh Datta

Yeah, so I did spent some time thinking about this. I think the engineering, pragmatic side of me would say Earth, for logical reasons. But you know, for the sake of the question, in the spirit of the question, I would say Jupiter. And that's mostly because of my fascination with it. As a child, I thought it was like the coolest planet ever. And I was like, obsessed with drawing it. And so I think if I had a chance to live anywhere, it would absolutely be Jupiter. And I would love to fly into the storm of, you know, the great big spot, the red spot. So I think that would be my answer.

1:21 Miko Pawlikowski

That is awesome. We haven't had that one before. Who do you want to be when you grow up? Jupiter. That's new. Alright, cool. So your passed, we can carry on. So let's talk about Cortex. It's obviously your thing, it's kind of all over there. I can see it on your hoodie. What's up with that? How did you end up starting Cortex?

1:46 Ganesh Datta

Yeah, definitely. So before, before I started Cortex out as this company called LendUp, as another YC company, and then we kind of split off into the other company called MissionLane. But one of the things I got to do there was be very closely involved in our journey from a massive monolith to more of like a service-oriented architecture. You know, starting from the very first service, we pulled out, all the way to around 60 to 70 services by the time I left. And you know, as we went through that journey, I think, obviously, the organization learned a lot of things. And some of those things was that it became very hard to know what services were building, what they did, what each team owned, just kind of what was out there in the organization and the architecture and how they interacted. But also just, you know, basic operational things, like, who's the owner, who's on call, or the run books? And I think, you know, every engineer has had this experience where, you know, they're paged at 2am, that wake up and like, they see this alert, they don't know what's going on. They're kind of scrambled through Confluence pages, trying to find the right things. And that's never the best experience. And you know, you're groggy at 2am. And so I think these are the things that we first realized, like, there's got to be a good solution for this. And so I remember, I was grabbing a beer with my other co-founders, and they were at Uber and Twilio at the time. And obviously, those are, you know, big microservices shops, who were being like kind of the classic microservices story. And I remember asking them like, 'Hey, like, you guys must have a solution for this. What do you guys do?' And they didn't really have anything internally, like they had the same wikis and Uber had built some internal tools. And that was kind of the inspiration for, hey, what if we build something that was, you know, where services were the first class that is in you could track these kind of operational things and ownership things about your services. And that eventually kind of morphed into, now that we have this information, services, how do we help you define best practices and standards and bring an end to all those spreadsheets that I think every engineer have seen the tracking all your microservices and ownership on stuff? That's, that's kind of the journey of how Cortex first started.

3:43 Miko Pawlikowski

Okay, so that's a shift. I guess, like you mentioned, you went from microservices and then turned out that it's not all just unicorns and rainbows, you actually introduced some other problems by solving this one. And you decided to do something about it. That sounds like a good, good answer from a co-founder of a company. So let's dig a bit deeper into that. So I understand you mentioned a few things, some graphs and ownership tracking. And I went through your website, and there seem to be a few kind of interesting ideas that I haven't seen before, like scorecards and initiatives. That kind of seems like maybe it's trying to replace JIRA, but not quite. Can you talk a bit more about you know, what's actually unique about? Is it just like a better spreadsheet? Or, you know, what was it that you actually have as a unique offering?

4:38 Ganesh Datta

Definitely, yeah. I think there's a couple different pieces to it. The first thing is what I just talked about, and I kinda like that personal pain point, which was just understanding what was out there. Using a common issue is you have microservices named after Game of Thrones characters and some new engineering have no idea what you know, Iron Bank is or Bravo says and you have to ask an engineer. And by starting with just a catalogue of, what services do we have? What do they do? Who's the owner? But then once you have this, I think there's a lot you can do with that. And so scorecards was kind of like the next generation of Cortex where we said, you know, every engineer has been on both sides of this equation, where there's a spreadsheet or managers asking to fill out certain rows, like you're trying to do a production audit of are your services production ready? You know, you're trying to do like a security audit, things like that. Migrations from one language version to another, you always have these spreadsheets. And I think what happens, I think it's kind of relevant to where we are right now, like SRE conference in SRE focused is, the SREs kind of become the bad guys, right? SREs are going after people, they're trying to say, like, 'Hey, your services isn't production ready yet. And you know, here's our checklist'. And you're like, 'I've never seen this checklist before'. And or you have to, like, fill out some fields. And so I think the first question was, how do we take this concept of production readiness or service quality and make that an objective thing? And so scorecards, basically are a way to define a set of rules for your best practices, and Cortex will go in to automatically score your services against that criteria. So you can say like, 'Hey, every service before it goes into production, it needs to have high code coverage, test coverage. It needs to have ownership, runbooks dashboards, it needs to have on call rotation with three escalation levels'. So you can define the standards and Cortex will go in and actually evaluate all of your services against this criteria. So now, it shifts the conversation from being like, 'Hey, here's this checklist that's very subjective' to, 'We have our predefined set of standards'. And this is something that, you know, we are now scoring objectively, and we can have a conversation saying, like 'You're missing these particular set of criteria'. And so that's kind of where scorecards comes into play. It's kind of gamifying service quality and the standards, and then, more importantly, automating that away, so that I don't have to go and fill the spreadsheets and do those things. And we're hooking into all your tools and all of your plumbing. So we're improving our profits for you. And so initiatives is an interesting addition to that, where we realized that these scorecards were aspirational. So in any given organization, your production readiness checklist could have like 15 to 30 different things. But no service is likely meeting all those things. It's like, if everything was great, and everybody was following all of our standards, we would be a 100%. But the reality of the situation was, you know, some services are at one end of the spectrum, and some services are still kind of starting that journey. So how do we get our services across the finish line? And so initiatives are this way of saying, 'Hey, as an SRE or an engineering manager, don't create a bunch of JIRA tickets and go and message people on Slack and beg them to do these things'. Just tell Cortex like, hey, this quarter, we want everybody to set up a one conversation for that service. And Cortex, based on the service ownership which we have in our catalog, will assign those things automatically to people saying like, 'Hey, as a service owner of this particular service, we noticed that you're missing an encore rotation, why don't you go and fill this out?' So now we're going to make that more of an actionable thing and bring service quality kind of front and center. So that's kind of the idea of the product as a whole.

7:58 Miko Pawlikowski

Right. That makes a ton of sense. But like you mentioned, the initiative, the scorecards being a little bit, you know, aspirational. It makes me think about things like Linting, when you know, your text editor choice, where everybody has their own opinion, or multiple opinions. And so how do you deal with, does it come with a predefined set of 'Oh, yeah, you shall do things like this'? Or is it more like, 'Okay, so let's just try to figure out some best practices that work for us?' Are you in the business of giving advice, or just giving tools?

8:36 Ganesh Datta

I would say giving tools and I think that's reflected in the way we've built the product. So when we built the scorecard feature, we built our own language to go with it, called CQL or Cortex query language. So essentially the idea is, your best practices should be expressive enough to cover the broad spectrum of all the tools and methodologies that your team is using. I think there're some things that are like Linting, like you mentioned, that are very opinionated, that's kind of your own thing as an organization, and block your pull requests on that. But you know, within the organization you might have some people are using Java, some people are using TypeScript, some reason Golang. So how do you create a scorecard that's like one size fits all? Because you don't want to end up in a situation where, you know, a service can only ever hit 70%, because you have, you know, 15 rules, and three of them are meant for other languages that are really relevant to your service. And so CQL lets you write these things which are like, if you're using JavaScript, you need to have a package lock file. If you're using Golang, you need to have a GoSome file, like some basic standards that everybody should be following. I think those are the things that scorecards really capture are those things that no matter what tool you're using, no matter how you're building your services, there are some set of like underlying best practices that everybody should be following. Like ownership and runbooks and, you know, language tooling choices, package versions, basic things like that, that everybody should follow. And so I think scorecards are a great way of encapsulating those kinds of things into a single score and CQL lets you be very expressive about those things as well.

10:01 Miko Pawlikowski

Do you think of the aspect of gamifying that, giving it a score, is actually working in the favour?

10:07 Ganesh Datta

Definitely. I think that was a theory that we had going in. And it's been really cool to see that playing out. Because I think by nature, a lot of engineers are a little bit competitive. We like these kind of like gamify things.

10:20 Miko Pawlikowski

Just a little bit.

10:20 Ganesh Datta

And I think that's just who we are. And I think scorecards kind of plays into that just a little bit. And we've seen that with some of our customers where like, the top 10 services are all owned by the same team, because they went in and like they fixed all their services and like, look at us, like we have 100%. And I think we're trying to lean into that a little bit as well. Like, we're trying to do like leaderboards like, show off your teams that are doing the best or giving out badges on your Git repos that say, like, I have 100% on my scorecard. So I think we've definitely starting to see that play out in our own customers. And that's been a really, really cool to see.

10:51 Miko Pawlikowski

Right. And I'm thinking, I can see at least three reasonably distinct groups of people that would look at this things differently. Like developers would be one group, SREs who actually run that thing and who gets called when things go wrong. And you know, obviously, the leadership does just there to at least have some kind of best practices in place to give the path. So do you think like the product is kind of received differently by these different groups of people?

11:18 Ganesh Datta

Definitely, I think it's very interesting that you bring that up. Because internally, that's something we talk about a lot is, I think, Cortex is unique in that it's a first tool where you're trying to bridge the gaps between these three different personas. I think a lot of the time, like SREs are tasked with reliability, but they don't really have the same level of context and all the micro services that a developer does. And so there's this kind of tension between each of these groups. And I think Cortex, we see ourselves as being this tool where we can bring them together. So I think the way we see this are, like SREs have their set of standards and best practices to try to get people to care about reliability. And so to define the scorecards. And so that's kind of the first piece of the equation. Then you have developers who are on the other side, where they're getting hounded to fill out the spreadsheets and stuff. And now Cortex is giving them a way to say, 'Okay, look, Cortex automated all this, our scorecards are up to date'. But then also like being able to create new microservices using cookie cutter directly through the Cortex UI or operating my services through the catalog. And the developers kind of get the value out of filling out the information, the scorecards. And so finally, the third leg is like engineering managers or leadership. So for them, they're like, 'I don't care about my individual microservices, like I don't care about Bravo's. I don't know, what does. Just tell me like, are we improving as an organization? Like, is there something that we need to be investing in? Like, are we just doing really poorly on call health and we should be investing in that?' I think scorecards now gives them the visibility to saying, 'There's this particular thing that we need to be focusing on across all of our teams, just tell me what that is'. And so I think everyone gets a little bit of value. And I think Cortex is that interesting tool in the middle where we're trying to pull all this stuff in. I think it's a hard problem to solve. But I think that's what's exciting is, you know, engineering as a whole, and it's kind of a philosophical thing, I think ngineering as a whole is very mature, but also immature, in some sense, from a tooling standpoint. Because you have like Salesforce for salespeople, you have Marketo for marketing people, but like, what do engineers have? So I think Cortex is getting that tool now saying, like, 'Hey, we're going to be a platform, where you can just do software engineering, no matter who you are, but what function you have, that's going to be your tool'. And so I think our mission really is to like, bring those different functions together into a single place. That's what really excites me personally about Cortex.

13:27 Miko Pawlikowski

That's really cool. So you keep going back to the Game of Thrones naming. I wonder, like, if you were to plot the graph of number of things named after Game of Thrones, and then you have the steep decline after season eight.

13:41 Ganesh Datta

I'm sure that's a thing, yeah.

13:44 Miko Pawlikowski

All right. So tell me more about... I also saw that you're kind of venturing, it looks like a little, you know, step in kind of a similar direction. But not just the scorecards, but actually templating services out by giving the tools to Go and Bootstrap something. Appears to be Python cookie cutter for now? It's kind of like what the clients want us the next step after you've given them scorecards? They were like, 'Oh, yeah, now we'll make it easy to make them look similar'?

14:10 Ganesh Datta

Yeah, I think that was also like a very full SecOps philosophical thing for us. So I think the choice of cookie cutter was because we want to make sure we're using open source underneath the hood. Like we don't want to lock our customers into some sort of proprietary tooling that if they ever want to migrate off, or they want to make more complex, they can't do that. So I think cookie cutter is kind of like an industry standard. And we wanted to invest in that. And so that's kind of why we went down that route. But generally speaking, I think templating is something that a lot of organizations are kind of ignoring in some sense. That I feel like a lot of companies will get value out of, because I feel like a lot of people spend time in defining your Production Readiness Standards, which are, you've built your service. And now let's check off a list of things. Or a lot of people spend time like copy-pasting the same CI scripts and deploy pipelines and all this stuff, only to be told afterwards like, 'Hey, you're not using the latest version'. But why not bring those two things together and say like, 'If you follow our golden path, then you get everything for free. Use this template if you want to create a, you know, a new Golang service, you're going to get the latest and greatest CI pipeline, you're gonna get the latest and greatest deployment scripts. And you're going to be following 80% of our Production Readiness Standards from day one'. So I think there's like this opportunity for organizations to invest upfront and say, 'We're going to give you the tooling, we're going to make it easy for developers to start services and reduce burden on developers and SRE to maintain Production Readiness Standards. And it's kind of like the golden path forward, like, you're gonna have the flexibility to do whatever you want. But if you use our set of templates that we have defined as an organization, then you're going to get all the support for free. So I think, like for us, we kind of view that as a next generation of what microservices tooling is, let's make it easy for developers to do the right thing. As opposed to like beating them with a stick afterwards and be like, 'Hey, you did the wrong thing'. Why not help them do the right thing from day one? So I'm super excited about that. And I spent a lot of time on that in my previous job as well. Just because, you know, I think as the engineering organization grows, and you're bringing people on, you want to make it easy for people to do the right thing. And so I think it's gonna be very, very powerful.

16:14 Miko Pawlikowski

Yeah, and I think, from my personal experience, every place kind of slowly evolves this best practices and their own bootstrapping, and you know, cookie-cutter style. This is how you start a new thing. So I'm curious, if you can talk about that, is it something that's been primarily picked up by big companies or small companies? Who's like your primary user base for this kind of tool? Curious.

16:40 Ganesh Datta

I think for templating, I would say it's for organizations that have a 100+ engineers -ish. Kind of like the main target. It's been interesting, because we actually thought it would be the opposite. We thought that smaller organizations who were starting to adopt microservices, we'll be using templating. But I think the learning was, they don't know their patterns yet. But larger organizations have people doing all kinds of crazy things. And so they're like, 'Okay, okay, please, like let's do everything the same way'. And so they're investing more in templates, which was an interesting learning for us. But I think longer term, we want to make it easy for like smaller companies to use templates as well. But it definitely have been kind of like the larger, faster growth, like organizations that have already adopted microservices, and are now trying to tame that, like chaos they've created essentially,

17:24 Miko Pawlikowski

What the book Cortex as you know, the whole. Is it also for medium+ companies that tend to get the most value out of it?

17:32 Ganesh Datta

Yeah, I would say the sweet spot for us is definitely like, once you hit 100 engineers, it's like a burning pain, like, 'Oh, my God, I have no idea what we're building anymore. We built the three of the exact same HTML to PDF converting microservice. And we need to like stop doing this'. But we've definitely seen like a lot of earlier stage companies like 20, to 30, engineers who are about to hit that inflection point are starting to grow. And like they're trying to be proactive and say, like, 'Before we get to that point, let's get our proxies in place. Let's make sure we have a handle on this side. Once things start to accelerate, like, we're not trying to figure that out when it's too painful'. And so I think people are starting to wake up and say like, okay, this is one of those key tools that everyone should have, kind of like APM, logging, metrics, telemetry. Like this is kind of one of the things you should have. So I think as the market matures, we're starting to see like younger and younger organizations who are adopting this.

18:24 Miko Pawlikowski

So shifting gears a little bit in the interest of balanced journalism. What's your take on the east to, was it monoliths to microservices to monolith again, kind of 180. I'm curious, you know, as someone who is obviously trying to make microservices a bit less of a mess.

18:42 Ganesh Datta

I think people moved microservices too quickly. So like, for Cortex internally, we are monolithic shops. So even though we're helping organizations with microservices, I think there's a lot of value in having a monolith. And this is kind of like my engineering philosophy as a whole, it kind of goes back to like premature optimization. And like, obviously, engineers don't like process and all this stuff. And I think it's almost in the sense of like, don't solve a problem until you have it. And then once you have that problem, you know exactly what the pain points are and you can solve those specifically. From the engineering process standpoint, but I think it holds true also for like monolith to microservices. Because I think what happens is, as you're building a monolith, you start to realize, for example, hey, this thing is something we're investing a lot in it starting to bleed over, like the logic's starting to bleed over. Why don't we pull this out into something else? And so I think drawing those boundaries is more useful. And I wish more people use like service-oriented architectures with like macroservices, as opposed to jumping directly into microservices from the get-go. I think it builds those muscles as an organization. I feel like, if you've done a monolith, you don't have the muscles yet to build microservices. So instead, build those muscles as an organization, which means being able to deploy faster, being able to build separate pipelines and monitor those things and build up your tooling that way. So start by pulling out specific macroservices from the monolith and then build more of an SOA, and then pull out the individual functional components to microservices, as you learn. I think the switch back to monoliths is kind of an overreaction. And I think this pendulum will shift back to the right balance. I do think the balance is some sort of like a macroservices with a set of functional microservices surrounding that is where I think the world is going to go. Just purely as a function of like Conway's Law in which, you know, like the organization, the code reflects the organization, I think we can get away from that. But that's kind of where I see the world shifting back towards is like, we're still gonna have macroservices, but maybe not as many as we've had in the past. But we're not going to go all the way back to monoliths

20:35 Miko Pawlikowski

Fair enough. One thing that I noticed, as I was kind of following your digital trail for Cortex, is that you seem to have started late 2019, meaning that you've basically been building this in the COVID world. I'm curious as to how that actually affected, well basically everything, from hiring to sell into, you know, anything and everything. Can you talk a little bit about that? I'm very curious.

21:02 Ganesh Datta

Yeah, definitely. So we raised our seed round, like literally like two days before the lockdown started in San Francisco. So we never even had a chance to like, think about opening an office. But what's interesting is, when we first started, we were all kind of believers and the serendipity of having conversations in person and like the, you know, the value that that kind of stuff brings. I think that was a big worry for us. But I think it forced us into having more structured processes. Not so much of like, 'Oh, we're doing sprint planning and grooming and like all this kind of like heavyweight agile stuff'. But you know, for foundational engineering, work building, writing tech specs, which maybe a startup doesn't do. But I think that kind of forced us into these conversations where we'd have like brainstorming sessions and figuring out systems that work for us. And I think that's been super valuable for us as an organization. Because we're ready as we add more engineers, like we're not scrambling to figure out how we're going to work together. I think that's actually been super valuable for us. And in this hiring market, being able to find people who are all over the place, I think is super important. And for me, personally, I moved out of the Bay Area, I've been kind of doing a wandering thing, and I'm in Redmond in Seattle right now, I'm going to be moving to San Diego in two weeks. So I think that's been awesome. But from a company building standpoint, I think there's a couple interesting things. I don't know how much detail you want to go into. I'm like happy to talk about some of the processes that I think have worked for us. From a company standpoint, I think it really worked in our favorite for sales, because pre-COVID, will be running around doing demos in person. And I think, post-COVID. Now all of our demos are virtual. And I think that adds a lot of value to our customers, because they're like, 'I just want to know what this is about. Let's get on a zoom call and learn about it'. We can do like three checking calls really quickly. And so that we can like kind of iterate to like the value that they want to get. And for us it means we can, we have customers all over the world. We have customers in India, Europe, the US, Latin America. So for us, it's opened up a whole new world of possibilities where before we were targeting very specifically like companies in the Bay Area where a certain demographic. But now it's like anyone and everyone, like we're we can work with you. It doesn't really matter. I think it's actually done us wonders. And it's not something that we expected going in, but it's been a pleasant surprise.

23:07 Miko Pawlikowski

Well, I was waiting for the mention of 'Oh, and then we started using scorecards to do our own scorecards and it got all the way better'. I've done the plug for you.

23:16 Ganesh Datta

We definitely definitely are. And I think it's going to be more and more. We have our own cookie cutter templates now for libraries that we're building internally. So that's been exciting. But yeah, I think it's most been awesome. I think like the serendipity thing. I think it's been a concern for a lot of engineers and engineering leaders and stuff. But what's interesting for us is we've had to find solutions for that. So obviously, you're not going to have you know, the same like watercooler conversations, but it's important to create those opportunities. And I think we've done that in a couple of different ways. I think having happy hours, you know, every week where you know, everyone's gonna get together and congregate and talks and has fun. We've done like our first quarterly off site as an organization where we all met in person for the first time which is awesome. But more from an engineering standpoint, I think one thing that's been awesome is giving a little more structure to the process. So for example, before if you're in person, you might all just sit down in a room with a whiteboard, and start designing your architecture that way. But that's going to be super high overhead now. So instead what we do is for example, we have an engineering team kind of come up with like a bare bones tech spec, and then we set aside an hour so that way our conversation is more centered around, like 'Hey, we have some ideas, let's noodle on these and see where we can take it'. So we're giving a little more structure so that the hour that we have in this zoom call has like more meaning and more value. And so coming up with things like these where we can like really maximize the time that we have together I think has been super important and I think it's been brought a lot of value to the organization as a whole. So it's been great and it's definitely scary in the future like how it's gonna look, but I think we've committed to being fully remote and I am excited for what that will give us.

24:51 Miko Pawlikowski

This awesome. Fully remote US-only, or do you actually have people in different countries too?

24:56 Ganesh Datta

Currently US-only but it's mostly a matter of time zones, I think, we don't want to hire people who are like more than three of four hours outside of the time zone. There is still value in having some synchronous conversations at our stage. I think as the organization grows, like building more asynchronous processes will be important. But for now, like I think this is the best of both worlds is remote with some level of synchronicity through meetings and things like that. But time zone is kind of the main thing for us, as opposed to like geographic location.

25:23 Miko Pawlikowski

You guys hiring?

25:24 Ganesh Datta

We are hiring very, very aggressively.

25:26 Miko Pawlikowski

Alright, go to...

25:30 Ganesh Datta

cortex.io, our new domain. And so, we're looking for account executives to help us with sales, we're looking for senior software engineers who want to get their hands dirty, and help us scale and build engineering culture and looking for solutions engineers help our customers. It's all across the board. Super exciting times

25:46 Miko Pawlikowski

Does it include a hoodie like that? That's important.

25:48 Ganesh Datta

Yes, it does include, it does include a hoodie.

25:51 Miko Pawlikowski

I think my wardrobe has been really sad. I haven't been to a conference for like two years now. So I have no new T-shirts.

25:59 Ganesh Datta

We can send you a Cortex T-shirt.

26:01 Miko Pawlikowski

Thanks. Alright, so can you just very briefly touch upon, because I think that's interesting especially for our Europe-based listeners, the experience of Y Combinator. This is something that, you know, we keep hearing about here in Europe, but it's slightly different culture. So I'm curious, like, what your experience has been with the accelerator? And, in general, what was the best and worst thing so far as being a founder?

26:25 Ganesh Datta

Definitely, I think Y Combinator is awesome. It's been, I think part of the journey is realizing that other founders, who were kind of going through this journey with you, provide a lot of support. Not just like, emotionally and like getting where you are at, but also being able to help each other and say, like, 'Hey, like, we just figured out this thing for sales. Why don't you try XYZ, and then we can iterate and kind of teach you there those things'. But I think what was really cool is seeing people, I think that's why member has grown, we have people from all over the world and like the international component is growing and growing, which is really awesome. Because you got to see everyone's different experiences and how they're solving differently for their specific markets and stuff. But I think it's almost like a crash course in Silicon Valley culture, which is, you know, like iterate fast, build things, get it out there, get in the market, and like that, like hustle-bustle energy of like, everyone's kind of building and releasing. And I think that was super exciting. And honestly, it gave like a lot of accountability for us that your group meetings, your other teammates or other people in your group are doing all kinds of crazy stuff, you're like, oh, man, we got to do stuff too. And I think a lot of that value comes from having that kind of support network. And that energy that a lot of people are kind of building things. And especially if you haven't grown up around, like startups, and you know, are not super familiar with kind of like the terminology or like, you know, how like fundraising works and stuff like that. I think Y Combinator is amazing to say, 'Here's how the valley works. Here's how technology works. Here's how you fundraise, how you build a startup, here's what hiring means'. And it kind of just give you all this knowledge, like a fire hose, which has been, which is awesome. As a founder, the best thing for me has been, like just being able to work on a product that really excites me and how like full ownership and share that with our employees and have them kind of join this journey and get that excitement. And see how customers are like adopting this product, I think has been everything I've ever wanted from doing the startup is building a product that people loved. And being able to see that and have a very fast feedback loop of release it, it's in their hands. 30 minutes later, we're getting our feedback an hour later, like that is super cool. And I think that's what excites me the most. The worst things, I think it's kind of like related the best. It's like, the highs are really high. And the lows are really low. Because, you know, if a customer says like, 'Oh, this feature wasn't great'. It feels like 'Oh, my God, like we're not doing enough. Yeah, it's like the two extremes. But eventually you kind of figure out how to tame those emotions. But I would say that's probably the best. And the worst is like, the wins are like, normally like, 'Yes, we did this!'. And the worst, we're like, 'Oh, my God, like my company sucks. We're not doing anything, I suck as a founder'. And like that roller coaster can happen, you know, five times a day. But it's totally worth it.

29:00 Miko Pawlikowski

That is awesome. So before I let you off the hook, let's take a stroll into the hypothetical, if you were to pick like the most important skill/slash/technologies/language slash/the next big thing for the foreseeable future, what would you invest into learning?

29:24 Ganesh Datta

That's a great question. One of the things that I've realized building a startup is that there's a lot of value in using things that are already built. Things like you don't want to reinvent the wheel over and over again. And I think that is more important than a lot of people prey for, even though it sounds obvious. So I think we're gonna see a resurgence in people who are adopting things like Ruby on Rails, and Django and Spring Boot, and all these things that were really hot, you know, six, seven years ago and kind of went off the wayside. I think we're gonna see a resurgence those things because startups and developers are going to be like, 'Why am I building authentication library for the 50th time? This is a solved problem, let's use a framework that's already done this'. And then we're calling shop internally, and we'll use Spring Boot, which sounds boring, but I think has given us a lot of competitive advantage. Because we're able to move super fast, use a huge ecosystem of stuff that people already built. And I think that will kind of feed back into people investing in the open source network, and contributing back to the community. I do think we're gonna see a resurgence and people going back to these kind of like, heavier, like batteries built in type framework, just because it provides so much value, you know, and shameless plug, I think service catalog will be an interesting space to follow. I think people are realizing that there's a lot of value there. So I think that's going to be pretty cool to see. And you know, how much investment there's gonna be in that space? All shamelessly plug statically typed languages, I think Kotlin is super cool. TypeScript was super cool. Just because, you know, as organizations grow and the complexity grows, it becomes easier if you have types and you know, what people are writing towards. So I think we're gonna see continued interest in TypeScript. And Microsoft has invested a lot of space. So I think TypeScript is going to continue going up. And I will plug Kotlin, just because I love the language. I think more people should be using it. But yeah, I think these frameworks are going to grow in popularity again. So that's my take on the state of the world and what we're going to see going forward.

31:14 Miko Pawlikowski

All right. And I think that's an awesome way to wrap things up. Thank you so much for your time. This was a real pleasure.

31:21 Ganesh Datta

Thank you so much. It's great to be here and thanks for hosting this.

31:25 Miko Pawlikowski

For everybody else. This is Ganesh Datta, co-founder and CTO at Cortex. And to learn more, cortex.io is their new website. Alright, well, thank you so much. See you next time.

31:37 Ganesh Datta

Thanks. See you, bye.