59. Catch the Tornado with Brad Buda

Piotr Karwatka  0:48  

Hello, everyone. In today's episode, We’re having Brad Buda, co-founder of Census, the operational analytics platform. I’m gonna ask him, what does it mean- an analytical platform? How they are doing the crazy numbers they're currently doing, (they are backed by Andreessen Horowitz and Sequoia, just to mention a few of the investors). And, of course, we're also gonna talk about why the Data Tools licenses but also data bricks, snowflakes are so hot right now, what makes Census unique, and how to manage the exponential growth. I'm excited to target all through with Bradley today. So let's get started. Thanks for being with me.‍

Brad Buda  1:30  

Thank you for having me on. It's a pleasure. And I've been looking forward to it.

Piotr Karwatka  1:34  

Awesome, awesome. So first of all, how I got to Census. I think that that's a pretty good starting point to our discussion, because I like reading all sorts of reports, technology, rather, enterprise tech 30. And actually this latter one Enterprise Tech 30, it was the first report where I spotted Census, it was in the top 10 of Data Tools. And actually, what, what struck me the most, you know, all those enterprise software tools that are growing right now, so rapidly, our data tools, you know, data, bricks, snowflakes, Census, do you agree that we have kind of new renaissance of data tools have been used before? Like, this is a completely different product offering.

Brad Buda  2:29  

I think I think we absolutely do. I think you're right. And I'm glad you found out about us that way. We're still a small company. So I'm always eager to hear about how people find out about us. I do think that dataspace is having a renaissance, I think this kind of trusty old SQL and data warehousing technology that, you know, predates my career is for some reason, again, hot. And I think, you know, there's a few reasons for that. And some of this is trendiness. To be sure, our industry is not immune to trends. But I think, you know, over and over again, generations of developers and operators are discovering that everything flows from the data. And there was a long move, I think, for a long time. And I'm happy to geek out about this, too, about how different back office applications and products were trying to be oriented on triggers or events or API's. When the ground truth of everything is always data, that's where it comes back to. And I think people are realizing that, like I said, we realized this once every generation and we're realizing it now. That if you want to control your tools, or understand your tools, understand their data,

Piotr Karwatka  3:30  

That's interesting. We had all those tools like Tableau and other BI and warehouses and other stuff before what happened with those tools.

Brad Buda  3:43  

Well, they haven't gone anywhere. You know, I think I think data warehousing has been you know, even though it has gone up and down and fashionability and right now it's, it's riding a wave of fashionability with with snowflake and BigQuery and Redshift and data, bricks and Roxette in any number of other data, data warehousing technologies that are becoming popular now. It's become more accessible because it is in the cloud. But of course, I think the data warehousing space has done a pretty good job of keeping itself relevant for a long time and the BI space as well. You know, the rise of web based bi and things like Tableau or Looker or, or other tools like that have really been steadily marching for the last 10 years or so, or even longer. And I think what we're seeing now is an ability to say, Hey, we've built all of this data infrastructure. It's very powerful. We know a lot of our businesses. What else can we do with that infrastructure. And that's sort of the wave that we're riding at Census is, you know, the only application for your data warehouse isn't just a BI tool, or even a machine learning platform, which is a third thing that's sort of driven across the industry. But you can use this data to run your business in a very tactical way, not just in a strategic “let me deliver a slide for the board deck” way.

Piotr Karwatka  4:51  

That's interesting. And yeah, that's really interesting. I mean, to use the tools on a daily basis and by a wider range of people also because they are easier to use. And I think it is maybe even more importantly, they are easier to deploy, because now the Tableau or other things that, you know, are difficult to use, especially for data analysts, right? But to deploy it at scale, it was crazy difficult.

Brad Buda  5:25  

Yeah, ease of deployment. I mean, this is where the cloud is sort of, you know, eating, eating all software, right? Data warehouses were one of the last things to get cloud enabled. And, you know, that was obviously something that I think Amazon was first to the game, but but snowflake, in some ways, did it better, and said, hey, you know, you can have an elastically scaling data warehouse, where you only pay for what you use in a very short period of time. Admittedly, you know, when we started census, snowflake wasn't even fully self service, you still needed to sort of talk to a sales rep to get yourself a snowflake instance. But I think anytime you make something easier to use, or to get out to just to deploy, you're gonna have more users. And the data space is definitely benefiting from that. It's maybe one of the last pieces of enterprise software that's benefiting from this sort of cloud centric deployment.

Piotr Karwatka  6:12  

