Transcript: The Invisible Layer Powering the AI Infrastructure | Co-Founder and CEO of Momento | Khawaja Shams

Host: Hey Kwaja, welcome to the startup project podcast.

Guest: Hinaraj, thank you so much for taking the time to chat with me. Excited to be here.

Host: Yeah, so for audience I'll I'll set a little bit of context, you know, about you. Um and I was going through your profile and you have a pretty interesting career till now.

Uh you worked at NASA, you did image processing for Mars Rover, you drove communications for interplanetary missions. Then you worked at Amazon in AWS, worked on Dynamo DB, simple DB, uh which powered Amazon Retail, Amazon Video.

And then you were head of AWS elemental, um and now you're building Momento, which is a, you know, serverless cache uh low latency messaging service soon to be launched or already launched durable storage service.

Um and you'll also closed a series A led by Bain Capital $15 million. Um so yeah, you've done a a lot of stuff and congratulations on series A. Uh I guess to start with, you know, what was it like to work at NASA?

Guest: Oh, it was great.

I started NASA as, you know, while I was still in college. and it was great to be surrounded by incredibly smart people who were, you know, more more so than smart, they were very passionate about what it was that they were working on. this endeavor to further human reach and explore places that we have never seen before.

It's a pretty inspirational mission. and I saw first hand what you can accomplish if all you really care about is, you know, that that passion, that that mission that uh that you're on.

Um a lot of the distractions, you know, team dynamics, politics, all of that kind of disappear when everybody is unified and chasing that one mission and I I really enjoyed that working at at JPL at NASA.

Host: Can you talk about the projects that you were involved in uh while there?

Guest: Yeah, I so I started working on the cameras on one of the Mars Rovers.

I started as a uh you know, was more on the hardware side. and one thing I learned about myself is that I'm pretty impatient and impatience is a is a virtue I guess as far as I'm concerned.

But um um you know, I found that software engineering had a much better velocity with which you see the results of what you're working on.

You could iterate faster and you're not, you know, and you can see the results of your of your labor come to light occur. So I shifted over to the image processing side.

And image processing for Mars has a lot of interesting challenges, you know, data is coming down from Mars and what you want to do is to paint all of the relevant images next to each other.

So that scientists can see a 360 degree panorama around, you know, what's going on around the Rover. You want to overlay satellite imagery that's been captured alongside the terrestrial imagery that's been taken by by the Rover.

Host: Were you also impatient because it takes a lot of time to get images from Mars, right?

Guest: Exactly. It it does take a lot of time to get images from Mars, but you know, it was taking longer to process the images.

And uh you know, because we were generating multi gigapixel panoramas in as quickly as we could as soon as the data comes in, people want to look at it. and that's when I decided to punch in my personal credit card and I went in and became a customer of AWS, Amazon Web Services to see if I can get these panoramas to be generating a lot faster.

And so I got to work on that. I moved our entire image processing pipeline onto AWS, took advantage of the elasticity. There weren't a lot of services in AWS back then. This is back in like 2008, 2009 time frame. This is pre EBS.

We had EC2, S3 and SQS is is all we had access to. and got to deploy that and it was a lot of fun just working on, you know, AWS in the early days and taking the state of the art technology and bringing it to space exploration.

Host: Does it involve a lot of process at NASA to get yourself reimbursed your personal credit card?

Guest: Oh, yeah, so I started uh prototyping on public data sets and I I don't think I ever got reimbursed for uh for the initial credit cards that I that I spent.

I got reimbursed in, I think I I I feel like I became a better engineer and I I learned a lot and that was totally worth it.

But onboarding Amazon as a vendor back in 2008, 2009 time frame, like late 2008 time frame, it was hard because you know, there was commentary like what does a bookstore needs like know about running infrastructure?

Like they they don't know what what it's like to run data centers. and you know, or or maybe, you know, can can they actually do stuff securely? Like can they live up to our standards?

And so it took a lot of, you know, effort to qualify them and to make sure that they were compliant to all the regulations that we had to comply to.

But after that point, you know, JPL was supposed was able to just um uh the NASA center I worked at, we were able to just pay for the AWS uh usage via the PO and then I could take my credit card off and I could afford to pay for all of the image processing needs that we had.

But it was good enough to do uh prototype work.

Host: And that made you join Amazon because of did you see like the potential or it was just another job opportunity?

Guest: Yeah, I I joined NASA because I like to have a positive impact of what I'm doing. and I thought that extending the human reach was a pretty novel endeavor.

