The Benefits of Boring Infrastructure with Helpful.com’s Farhan Thawar

Episode 113 · 33:56 · SRT · archive.org · all Tanzu Talk

Hi, everyone. Welcome to Pivotal Conversations. I'm Jeff Kelly. This week, Dormain and I chat with Farhan Tawar, who's the Vice President of Engineering at Helpful.com. Helpful.com provides a video and audio-based business communications platform to help business users collaborate more interactively. Farhan talks about the challenges of building a company from scratch, why it's important to apply smart architectural principles to empower development teams, and why he strives for boring infrastructure. Enjoy. I was thinking about this, Farhan, that it's almost four years to, I mean, here on recording day, perhaps when this goes live, it'll be four years, almost exactly, since you and I did a webinar on... Oh my God. The January, yeah, the January webinar. That's right. So, yeah, I was like, holy moly. It was fun, as always. And yeah, it's just been a long time, which is kind of crazy. So maybe you can catch some, catch me up, catch our audience up on what you've been up to. You were at Pivotal back then. That was four years ago. But you are at Helpful now. Yeah. So I can give you a little bit of the history. So I met, actually, Edward and Rob, me in 2009 when I first got to Extreme Labs. And what was interesting about what Extreme Labs was doing was that Sonny, who was one of the founders of Extreme Labs, he was a Pivotal Labs client. And he was building a startup. And he got more excited about how they were building the stuff that they were building than his actual startup. So he was working with Pivotal Labs. And he's like, you know what, the way you're building my product is more interesting than my product. And so he decided to then,

you know, that startup, I can't remember actually what happened to the startup, but he started a new company called Extreme Labs in 07, focused on two things that were different than Pivotal Labs. One was mobile. They're like, we're going to make a big bet on mobile. And the second thing was they wanted to do it in Canada. And so, you know, the, I think the, in the background, you know, Pivotal Labs North was kind of their idea on focus on mobile. And I joined in 2009 via the other co-founder who I went to school with, Amr. And right away, the first thing they did is they said, you got to go to San Francisco and sit down with Robby and Edward. And you have to sit down and understand what, how they are building software in a completely different way than anything you've ever done before. And so I wasn't like, you know, right out of school. I've been, you know, 2009, I graduated in 98. So I've been out of school for a while already, but I went down, I still kept that piece of paper of my notes from that meeting because it was mind blowing on how they were building software. And, you know, there's, as you know, there's lots of things that are popular, right? There were pair programming, tracker, sustainable pace, like all these things, but there was all these little minor notes too. And so we built Extreme Labs in their image, innovating on the mobile side and also focused on making changes to work with enterprise. Cause that was quite different than what Pivotal Labs was focused on. They were focused on startups and rails. And we were doing mobile and enterprise. And so I was, you know, modifying and adjusting the process, right? Robby calls us do the right thing. So you do the right thing, which is sometimes you got to make changes. And then surprisingly, or maybe unsurprisingly, Pivotal, Pivotal, Big Pivotal bought Extreme Labs in 2013, which was a, we were about the same size as Pivotal Labs at the time, 350 people. So we merged and became this giant force, which was the Pivotal Labs business inside of Pivotal. And then I was at Pivotal for two years doing two main things. One was, um, integration. So I became a VP engineering for the Northeast integration into Pivotal Labs business. And then, uh, I left the labs business to join Cloud Foundry and was the CTO for mobile and Cloud Foundry and worked with the team there to help bring,