Again, we absolutely get to this once again, right around, I mean, because it's so important that you're enabling, you know, all new categories of users. You have SQL instances, which is, you know, familiar with a lot of people like office assistants, no SQL, like everyone uses SQL, but not at the scale. And you know, it's second generation for me, it sounds like second generation tools, like you have Hadoop and other big data tools. Crazy, difficult, crazy difficulties. Even for developers, it was crazy difficult to use. Now, it's, it's a new era. It's exciting. But let's go back two steps back to your background, right? Brad, how did you get to software engineering, like, what was your way to Census?

Brad Buda  7:06  

It's a long story, I'll keep it as long or as short as you would like it to be. But the way I got to software engineering, I was, I mean, fascinated with computers since a very young age, like, you know, I think my first programming class and I was very lucky to have this resource available to me, I was six or seven years old, and my school had a little computer lab ad. So very, very on the leading edge of what we now call STEM education, but they had a small computer lab with about 15, Apple, Apple, two Gs, I believe, was the model number Exactly. That ran, you know, you booted up the computer, and you got a basic prompt, and you could either put a disc in and run a game or you could start writing code. And so of course, I played all the games. And then once I was done playing all the games and had gotten everything I could have thought of Oregon Trail and lemonade stand, I started learning how to write code and there was a small after school class offering learning how to write Apple basics. And then I was also again, very fortunate to have a home computer not long after that, an IBM a 286. I think it had a eight megabyte hard drive. And probably 512k of RAM somewhere in that neighborhood. It was a very, I think, even at the time, it was maybe a hand me down computer, I think we got it from a neighbor. But it was more than enough for me as a child. So you know, learn to read basic Microsoft dialect there. And then later Visual Basic. And then the other thing that you know, I had access to at that age was a modem and access to BBs. And then later on, you know, the early online services in the US that was, you know, Prodigy at first for me, and then America Online, like everyone else had. And so both learning about programming and learning about networks were things I was extremely fortunate to have access to as a child, and it's just sort of a smooth path from there. I studied computer science in university at the University of Michigan. And then when I was coming out of school, it was the year 2003. So we weren't too long after the.com crash in the US. And the job market was a little soft, I wasn't really sure where to go. And my best friend had just completed an internship at Amazon in Seattle. And he said, when I was growing up in the American Midwest, it's kind of a sleepy suburb, a great place to grow up, but maybe not the most culturally dense capital of the world. And he said, Brad, Seattle's amazing come on out here, I can help get you a job at Amazon. It's not just the bookstore. He was working on some interesting software that eventually turned into the simple queue service SQS, which was Amazon's, I think, second ever web service. And so he said, “come work at Amazon”. And so I gave it a shot. I spent the first three years of my career there at Amazon, in the era of, you know, kind of the birth of AWS, and worked indirectly on a couple of AWS services, including the cloud one is now today the cloud watch service, but was working on a lot of performance monitoring and at the time, big data. And the numbers are embarrassing now, you know, I used to brag about it and say our team processes, I think the number I used was 50 terabytes of data a day. And people's minds were blown by that back in 2005. And now that number is not so impressive when you put that on a couple of, you know, I think all the MacBook hard drives in this office at 50 terabytes of capacity between them. So I started out at Amazon. Yeah, I worked on early web services, there was and this was the era too at Amazon, when there was a mandate that everything was supposed to be a web service. So the idea was whatever your team had shipped before, think about how to ship it as a service, which now seems almost obvious and in retrospect, but at the time, you know, the thing that I owned, this large data processing system, was a logging pipeline. And it was essentially, like, we ran a small Perl agent, couple 1000 lines of Perl that ran on every computer@amazon.com, collected the logs and shipped them off to a fleet of NFS NFS servers, which was a very kind of like late 90s, early 2000s, a way to do log management. And we had done a great job of getting it running at scale. But we weren't thinking that wasn't meant to be a web service. Right? This was a sort of a thick client, you had to have it deployed through a central management software, you couldn't just consume it however you wanted to. And so that shifted approach of everything is an API, and you can consume it how you want to not necessarily how the API author wants you to consume. It was a big kind of formative moment for me in my career, and learning that, that Amazon from 2005 to 2008.

Piotr Karwatka  11:26  

That's absolutely amazing. I mean, you know, I know, the AWS was released for, I think, for quite a few years. For many people, it was just a virtualization platform, it set up the next easy to instance, or, of course storage device to write s3. But as you said, you had at Amazon that vision for encapsulating way more sophisticated things as a services before. So was it like, you know, that the vision was there to make a product or it was just for internal purposes, and then, you know, somehow evolved into what AWS is today.