To take humanity to where humans can't go, because NASA JPL, the center I worked at, they are the premier NASA center for, you know, robotics exploration of the solar system and and going to places where humans just can't go.

The furthest spacecraft they operated is beyond, it's beyond the edge of the solar system now. And I thought this was a very profound mission.

And the more I worked with the leaders at Amazon and the engineers at Amazon, the more I realized that this is the beginning of something really magical.

Cloud computing at the time was commoditizing infrastructure to make it available for experimentation. and it's the same thing.

Like the way I was going and putting my credit cards in, I I felt that startups are going to be able to run a lot faster because they can just punch in their credit cards and experiment without the physical barriers of buying infrastructure.

I had a demo where I I was showing that, you know, I worked on a NASA supercomputer as well and you know, we had a demo that showed Amazon had released spot instances.

You could run for about 100 bucks an hour, you could run a top 500 supercomputer. and and I did the benchmarks to to validate that.

So I was inspired by the profound impact AWS was going to have on the the GDP of the world's innovation by enabling more experimentation.

I wanted to be a part of that mission and I wanted to, you know, bring those benefits and and be a part of the the journey that that brings it and do my little part that I could. That's why I got inspired and enjoy.

Host: Amazon is a particularly unique place from, you know, what I know I have a lot of friends who work at Amazon because I'm in Seattle based. Um what was your experience of working at Amazon? Like those early days to, you know, when you came out of Amazon?

Guest: Yeah, I mean when I joined Amazon, it was 2013 and it was still early days of Amazon compared to where Amazon is today. Amazon was a much smaller company. The market cap was, you know, a tenth or so what it is today.

Um the employee count was smaller. and what I really liked about Amazon at the time was it had the same kind of missionary mentality of people really passionate about achieving a particular goal and working hard to to kind of deliver on it.

It was still a smaller company, there wasn't any bureaucracy or anything like that. You you have an idea, you just just go get it done and the level of ownership was through the roof. And I really enjoyed that.

It it felt very much like the same passion that people had at at NASA and there was this very unique feeling of customer obsession. 2013 was a really nice time to be at Amazon, in particular in the AWS division of Amazon, right?

AWS was tiny back then. and the customer obsession was really nice because people would put themselves in the shoes of the customers. and you would get to go work with all kinds of customers around the globe and understand problems in a completely foreign domain that you have no idea about and help them solve deeply technical problems via using the AWS infrastructure.

So I had a lot of fun and I felt incredibly productive in terms of the contribution I was able to make to the world in my small ways by being a part of uh AWS in those days.

Host: Uh which teams did you join and which products did you work on while being at Amazon?

Guest: Yeah, so I joined as the technical assistant to Charlie Bell. Charlie ran, you know, basically product and engineering for AWS at the time. and technical assistant is basically a chief of staff role. It has the title is technical assistant.

You're you're the chief of staff. It's the same role that Andy Jessie had to Jeff Bezos at one point. and it's a role typically reserved for somebody who's been tenured at Amazon for a while. Uh but I got lucky.

I I was able to get that role uh as my first job at at Amazon.

And it was nice because I got to learn how AWS was scaling and I got to be in the, you know, the same meeting rooms with the core AWS leaders for six to eight hours a day for the first 15 months I was at Amazon. and it was like the best MBA program that you can get access to because, you know, I just got to absorb.

I didn't know anything about running a business or running making money off of infrastructure. I'm still learning, but I was able to absorb a lot while being there and and just watching the way Andy and Charlie were operating.

Subsequent to that, I ran um you know, it's a rotational role. You're you're supposed to go in, learn and go repay Amazon the benefits of all of which you've learned by taking an operational role.

So I was appointed to run Dynamo DB, which is a large no SQL database. And you know, I did that for for a Amazon purchased.

I I had it in my heart to just be a part of like startups one day. and Amazon purchased a um a video encoding company called Elemental Technologies and I didn't know anything about video, but I really wanted to be there.

So I I went in as the person who was supposed to do the integration work. Like everything from getting their Wi-Fi set up to, you know, getting everybody an Amazon username and password and all of that.

So that's the kind of hands-on roles that are available at Amazon. and in the process I I fell in love with the people that were there.

The energy and the startup of Elemental, the passion that people had. and this was a company that got acquired and we were supposed to just go and build a bunch of AWS services on the technology that Elemental had.

So I stayed back after the integration was done and took on the role to run product and engineering for Elemental and shipped six different AWS media services. and so long and short of it, I ran Dynamo and then I ran product and engineering for all of the media services for.