um, Cloud Foundry to folks who wanted to build, uh, scalable mobile infrastructure, which is, uh, a large part of where, uh, software is going. Um, so that's 2015. So there you kind of long winded way to get to 2015. And then I, uh, wanted to pursue my entrepreneurial route. So I actually never started a company. So 2015 left to start a company called Helpful with another serial entrepreneur, uh, in Toronto. So that's kind of the genesis of how I got to where I am now. So what does Helpful do? So in 2015, we had a few thesis, uh, theses, uh, thesis around, um, what, where we thought software was going. I was still interested in mobile, still interested in enterprise, um, and started getting even more interested in machine learning, machine intelligence. And so, um, we built a product in 2016, um, called the Helpful Directory, which was the AI powered employee directory for fast growing companies. We noticed that in many large, uh, fast growing companies, you end up building an employee directory because it was the thing that helped you figure out who knows who and who's doing what in the company. And, um, we did that for about a year. Um, we learned a lot in that process. And through that, one of our engineers, uh, in a hackathon project actually, um, built out a little video, uh, profile for herself. So he had a, you know, employee directory, had a little profile and she said, you know, it's much more compelling for me to put a little video on here than a little text profile. And so Patricia built a little video profile. And what we noticed was one, it was super compelling, you know, just like an about me and, um, what I'm working on my goals. Um, but we, people started hacking the video profile to talk to each other. So people would kind of use it as like a voicemail I would look at Patricia's profile and would tell me like what she's working on right now. And then I could leave a voicemail for her and people started using it very much like Snapchat. People use Snapchat in the consumer world. So we pivoted the product in 2017 to be focused

on video. And so we built a Snapchat for work. It was enterprise ready, single sign on, um, AI transcriptions, stickers that were focused on, um, more around workplace stickers. So not like vomit comet and things like that, but more around, um, sales deal closed, you shipped a product, you recruited a new person, like those kinds of stickers. Uh, we deploy that solution. And then in 2018, we got really, really excited about the rise of audio and with podcasts that this is one of them and audio books being, uh, a new medium, we realized that there was a gap in the market in, um, live interactive audio. And so we built a tool called dialogue, which was focused on live interactive audio over the internet. So, you know, the example I always give people is when Donald Trump tweets, people wait for Nate Silver to respond from five 38. And it takes him about six hours to create an emergency podcast for that tweet. And with us, with dialogue, you can respond right away, reply, you know, start streaming live immediately and take callers and it's, you know, AM radio on the internet. Uh, and so that's what we're working on now. We have a bunch of, um, folks with pretty large audiences. Um, Ben Stiller uses it every week, Jake Tapper from CNN, Greta Ben Sustran, and a bunch of other folks who, uh, use it to connect with their fans, uh, every single week. So that's, that's what helpful is working on right now. Okay, great. That was a really good overview. So tell us about how you build software and how you're running the platform at helpful.com. Yeah. So let me, let me get into that. So I think, you know, the, the, the one testament that I can say about, you know, things from a previous, like, you know, coming from pivotal is that once I started my own company, which meant writing my own check, right. You can, you can basically say to yourself, okay, what are the things I still believe in that I have to now use writing with my own money? Right. So if you, you know, for example, um, let's say you worked at a restaurant and then, uh, you left the restaurant, do you still come there

to eat? Because just like the way that they prepare the food and the food itself, you're like, it's still good. It's still, it still reminds you of like, Hey, this is really good craftsmanship. Right. And so when I left pivotal, I think a lot of people were looking to see like, what would I still do? Um, given that I left pivotal. And so I left pivotal and what do I still do? Well, with my own money and my own team, we pair program, we still use pivotal tracker. We still work nine to six, like all the things that, uh, I've been doing for the last 10 years in my career. And then got bolstered by learning from many of the people who invented the stuff. Um, I kept doing in my own company with my own money. So I think that's a good testament. And part of that is on the infrastructure side. So when we first started building helpful, um, the dialogue, uh, not dialogue to help the first product, which was the, uh, directory, we right away realized that of course we need some server infrastructure. And I gave a credit card to my first engineer. Um, and I said, Hey, go get an Amazon EC2. Right. Cause I was just like, you know, get some infrastructure. And he looked at me and he goes, you want me to manage servers now? Like he literally said that to me. And, you know, given that, you know, he was also from pivotal, he was reminding me of like, Hey, we just came from an environment where we tell everybody that don't do the undifferentiated have, don't do the undifferentiated heavy lifting. Why are you then going to Amazon EC2 and like setting up a server that you have to maintain? And so I looked at him like, you're right. We should be using PWS. And the reason we should be doing that is because it's going to allow us to containerize our application logic and only have to worry about the application. And so, um, PWS at that time, much less mature than it is now, but was, uh, did have production workloads on it. And so we were able to right away, bring up a PWS infrastructure, um, build an application, uh, deploy it, and then not have to worry about all of the runtime things that you have to worry about in managing a server. And that, um, since that day in early 2016, we've been on PWS the whole way. So we have, you know, we have a very, you know, when we're doing the video infrastructure, a pretty significant