Brad Buda  12:15  

It was both and the storytelling is interesting on this, because Amazon loves to tell the story about how the whole company was built on top of AWS, and, you know, then we released those services out to the world. And that's only kind of true. You know, the, the reality is that, you know, like most, like most large companies, we had big platform teams, although, you know, this is probably one of the first companies to have a large platform team, we would, you know, right there with Google and Facebook in their early days. And we're providing common services to other teams, right? It's a very standard relationship in a software organization, not everyone should invent their own performance monitoring, or alerting, or logging, or web server or whatever it might be cash, etc, etc. So I was on a few of those different platform service teams. But you know, the leadership at Amazon had the insight very early on to say, hey, you know, people, we've built something here that's unique. We have the largest performance monitoring tool in the entire world, and it's trapped inside of our data center. And that's a valuable product. There are lots of other companies who do things other than sell books on the internet who need those tools. So let's figure out how to get those out there and resell those. And it's a long journey. If you look at the arc of from the day that you know, the EDA came on down from management to say everything must be built as an API, to the time that I started doing some of the early designing CloudWatch, to when it actually shipped publicly, and then even further to when that actually shipped internally. Because the interesting thing about a lot of these Amazon Web Services they shipped to the public before they shipped internally, of course, they were available to other Amazon teams, but you weren't compelled to use them. And they were alternate techniques. You know, so I think I'm long on Amazon. Now. It's been 10 years since I set foot through their doors. But I think that most Amazon services are now actually dogfooding those tools internally, but that wasn't necessarily the order in which they shipped. I think it was probably many years before, from the time that CloudWatch, for example, shipped to the time that an internal Amazon service was actually using that as its only monitoring service.

Piotr Karwatka  14:09  

Awesome. Really exciting to have this, you know, firsthand view of how things evolve now. But how did that lead you to the idea of Census, how did it all you know get started?

Brad Buda  14:25  

Sure. There's a couple of you know, I think the first step was making the startup bug. So I was fortunate to have, again, another bit of luck in my career a great manager at Amazon, who, you know, I was disappointed when he left the company, but was excited a year or so later when he called me up and said Brad, the reason I left as I'm starting my own company, it was a ad tech analytics platform called track simple. And he wanted me and my coworker Anton, who is now my co-founder at Census to be the first engineer in place. So we went and joined there with a little bit of a friendly push. And it's definitely hard to get out of the Amazon Best out of the finest that remains true today. I think there's a lot of entrepreneurial types within big tech companies that just need that friendly push. And I got mine from John. And he said, Come join me, be the first two engineers here, take a huge pay cut, but I'll give you some equity. And let's see if we can build something together. And that was my experience of, you know, my first professional programming job was me providing services to serve teams that provided services to 1000 person engineering organizations. And all of a sudden, it's, you know, three of us engineers sitting in a room with a blank piece of paper saying here, let's draw the product here. And then let's figure out how to build it there. So a radical shift in the world, but something that I absolutely loved. And the thing that got me, you know, that kept the startup bugging me was not just the feeling of, you know, strong product and engineering control and the ability to do whatever you wanted, but also like they take us to the customer. The thing that really impressed me with that job was that we had a customer who I could name, I could look at, I could get on a video call with a phone call. And if that customer had an issue with the tool, we could fix it. And there was no bureaucracy, there were no layers of indirection, we didn't always necessarily do it the way that the customer wanted us to do it, right, we still had our own product opinion. But we had the ability to directly within, sometimes as few as 30 minutes, and sometimes, you know, the longest it would be will be a day or two to release a feature back into the product that would make our customers life better. And that's a really powerful feeling that the rapid cycle of someone has a problem. I know how to fix it, I have fixed it. And now they have a solution.

Piotr Karwatka  16:32  

I heard the term for that. Recently, radical customer intimacy. And it was more for enterprises doing open source multi brand works the same way, like open source for enterprises. Super exciting, sometimes just before they get this first hand feedback from devs, right.

Brad Buda  16:51  

Awesome. Yeah, I love that. I haven't heard that term. But I love it. I mean, it's, it's something that you end up doing. Just in the course of business as a start up, you don't have to think about being intimate with your customers, because it's just, it's the only way to be. But it's something that you have to remember and hold on to. And I think we're at an interesting phase to fast forward a little bit to Census, where as we scale our own organization, we're now getting from the point where we're accidentally intimate with our customers to being very intentionally intimate with them, and making sure that we, you know, are keeping that responsiveness and keeping that that superpower that a small company has. The stop between?