Host: It's crazy because um 2013 is where I think I started observing.

That was my first job in the US and observing AWS and Amazon closely and then we used to think that it's already 100 billion dollar company and I think yesterday it's like a two trillion dollar company.

All you had to do in last 10 years was just buy Amazon, Microsoft basically all the three clouds and you would exceed every expectation. Um have you been surprised by the scale of the cloud in general?

Uh like did did it even, you know, surpass your expectations or when you were in those early rooms with Andy Jessie, uh were you sort of expecting this kind of growth?

Guest: You know, about 15 years ago, Werner Vogels said something really controversial. Well people were saying is AWS just a hobby project for Amazon? and he said one day AWS will be bigger than the retail business.

And people were just like, okay, this is just posturing. That's never going to happen.

But the one thing about Amazon leaders is, you know, they really believe in the think big leadership principle and and the leadership principle just says, you know, thinking small is a self-fulfilling prophecy.

So I, you know, I was along for the ride but the leaders at AWS always had the the North Star in mind to be to be as big as they are today and they're relentless.

They they're not they're never going to be happy with the level of impact they've made on the world by where they are today. They're already thinking how do we grow this in order magnitude again.

And that's the the really exciting part of of being a part of a company like that. I honestly, I didn't have expectations of how small or large the Amazon growth would be.

I was just enjoying the ride of working alongside some of the largest consumers of infrastructure, convincing them to move to AWS and seeing the business benefits that they were getting by running on the cloud and how productive their teams were as a result of it.

So I I, you know, every step of the way the product market fit got validated and the AWS teams just kept adding capabilities.

So, yeah, I don't know if I could if I could genuinely say that I I thought Amazon was going to get as big as it is today, but I I had a lot of fun watching it happen.

Host: Um so at some point you decided uh you know, you you had enough experience at Amazon and started momento.

So what was the triggering point and did you see an opportunity for like building a cache or uh because I mean AWS, you know, when I compare AWS and I'm mostly in the Azure world as a user and a builder.

Um AWS has more products than I think any other cloud. Like they they churn out products left and right and I think they have scaled back a bit. Um and I've seen caches also of a lot of different kind, right?

Front and cache, back end cache, key value pair cache. There's so many products out there. So what was the triggering point to say that, you know, there's a gap in the market that you are trying to address with Momento. So what was that journey like?

Guest: Yeah. you know, my co-founder Daniella and I, we both come from the Dynamo team.

One of the things that we really about Dynamo was if you need to do 10 million transactions per second, you don't have to learn what instance type and number of shards and number of replicas.

A lot of the knobs that you have to deal with with the traditional database, they just kind of go away with Dynamo. And that experience did not exist with any of the caching solutions.

All of the caching solutions that we have or had in AWS, they exposed, they were leaky abstractions and they exposed a lot of the knobs to the end user.

So we started by saying, you can Momento will help collapse a bunch of the diagrams, a bunch of the boxes in your architectural diagram of your caching deployment into a single, you know, SAS endpoint and, you know, it doesn't really matter if you're doing 10 TPS or 10 million TPS, we we take care of, you know, making the best underlying decision on the infra side to get you what you need and to keep you productive.

What we realized along the way and we literally did this accidentally is we built a two-tier caching system and the second tier ended up being a really great web server.

And this means that now we're not only collapsing a bunch of the boxes in the caching side into one, we have the fine grain access control plus the HTTP server and a cache so that, you know, like mobile devices can talk directly to Momento and again, that just comes down to developer productivity, right?

If you want to build like a chat system with 4 million subscribers without having to deal with web sockets or having to deal with, you know, membership management and you know, writing a bunch of code, you just write a bunch of client code and a token vending machine and boom, you're off to the races, everything scales. and nothing like that exists today and it certainly didn't exist back then.

Um AWS is great for providing incredible building blocks and all we had to do was to compose the best set of building blocks available to solve this particular use case around enabling developers to build highly interactive applications.

Host: So this idea that, you know, different abstraction level is necessary. Was that an insight, you know, talking to a lot of Dynamo DB customers or um like how did you get to that sort of maybe hypothesis that you know, customers need this?

Guest: Yeah, there were two things. One was, you know, we at the Elemental side, we were some of the largest caching consumers because we built, you know, one of the services uh my team built was Media Tailor.

Media Tailor is a personalized ad insertion service. It inserts personalized ads when millions of people are watching Thursday night football on Prime TV. Like there's a service that's injecting personalized ads.