workload, um, we've had to push and pull PWS into different ways to make the things that we wanted to run as performant as they had to run. Um, you know, in that, in that time period, but it was, uh, it's, it's been a very, it's been a differentiator for us on the infrastructure side because we don't have to manage security updates. We don't have to manage, um, wondering if our things are running because they're, uh, that's automatically managed by the platform. It's automatically updated. Like all the things that we care about, um, happen for us through PWS. And then on the second side of it is, is support infrastructure, right? So we are very, uh, ingrained with the support team there. Things are going wrong. Um, we can message them. We can find out what's happening. We watch the incident reports. We have, you know, the PWS Twitter feed right into our Slack channels. We can see all the things that are happening and it allows us, you know, high confidence that our infrastructure works. And, you know, all goes back to that first comment from my first engineer who said, you want me to manage servers now? Like literally like what's the, what's the value in that? There is no value. Exactly. So now you've got, uh, you're able to put your team, you're able to focus your team on the things that do differentiate you, which of course is the application and the features and the capabilities and listen to your customers and iterating and those kinds of things. Right. And I think it's a, it's, it's not a minor point because what I think some people maybe take the wrong way is they feel like this sort of infrastructure is only for big companies, right? Like, oh, if we're, if we're a big company, we're a bank and we have thousands of applications and thousands or thousands of microservices, we might need this level of, uh, orchestration, auto automation. That's false. Even in, you know, when we started, we were only two engineers, right? So with two engineers, um, you know, everything we were pair programming. We were using tracker. Like we were, we were, you, we were using PWS. So it's not the case that you have to wait until, oh, you know what? There's this like breaking point where I, then I have to start thinking about automation in my infrastructure. It's, it's, you have very limited time. So if you have very

limited time to react and build things for customers, why would you not want to spend all that time on the differentiation of your company, not on setting up a server and doing security and upgrading, like, like all the stuff that is like non essential. Um, so I'm, I'm glad we did it right away. And I would, I would encourage folks to think in that way early on rather than later. I don't think it was, you know, at any point like overkill. Right. And in fact, I mean, if you, you could make the arguments, it's even maybe more important if you're a smaller organization, if you've got two people, you don't want them, you want them spending all of their time on the product and, and as little time as possible on those things that aren't going to differentiate you, uh, like managing servers. So, all right. So that's great. So you're using PWS, which is essentially a hosted version of Cloud Foundry. Yes. So talk about some of the things you're doing in terms of the CICD and continuous deployment. Talk about how the platform enables you to do some of those things. Yep. Sure. So, I mean, maybe no surprise. We use Concourse, right? So we, we use Concourse CI. We have a hosted for, uh, we have a version, I think hosted for, uh, we heard that we host, I think on EC2, I gotta, I gotta check that. Um, but what that again allowed us to do was make sure that we have, you know, visible, uh, build monitors. We were actually part of the team that, uh, the Concourse CI team came here to see how we were using it. I think we built a custom UI on top of it. So they wanted to see what people were doing in terms of like custom UI, but the same, you know, the same things, uh, apply, right? Meaning if you're writing code, then you're, uh, not ensuring that the pipeline is green when you're writing code and the team is, is entirely green. Everything stops and you have to fix the build. And that's something that because it's visual forces the culture of the company to be like, Hey, you're, you can't like, everybody should stop what they're working on and fix the build. And so we do have these monitors up that keep us appraised of the CICD condition because we all also build things, microservices.