Piotr Karwatka  17:26  

No, that's awesome. We can continue about this intimacy for long, that's for sure. But let's back how have you know, having this started back? How would it lead to success? I can't wait to hear this story.

Brad Buda  17:44  

You've asked me this question three times. So this time, I'll actually try to answer it. So you know, after starting a different company, which was a identity and access management company, with with Anton who I was with at trek simple. And my my now co founder, Boris, we had a sort of a small exit from that company and knew that we wanted to do something bigger and better. And that was how we got to Census. And it was a long kind of twisty journey, we knew that we were really good with integrations, because we had worked on that, you know, being early in the the web service days at Amazon, and then working on integrations and my SSL product. And we knew that we really want to do something around data and around customer data and around making enterprises successful. You know, something that had always frustrated us as founders was how quickly data could proliferate across different Saas systems, and how difficult it could be to track a customer's journey through your product with all those different panes of glass. And we are far from the first people to realize this problem. We came up with sort of a different way to solve it. We brought on a fourth co-founder, Sean, who had, you know, he has the best Rolodex of anyone in Silicon Valley. And he had been talking to some of the folks at figma about their problems. And they said, Hey, we've got this data warehouse, we have, you know, a couple million customers in there, whatever it was at that time. And we have fantastic views on what all of them are doing. And the only people who can see that are see pointless, no one else has visibility into this data. They had visibility into it through their BI tools. Right to go back to your earlier question, right? They had them I don't remember if it was moto Looker, Moto Looker dashboard where they could sort of see an aggregate of how the customers were behaving. But they had this really rich, almost clickstream level picture of each customer that was just getting lost in the noise. And they said, Hey, we've got you know, 100,000 leads in our Salesforce, we need to figure out you know, which one of these people we want to talk to can we do that rather based on you know, instead of looking at their name, or their domain name, or what territory they're at, or whatever, to make sure that their product usage and figure out which ones you should talk to based on who's actually using Figma in ways that suggests they will become an enterprise customer. And we ensure we can help you build that and they said, Okay, we've done it all this thing called a data warehouse. And you know, I was not really intimately familiar with the data warehouse space at that point, I knew that there had been a resurgence in data warehousing. The Five Tran founders are some close friends of ours and I'd sort of been following them you know, indirectly and saying I think they do something for enterprises with databases, not really sure what it is. And as we got to learn more about that space, we, we realized that there was sort of a missing link in this chain, right they, we'd see these big diagrams, which was all the data flows from here to here to here to here to here, and it ends up in the Data Warehouse. And that was always the last line of the diagram, no matter what the diagram was, the data warehouse was always the last line and simple insight that Shawn and my co founders had was, why don't we draw a line that leaves the data warehouse and goes back into the tools where people actually do their daily work like Salesforce, or Zendesk or NetSuite, or wherever it might be.

Piotr Karwatka  20:28  

This is super important for the point you raise up like the data warehouse used to be the very last piece of the puzzle, usually, which means there is typically, you know, a lot of delays to access the data. And usually you can access them when it was too late for many use cases. And this is the difference, right? And how you define the operational analytics that you can get it right when the data changes to some even triggers this kind of no real or close to real time cases?

Brad Buda  21:08  

Yeah, I think that's a great description of it. And the interesting thing about that, as you point out, right, the delay in acting on your data warehouse data was not a technology delay, it was a delay in the way that we use the data, right? And that's the nature of what do you mean? Well, it's the nature of a reporting tool of a BI tool, right? A BI tool. I mean, they do have some features for this now. But BI tools are generally not there to trigger or notify, or proactively take action. They're there to sit there and create a dashboard or charts that you can review later. Right. So as long as you are, as soon as you have introduced a review step in your pipeline of let's all go look at the dashboard together, either maybe in a weekly ops review meeting, or in a you know, God forbid, a quarterly board meeting. Now your data is gotten stale. So the nature of BI tools, as the output is a dashboard and a person has to look at it, introduces human latency, right? Are we all gonna go decide to look at that dashboard together? Yeah. So when the tool is, you know, when it's an operational analytics tool like census, that's actually pushing the data into, you know, your your line workers, your salespersons, your markers, you know, surfaces that they use to run the business, you don't sort of have to make a decision to look at, you don't have to build a process around looking at it.

(...)