And you can imagine this is a very high throughput system. and as a result, we became one of the largest customers for, you know, the caching services at at AWS. and that's when a lot of us, you know, looked at it and said, you know, I really wish this was less painful.

I really wish I didn't have to deal with the instance types, the number of shards, the replicas, the maintenance windows. I wish all of that just didn't exist.

So that was one piece. and then we also learned, we realized that we were learning a whole bunch of operational lessons, one outage at a time. and then we also realized that it's the same lessons that every other team at Amazon was learning because Amazon has that operational metrics meeting.

We realized that caching is a really common place where people get in trouble and it's the same set of things and we can productize those.

Like little things like tuning your clients, having the right, you know, exponential back offs, timeouts, retries, you know, managing capacity, having enough capacity available to you, you know, optimizing the capacity, making sure that you're not just over utilized, you know, heat management, dealing with hot keys.

All of these things are, you know, outages that that happen and then teams have to go fix and re architect.

And we figured we could productize that and that's our contribution to humanity is to, you know, let the developers that are building interactive experiences focus on their differentiating aspects instead of worrying about the number of shards in their backend cache.

Host: Uh so you sort of identified this hypothesis that this is a problem and you want to sort of create a solution for that. What was that initial process of going from zero to one? Um you know, how did you hire your team?

We talked about your co-founder. Uh talk to me a little bit about that, you know, zero to one phase where you where you're hiring, you know where you're building that MVP, um sort of that journey.

Guest: Yeah, so Daniela and I firmly believe in hiring ourselves. We, this is a a craftsmanship of building your own team is incredibly important to us.

We take a vested interest in every single employee, especially in the early days of the startup.

So almost like pretty much all the hiring at the company and certainly all the hiring on the engineering and product side has been done by us together as opposed to it being outsourced or being a problem of a recruiter inside of a company.

And the people matter, the people matter a lot. and if you have the right team and and that team has the right passion, you can accomplish anything. Then, the second order bit is well what is the what is the thing that you want to accomplish?

We knew that, you know, this is a large enough market, but whatever we build has to be grounded by customers. So then we started approaching customers for design partners.

We started having some hypotheses around, hey, this particular customer is running at scale and we anticipate them having these kinds of problems. And what we were looking for is not somebody to write us a check.

It's the somebody who's willing to be a design partner, somebody who's willing to share with us what are the infrastructure challenges they're having with their caches. Let us experiment.

They have to be early movers and get us feedback on our product when running at scale. and that process was very gratifying because the team of passionate individuals that we hired took this responsibility of a design partner very seriously. and they built a culture of operational excellence and this culture of not letting a customer down because we are in their mission critical path.

And as a result, you know, we found our first few customers and you know, in some cases we got them out of something that was having constant outages. and in some cases we helped them with their product launches and with unaticipated scales and so forth.

But every step of the way, I think our customers have not only love the product, but they've loved working with the team and the level of ownership that the Momento team has in their success, not just the revenue that company is is generating.

So that was a zero to one. You hire the people, then you find the customers who can be your strategic partners and can give you the product grounding that you need.

You make them successful. and now we're at a stage where we have a bunch of these customer design partners that have been successful and we're now beginning to add how to double down on our go to market strategy and get our product into more hands and and get more even more real world traction for our services.

Host: Are there any specific type of customers that were looking like when you talk about dessert partners? Like are these your video streaming companies or are these your companies like building lots of chat application? What type of companies were uh you know, interested in the solution?

Guest: Yeah, this is something I did pretty badly at first. So I I used to go around telling my team like we we built we're building a cache, a cache is a it's like selling a water bottle.

Every vertical, every customer needs a cache. and and what that led to was a pretty um broad go to market motion in terms of which customers to go after. But we realized that we don't have the luxuries of a larger company.

There's very few of us and we need to specialize at first.

We need we can't over specialize to a point where we're on a particular ridicule, but we need to, you know, exert concerted efforts towards a specific set of verticals so that we can recycle the messaging and and find look alikes and so forth.

So the core verticals where we do really well are media entertainment, so like video streaming like you said. and not just the actual streaming part, like video companies have you know, they have identity management, you know, like how do you log into your uh to your box for direct TV.

What what what you know, movies do you have access to watch? That's called entitlement, you know? What CDR workflows need to be, you know, recording at 8:00 and at 8:30 o00. That's you know, there are lots of spikes there.

So, and then each of these companies have lots of mobile applications to make the experience more interactive. So, we found our niche and we found a bunch of really happy customers, like large media customers.