It allowed us to abstract away, um, team A from teams B from team B's work in a way that allowed them to deploy independently, right? Um, you don't want deploying to be some momentous event. It should be just a normal course of, uh, the course of the day. And so we deploy all the time, microservices are deployed, different components are deployed. We use the CICD pipeline in that way to see that the health of the product is, um, green. And that allows us to, um, not worry again about the overall health. And we can just focus on like, Hey, what am I, what is my, what is in front of me right now? What do I have to focus on? And I don't have to look around and be like, like, okay, the thing that I did broke somebody else's thing. Um, so the, that CICD, you know, again, I, I, we, it wasn't like we were trying to remain on the pivotal stack for whatever reason. Like, um, I didn't sit down and be like, well, let me just see what pivotal library has. It was more about each thing kind of came from the team and, um, the team came back and said, well, you know, this is what we need for the infrastructure. And our team did, you know, our team, um, at its, uh, largest was about 25 people. So that is a big team. Um, and that did a lot that did allow us to move faster. Yeah. And, and talk a little bit more about the importance of being able to develop teams to develop independently of one another. Uh, obviously that's a key component of the whole microservices architecture, one of the things that supports and why is that so important, uh, for helpful? Yeah. So I think there's a kind of a couple of ways to think about it. One is, uh, and, and this, you know, I've had this debate with startups all the time is should you, or should you not, uh, not adopt microservices when you're building something from scratch? Uh, and then the second part is, is how do you have teams grow in a way that at a minimum can grow linearly? Like, so you add two engineers, you get two more engineers worth of output versus what we see in other, um, team structures is you add people and you get more, but you don't get a full engineer's output for every person you add, right? Because it asymptotes at some point or approaches

some, um, you know, some, some ratio where you get like 0.2 of somebody or something. And so on the first question, what we realized that helpful was that if you can create a, an automation, which allows you to create microservices fairly easily, right? So you can literally like, you know, type in one command and you can create the stub of microservice. It's automatically, you know, it's easy to find it connects to the registrar, like whatever you need to do, then creating microservices is super easy and it encourages people to do that. And the reason we did it that way versus trying to build something in a monolith first and then try to break it out was we realized that aggregating microservices is quite easy. So if you, you know, if you were going to have something be one giant monolith, uh, and then break it out when it, when it, uh, made sense to break it out versus it's already a microservices and it's 10, let's say microservices and you could just aggregate eight of them together because they all belong together. The aggregation step is quite easy and you know, it's not a lot of work to do that, but the breaking apart the monolith typically requires large swaths of like refactoring time. And so we went the other way. We went like microservices first in for the second question around how do you maintain, uh, growth and, and, uh, efficiency and effectiveness was by breaking up components of the T and maybe get the team into components that could go as fast as they wanted to on their own. That allowed us to move more quickly. So for example, in the microservices terminology, if you had a pair that owned, you know, five or six microservices and those microservices were built in a way that to not be dependent on other microservices, like how you're supposed to architect it, then they can move really, really quickly because they're not worried about, um, running into someone else's, uh, code infrastructure or having to, having to deploy and saying, oh, I'm deploying this, but that test from that other service deploys is a requirement for my service to run correctly. Like that infrastructure problem doesn't happen. And so now you're always thinking about how do I test my microservice? How do I deploy my microservice quickly? How do I deploy functionality just for my microservice?

And then you're independent. You're like on a completely different team and your API, your API to everybody else's rest. So you're not really focused on, um, having to worry about what other people are doing from that perspective in terms of running, uh, running into roadblocks. Hmm. So it sounds like, sure. It lets, it lets each team develop at their own pace, but it also lets them focus. Yes. Yeah. And they, I mean, we did, we did a few things, right? One was we rotate pairs often. So yes, at the time you're focused on your infrastructure, your services, but because we rotated, you're getting a view of the entire system. Um, but yes, any, any, any individual week, like we didn't, we don't rotate as much as Pivotal likes to rotate, which is daily. We would rotate, you know, more weekly, sometimes even monthly, but that gave people enough of a view of the system to understand what's going on and a deep, a focused enough view of the system over weeks at a time to then be able to move really, really quickly on those services. Yeah. So what else did you, did you look at or, um, or, or not? So when we were, yeah, basically in 2016, when we realized, you know, you realize you need to back in the first, my first thought was actually Amazon EC2, just because of, you know, probably brand, brand recognition. And it was my engineer who said like, why you want me to, you know, you want me to manage servers now. But, um, outside, outside of EC2, um, you know, I think in my mind, anyway, I taught about, I thought about digital ocean thought about, obviously there's GCP didn't spend any time on Azure. I think we did look at Heroku, um, just at a high level, mostly because my co-founder's company got bought by Salesforce. And so there's a Heroku connection there. Um, but outside of that, um, we, you know, I think our idea was, well, let's see if PWS can work for us as a startup. And so by jumping into PWS early and having all the connections there from a support perspective, um, we never had to leave for, you know, we're coming on three years now on, on PWS. And we were able to, you know, pretty much stretch it into different areas that we require. Now, there are times when there isn't a service in the marketplace or something like that, that we have to go direct.

But for us, the, um, the best way for us to use PWS is to use the services that are then in the marketplace, because that allows us to have this, um, very low friction way to adopt things that potentially would be harder to do when not in PWS. So we always check the marketplace first. And then, um, if it, if it's not there, we'll then do an external connection, but we've been able to move as fast as we have scale as quickly as we have scaled and, um, build new products, um, that are quite different from each other all on PWS, uh, very successfully. And I think it's one of our competitive advantages, uh, versus other companies, because there isn't, uh, any infrastructure we have to manage that is, uh, you know, the undifferentiated heavy lifting that we don't have to do. And so we're very easily like, we like literally, I see, sometimes I go to my engineer and I'll say, Hey, so we have this big, you know, I was telling you weren't their domain, but we have some pretty big celebrities on our dialogue platform. Um, Jake Tapper, Ben Stiller, Greta Van Susteren. Yeah. And so sometimes we have these big shows and we're like, Hey, we need to, you know, ramp up the infrastructure. And my engineer looks at me and he goes, yeah, that just means pressing buttons. Like I just have to press some buttons. Like he like, right. Like I don't have to do any code. I'm like, Oh, don't you have to do it? He's like, no, no, I just got to press some buttons. And so, um, and now with even auto scaling and things like that, we don't even have to do that. Yeah. Okay. Um, and, and so in terms of how that becomes a competitive advantage is, you know, every person that you're able to bring on in engineering is able to work on new code, updates, product oriented work, as opposed to the undifferentiated heavy lifting. Yeah. And I think, I mean, there's a couple of things going on. One is we bring on lots of smart folks who may, may not necessarily know about cloud native computing. And so at the, at the beginning, it's a little bit of, you know, repair, so it's not so hard, but it's, it's an introduction to like the infrastructure. But once they see the power and they realize that they don't have to do things that they potentially had to do in other jobs, they're like, wow, this is actually quite fast. Like, I don't have to worry about all these things. Um, I think during the last three years,

right, you had, you know, a heart bleed and other big security vulnerabilities come across. And all that happened was I got an email from PW saying like, you know, uh, you know, redeploy your applications. Like there wasn't anything else that we had to do. And, you know, given that we work with a lot of big enterprises and we go through rigorous security reviews with them, um, to go back and they would specifically ask us about those, um, vulnerabilities. I'm like, oh yeah, it's, it was, it was taken care of by the platform. And I could even other forward them the email I got from P dubs or, um, or just show them that it was certified fixed from an infrastructure perspective. Um, again, as a startup with not, you know, not thousands of developers, right. Um, we're not focused on that. It's like, yeah, I just don't have to worry about it. It's like, yep, that's just taken care of. Right. We were actually talking about it last week. I can't remember what it was, but it was, there was something else. And I said, oh, is that just a CF push? Like I don't have to do anything else. Right. Yeah. Okay. I mean, and so what, what do you do when, when there's something that's not on the marketplace where, where kind of the edges or areas? And then I guess kind of on a related question would be, what advice would you have for another startup out there in looking at P dubs, getting started? What do you, what would you recommend to them to, to just make that smoother? Yeah. So, I mean, I think the first thing, I mean, Leila asked the second question first is that, um, like you want things to be as boring as possible, right? On the infrastructure side. And I think that's where people get caught up. Cause you're like, I want to try the newest thing. And for me, it wasn't about the newest thing. Like we weren't trying to like use like the latest in containerization technology. It was like, it's like, what's the most, like, what's the thing that allows us to focus on the work, right? Not the undifferentiated work. And so, um, it's pretty boring around here, infrastructure wise. And maybe that's not as fun as elsewhere. We're like, oh, the thing went down and I got to bring it back up and like, I can put a security patch. And like, it's always like nerve wracking when you do an upgrade. So from that perspective, we weren't necessarily trying to be heroes on like the latest and greatest thing. We were just trying to find the thing that allows us to focus on features, talking to customers, getting feedback, iteration,