And the second niche was gaming. same thing. So we identified our core power for Momento comes when you have like unprecedented, unanticipable scale and like spiky traffic.

That's what we do really well. and media gaming and then Fintech and specifically in the areas of like fraud detection, payment processing, like those spikes we absorb really, really well.

So going back to our core ICP, it's spiky workloads, space traffic. and there's one other part which is if there's an outage, it really hurts. Like it has a financial impact on the company.

So that's how we identify now, you know, the next generation of design partners that we look for. They have to have large scale, unanticipated spikes and mission critical health.

Host: I mean at at how many customers did you feel like, you know, you were good enough and okay, we we really have a product market fit or are you still think that we are still figuring out product market fit?

Guest: Um no, I I think, you know, we have dozens of customers that are in the, you know, that that we consider as like large enterprise um customers. Um and there's coherence in their asks, right?

Like they we we had to add a whole bunch of features that we never thought we would. Like we had to add data structure.

We we thought, you know, most users are using key value, but you know, people do like using data structures in their in their cache. So but it wasn't like a one off thing. It's not one customer asking for a particular item.

So the fact that there's coherence across the dozens of customers that we that we work with in our early stage, gave us assurance that there is product market fit.

And then it's about, you know, creating that roadmap and prioritizing it based on what the customers are are asking for.

But it's also about curating the go to market messaging and the go to market efforts to find more customers that kind of fit these uh these verticals and and these ICP description that I mentioned as well.

Host: Talk to me a little bit about, you know, how are you thinking about marketing in your context or growth in your context because B2B growth is slightly, I would say less stunt about and how you approach is very nuanced and it's also very hard.

Like B2C is pretty straightforward, you know, um you can buy Google ads, Facebook ads and you can go in front of a lot of customers and find the right customer uh said that would consume you.

But B2B is slightly a much more complicated game uh when it comes to startups. Uh talk to me a little bit about, you know, what you've learned in terms of like growth and marketing and how are you thinking about it right now?

Guest: Yeah, and I'm still, you know, we're we're very early, so I don't know if I've learned everything I need to know by any means, but one thing I learned is the focus really matters.

You know, given that we have some of the largest names in media and gaming already using us, it became a lot easier for us to say, hey, this is who we're going to focus on. and you know, um one of my mentors advisors uh Shruti from Roxet, you know, uh Shruti says that, you know, once you land a particular customer, you immediately got to start looking for lookalikes because when you go to those look alikes, they know that they're not the first ones.

They're not the sacrificial lamb that you're you're trying with. So that's that's important. The focus matters. The look alike, you know, finding the look alike matters. The other part is you just you just never want to let a customer down.

And in our case operational excellence and having the architecture behind ourselves to not cut corners and actually be ready for unanticipate scale is is really crucial.

Because when you do that, then the existing customers, the the customers for whom you're finding look alikes, they become references. and they become your advocates.

So don't let customers down, like have that real obsession, focus on a few, you know, key verticals, um and really listen to the customers to create a coherent roadmap. and sometimes you have to tell the customers, no, that's not what we do.

But in some cases you have to disconfirm your beliefs and see patterns that are emerging as you're talking to customers to round the product that you're building.

Host: I I'll slightly shift gears and I'm ask about this one thing that I sort of skipped asking you about, you know, working at Amazon. What's your take on, you know, I think Amazon at this point has 16 principles.

Um and you know, the the way you work using those principles um or like the philosophy of using those principles sort of to drive culture and like and do you take that in your current company?

Um do you have your own sort of principles or you know how how do you look at the whole principles thing at Amazon?

Guest: I think the leadership principles at any company are a really good reflection of what the culture is in the company, depending on how well they're embraced.

I'm a fan of the Amazon leadership principles, but I also recognize that Momento has to define its own culture in its own unique ways.

We we have the opportunity to start with a clean sheet of paper, you know, we we don't have to copy the the culture from any one company. So we don't we didn't copy the Amazon leadership principles uh wholesale.

We have a customer centricity as as one of our core leadership values and you know, psychological safety for everybody and that inclusivity is core part of our our culture. But Amazon has similar values, they're just in a different format.

We're also too small to have, you know, 16 value. Like we we just can't. Um most Amazon leadership principles and I think it's because there's so many of them are grossly misunderstood as well even by people at Amazon.

So I'll I'll give you a concrete example of a commonly misunderstood one. There's a leadership principle that says leaders are right a lot and you know people think that's about, you know, leaders with good intuition and the nuances get missed.