like the, the, the actual value, right. Versus like the, the thing that had no value. So that was, that was the, you know, your answer to your second question. On the first one, there were times when we're doing something specific that may or may not fit in directly with what we need from, um, PWS. And I don't think it's a, like a miss. It's just something very specific. So an example would be, um, when we were doing the video infrastructure, we were sending, you know, thousands and I think, you know, tens of thousands of videos a week. And that necessarily required us to have some fast storage access and the fast storage access isn't necessarily something that's going to go through a P dubs, just given that, um, it didn't make sense to go through P dubs. And so we, you know, spent time with Amazon S3, spent time with GCP file storage, uh, to figure out and benchmark the things that we needed to do to make those as quick as possible for our customers. And, um, so those are just direct connections to those things. Um, and that's typically what you end up doing when you have something that in that case was like a high bandwidth, low latency request. You didn't want you, you didn't want to have any more hops, um, that were required. Yeah. And are you still able to make those direct connections that, that you've had to build yourself something that's easy to maintain? Well, not as I mean, everything, our first choice is always go through the marketplace because it's easy. It's, it's much, much easier to maintain there. And so that is our, our preference always actually, there have been times when I think we worked on something that was not in the marketplace and then it came into the marketplace that we would do that refactoring, um, because it made our lives easier again, like the more you can do in the infrastructure, the better. Um, so it's never as good as having it be in the marketplace. So we try to keep up to date with what's there, but, uh, it doesn't mean, I think the other way to think about it is you don't have to just use everything in the marketplace. You can use anything and, and you don't have to be stuck with only what's in there, but it is more to maintain when it's outside. When you're talking about how things are really boring from an infrastructure perspective,

um, but that's a good thing. And maybe this is something you already talked about. What are the kinds of things that you, you do celebrate? What are the metrics, the kinds of things that you do want to see? Like this is, this is where it shouldn't be boring. Like infrastructure should be boring. Great. We're really focused on product. We're really focused on our customers. Therefore, this is where the exciting stuff happens. How do you measure and look at that? Yeah, sure. So, I mean, I think the way I mean, think about our newest product dialogue, right? Um, the things that we don't worry about are, um, scale. So lots and lots of, you know, it's an audio product, so lots and lots of listeners, we don't worry about there being too many listeners. Um, lots and lots of shows. We don't worry about lots of people creating shows. Um, we do, we actually do load tests on these things also to see that the infrastructure can scale to, you know, five to 10 X what the current load is. So we don't have to worry about the re-architecture until the next phase. Um, but that's what makes it boring. Like it's pretty, it's, it's, we're not even looking at those things. It makes it, uh, very easy to focus on things that do matter. So in our, in our case, the things that do matter are, you know, when, um, we have a show with Jake Tapper, how many live listeners are there? How many are supported? How many people are trying to call in? How many shows do we have per day and per week? Like all this, all the business metrics that we care about are things we can actually concentrate on versus having to worry that will the infrastructure support it? Is it going to be up? Is the latency too high? Um, is the user experience, are they experienced extreme slowdowns? Like we don't worry about the things that, um, you know, I would call the non-functional requirements. The things you assume are already there, but only when you run into them, you're like, oh crap, we have to do work to get that. Uh, we don't, we just focus on the end user. And those are the metrics we report to our customers. Like, hey, here's how many listeners you had. Here's how many people listen to it afterwards. Here's how many shows were created per week. Here are the top shows of the week. Like all the things you would imagine as a business user. Um, we never send things like six nines in reliability, latency, like the things that people, people should not care about. We never report them. Like I actually don't even know what they are because we don't care. It's a non-issue.

Okay. Um, so, and you know, what's, what's next looking ahead, uh, where are you looking to sort of expand or, or build from either a technology perspective or product perspective, whatever you want to kind of get into? Yeah. So what's amazing about dialogue and what an audio in general is it's a, it is a growing, um, it's a growing marketplace of content, right? So, you know, I would say in on the internet, right, you, of course you have text, text is everywhere, text is growing. Um, but you have like video and audio, which are now because of, you know, better hardware, better networks, social norms and behavior. People want to share things that are more compelling. And so with audio in specific, it's a very, very fast growing medium, right? It probably a combination of AirPods, podcasting, audio books, all growing at the same time, and then social norms changing so that it doesn't look weird when you see people walking around with talking, looking like they're talking to themselves, but they have AirPods in or Bluetooth headset or earphones. Um, and that makes it a place where, you know, audio can be consumed in so many more places than video can, for example, or even text. Um, I take the streetcar or subway or I walk and I'm always got a podcast on. So from that perspective, it's a growing medium. And what we, like I mentioned, what we're focused on is making it interactive. And we think that the things that we have to build in order to make that more compelling for folks are deeper, enriching experiences. So for example, right now our entire platform's on the web, it's mobile web, it's desktop web. And with lots of people say, I really want, I really want this to be a mobile app because then I can do, um, things that I couldn't do in the mobile web, get notifications, potentially subscribe to different people. Like there's lots of different UX models that can be built. And so then for next for us, it's probably interacting with our backend in a slightly different way, but via a mobile app. There's probably a few

things that like, you know, we're recording this on Zencaster. I want to be able to have high quality audio broken down by audio stream. We assemble those, um, so that it's a higher quality experience for the, for the recording. So there's all sorts of things that we can do to make the experience even more compelling and more interactive, um, for folks so that we are able to, um, really, really bring audio everywhere for those, for those people and make it live and interactive, which you can't do right now on podcasting and audio books. Right. I'm a little terrified what that would look like though. If what terrified, terrified how, uh, we'll just, you know, here we get to make up all of our own, um, uh, left field analogies or, um, examples and yeah, you know, it would just be, it would just be a little bonger balls to have like anyone in the world kind of being like, why are you talking about margaritas? It's a tech, you know, podcast. Yes. Yeah. Well, I mean, I think, but I think that's, that's what's, that's what's interesting about the content. He literally hit the nail on the head. Even though if it's, even if you listen to it afterwards as a recording, live content is different because like you said, anything can happen. Right. And what we're seeing is that because of that, anything can happen attitude. And for these people with large followings to want to interact with their audience, not just talk at them. Right. If you're talking on TV or even on a podcast, you're just, you're talking to people and you can't get feedback. They can't talk to you back. And that's where literally the idea came from us was we were listening to all these great people over podcasts and like, Oh, I wanted to, I want to respond to that. And I can't. And it does make, yeah, right. It's you yelling at the TV and instead, um, and you do see this happening all the time, like product on called it Twitter for voice because you do see this, it's just on Twitter. You don't see it in any other way. Right. Um, and I think that's, uh, that's what's going to change. Okay. Yeah. No, that's me kind of shouting at the crowds as I walked down the street. Okay. And then we'll have to like, um, actually, instead of just all capsing when we're trying to

yell on Twitter, I'm just like, actually yell. Actually. Yeah. Well, and actually it turns out because we're human, right? Like that you don't usually in react the same way when you're, when you've connected with someone over voice that you would over text, right? Like there's a, there's a podcast where this person calls everybody that was yelling at them on Twitter. And the first thing they always say, they're like, they say, Oh, I'm sorry. Like I didn't, I didn't know. Like they, that's the first thing they say, because you're talking to another human versus in text, you can just like all caps and like WTF. And I don't understand. Right. You can do that. And with, with voice and connecting audio, it's much more civilized, but even without video, even just voice, it changes things. Like when somebody calls you, it's a big difference. Well, then, um, clearly we're just going to be cleaning up the world and making it a better place. Uh, so thanks so much for, for joining us and taking the time. Um, where can folks kind of learn more and follow you and, um, just continue their, their conversation with you? Sure. So get dialogue is at uh, I just said it get dialogue.am. That's the name of that's the URL where dialogue is hosted and people can follow me on Twitter. It's just, uh, F N as in Nancy and my last name flower, T H A W A R at on Twitter. Okay. All right, folks. Thank you so much.

Tanzu Talk · 🍕 Get more pizza.