Like they're right a lot. They're not always right. and if you read the the actual description, it says leaders work to disconfirm their beliefs. They are attempting to disconfirm their beliefs and they're willing to be wrong to be right, right?

Like which means that you don't indulge in self-consistency. You're willing to look at data and say, you know what? I thought about this wrongly and I have changed my perspective on it.

It's not about you're the leader so you're you're going to be right always. But when you have so many nuances get lost, especially when you have, you know, hundreds of thousands of employees.

So, Momento has its own, you know, set of leadership values and you know, we'll keep adding some, but right now it's about customer centricity and psychological safety for everybody.

Host: Yeah, the reason I ask is I felt that I Amazon did it a little bit um I think Bezos added two more principles when he was leaving Amazon, which I thought was a little bit over the top. I think you had already 14 principles.

I think it's just that I I don't feel that it was productive to add more two more principles into the existing set of 14 principles. Um because how many principles can really people follow? Like have the nuance to pick up and when?

And I've also seen this pattern of like uh people who stay for long at Amazon know on how to use the principles to sort of reinforce their point uh which sort of is completely opposite of the whole purpose of the principle itself.

Um which means that anything can be justified in the name of principles.

So the original whole point of having principles is now really moot because uh you know, you can say anything and you can apply the principles because you're really good at applying principles, not really actually using them.

And so that that's what I felt when they added like two more principles on top of the existing principles. Um but yeah, it's a very interesting culture for sure and I think it has worked really well when, you know, applied correctly.

Um any other interesting lessons that you learned uh from seeing now, you know, three different cultures like you worked at NASA, it's you know, completely different set of, you know, factors at play.

Amazon completely different set and now you're seeing as you've integrated startup and now you're creating a startup.

Uh do you think there's differences on how you approach or like create talent and because I'm focused more on like how do you convince people, especially in a startup, right?

You have to convince people that this is an important problem where you're spending, you know, significant amount of time to solve your lifetime and it is a worthy time to spend on, right?

So I always feel like in startups that was that is one of the biggest challenges is to convince great people to come and join you to work on this problem.

Um and it only happens then you can like really create a culture where, you know, you can attract really high talented individuals. Um so yeah, that that's sort of like my motivation to ask that question.

Guest: Yeah, I mean, Amazon is so large and the US government is so large that it's really hard to make a generalized statement about which culture might be better or not. Like cultures vary.

Like you go to some cities, you can see like street by street, different neighborhoods have a completely different landscaping norm or whatever it might be. and the same is true for Amazon.

You can have teams within the same organization that are horrible. and you can have teams in the same organization that are actually really good. and and that's just it's law of large numbers.

So you're going to have terrible teams, you're going to have great teams. and if you're considering a role in any of these companies, any of these environments, it is really important to make a bet on the people on your team.

Even if you're joining as an IC, you're making a bet on the team that you're in, the product that you're working on and the team you're in. and this is true inside of Amazon as much as it is true joining a startup.

You should go spend your time working with people that you enjoy working with and working on a problem that you believe will leave a profound impact when you're done with it.

And that's how you should pick a team inside of Amazon or Microsoft or at Google or at, you know, take thousands of startups that exists.

Find the people that you want to work with, find the problem that uh that you think will have a profound impact and you'll you'll feel very fulfilled doing that.

Host: Yeah, I think that's a great answer. Like whenever someone asks me a question about, you know, broadly about the company I'm working at and I always say it if it depends on the five to 10 people that you're working with.

Everything else is, you know, it's it's generalized, right? You don't know like five teams away how the things are, you don't know how things are between adjacent team.

It's all about like 10 people that you work with closely and everyone else uh on the periphery. Uh so we're almost at the end of our conversation and I ask a couple of questions to all my guests.

Um so uh one of the question is what are you consuming these days? What is your um you know, books or podcasts or Netflix? Uh what is defining your consumption these days?

Guest: On the books, huge fan of um Daniel Kenman, thinking fast and slow. If you want to learn to be a good product manager, not a product manager book, but but I I found that to be a pretty insightful book.

On the podcasts, I we've been creating a new community for Momento and as part of Momento, we've been creating newly around serverless computing.

So there is, you know, it's a community led effort, but there's like three or four different podcasts every week now. I can't even keep up with with them.

We we started this and now it's taking the life of its own, but I always find very interesting podcasts on, you know, if you go to believeserverless.com. I also follow software huddle, Alex Deebry on the on the podcast front.

Netflix, I don't think I have anything in particular exciting there. I feel like I'm done watching TV for a bit. Host

---