Episode Transcript
[00:00:04] Speaker A: All right, everybody, welcome to the True Data Ops podcast.
This episode of the show is going to be very, very exciting. I'm your host, Kent Graziano, the Data warrior. Each episode, we try to bring you people and activities that really showcase what's happening in the of data ops today. Now, if you haven't already done this, be sure to go look up and subscribe to the dataops live YouTube channel because that's where you're going to find all the recordings for our past episodes. So if you missed any of the prior episodes, you can always go back and catch up. And better yet, you could go to truedataops.org and subscribe for the podcast. And then you'll get the notifications when we have new podcast schedules. Now, for those of you who are regular viewers, just want to let you know this is going to be a pretty, I think it's a pretty exciting topic we have today, so we might run a little longer. And if we do, don't worry about it because you can always catch the replay on LinkedIn and be posted immediately after the show. So my guests today are two of my budies from Snowflake. So, Vernon Tan and Rob Guglietti. Now, they both were sales engineers, amazing sales engineers. And then together they founded what is now known as the Frostbite team at Snowflake. So we're going to have fun time talking about all that. So, Rob and Vern, thanks for being on the show today. Glad to have you here, and thank.
[00:01:40] Speaker B: You for having us. We're very excited to be here and talk about all the good work we've done with Data Ops live.
[00:01:48] Speaker A: All right, so to get started, why don't you guys take turns here and give us a little introduction to your background in data management and particularly your journeys at Snowflake.
How did we get here?
[00:02:05] Speaker B: Absolutely. So, for myself, I have a bit of an unconventional background. So I majored in criminal intelligence, got into analytics and telco, and from there got into sales engineering and basically became a career sales engineer. And in doing so, I learned a lot about the different problems that different organizations had with data, managing it, having the right pipelines in place to deliver data to end users, and then what do people do with that data? How do they get value out of it? And that's where I learned pretty much everything that I know about data management.
I started out as a sales engineer at Snowflake and started doing cool projects, building out demo content and solution content alongside Rob, actually. And we started the Frostbite team as a result, where we build out industry solutions for all of Snowflake, deliver that content to the field and to our customers, and showcase what Snowflake can do to solve business problems.
[00:03:14] Speaker A: Very good. Rob, what about you?
[00:03:17] Speaker C: Yeah, I started my career over several decades ago, starting in 98 with the Y two k problems and all the craziness that brought.
It'd be interesting how the new automations of today would have helped solve those problems and simplified that whole craze.
Moved into contact center industry, helped pioneer some of the voiceover IP IVR contact, or CRM system integrations, went from there to kind of the banking industry and kind of brought mainframe data over to modern data stack.
Worked with cobalt and kind of all that fun stuff from there, went on to different consulting gigs and ended up joining SAP, where again focusing on a diverse set of industries and customers, solving some of those transactional system and operational system type problems.
And then that's where I ended up meeting Vernon, moving into the sales engineering of SAP.
We kind of worked together on kind of selling that vision. Vernon moved on to Snowflake and kind of told me, hey, Snowflake has solved this problem of separating storage and compute. Obviously, I didn't believe him, but he could.
And here we are today, working solutions on kind of the cloud data platform with Snowflake.
[00:04:47] Speaker A: Wow. Yeah.
I definitely encountered that particular attitude when I started with Snowflake in 2015. As every talk I gave, there was always somebody in the audience that say, well, that'd be awesome if it was true.
They didn't believe that what Snowflake could do and how it did it, reinventing this architecture. And it's like when I started at know, one of the reasons I find this whole conversation we're going to have so exciting is to do a demo.
I was brand new to Snowflake. Steve Herzkovitz, who is the head of sales engineering at the time, would always end up having to come over to my laptop and help me unzip a tar ball with a bunch of python scripts in it. And of course, they would not always run right on my machine, and the demo wouldn't always be completely set up, and it was a nightmare trying to figure out how to debug it. And over time, of course, that got smoother and smoother. And now with the growth at Snowflake, it was exciting for me to see this frostbite team that you guys formed to help that to get better. And then now we're talking about this even more of an evolution with this internal release of what you're calling the Snowflake solution center, which is powered by Dataops Live.
And if I understand correctly, this allows all your sales engineers and your field ctos inside of Snowflake to really go out and do the demos and the presentations and present solutions in a much more seamless manner. I guess so what I really want to talk about is hear from you guys, is like, what problems were you really trying to solve there, and how did your frostbite team end up getting involved, and what role did you all play in putting the Snowflake solutions center together with data live?
[00:06:40] Speaker B: Yeah, so I could start, and then, Rob, you could chime in as well if I get anything wrong, or if you want to add on to it. But the genesis for all this is, it pretty much goes back three years ago, where we formed the team. We started building out content, and we realized that rolling out end to end solution assets for people to adopt on their own machines, on their own Snowflake accounts, is kind of a complicated proposition. So for anyone who isn't familiar, the way we roll out demo content at Snowflake traditionally is every sales engineer will have their own Snowflake account. There isn't really a shared one. There may be a few shared ones that teams use, but we have to deliver end to end content to all these individual demo accounts, and there are thousands of them. And three years ago, it was already complicated enough to deliver it to hundreds of demo accounts, because if you were to think about it, they have to get the data delivered to their snowflake account.
There has to be a pipeline to do that, right? So what I did is I set up central Snowflake account and a replication ring around the world to basically replicate all that data to every snowflake cloud and region available to snowflake sales engineers. Then we set up data sharing for people to access all that data without really physically moving it after the replication is over. So at the time, that definitely served its purpose, and it still does. We still use that framework today.
But doing that alone isn't enough, because what do you do when the data lands in that snowflake account? How do you instantiate any first class objects, like tables, views, or anything else that people actually need to work with that data and deploy the solution?
How do you, I guess, manage versions? How do you roll out the code for people to run reliably and make sure they don't run errors? And then how do you do all the stuff outside of Snowflake as well, like Jupyter notebooks? At the time, we also only had streamlit, open source, not streamlit in the product. So there were a ton of moving parts that needed to be managed. Right. Python packages, you name it. And it's very complicated to manage troubleshooting for hundreds of snowflake accounts around the globe with our humble team of eleven. Right.
So the basis for the problem is how do we do this at scale? How do we do it in a way that is seamless for end user group of hundreds of SES across over 1400 demo accounts, right?
[00:09:36] Speaker A: Well, and you say hundreds, but it's north of 750 now, right?
[00:09:42] Speaker B: Yeah.
[00:09:45] Speaker A: That'S a lot. You're starting to push 1000 sales engineers and field ctos that are trying to do presentations and demos in the field, like you said, all over the world.
[00:09:56] Speaker B: Exactly.
[00:09:58] Speaker A: And have it all be seamless in the process.
[00:10:01] Speaker B: Right, exactly. And 1400 unique environments. Right.
[00:10:06] Speaker A: Wow.
[00:10:08] Speaker B: Yeah.
[00:10:10] Speaker A: And of course there's new features and private preview and public preview and all new stuff continually coming out on top of it. So it's not like it's static.
[00:10:20] Speaker B: Exactly. So as we update content, if we simply pushed out changes via GitHub and tried to get people to manually instantiate those changes, well, people get left behind. Right. And they might be on an unsupported version, an old version that maybe we're not even on anymore, and it makes that supportability problem even worse. Right. And I don't know, Rob, is there anything you wanted to add there? Did I capture that correctly?
[00:10:52] Speaker C: Yeah, pretty much. I mean, we understood that our solutions were evolving with Snowflake, and they're getting more and more complex over time. So moving from straight data warehousing type feature function into full fledged data products, data applications, data solutions that leverage the entire data cloud, from data science to data warehousing to data lakes, data applications. So these things grew more and more complex, and it was harder and harder for sales engineers to kind of pivot on the fly and showcase the power of snowflake to potential customers without having a massive amount of time to set those things up. We had in GitHub thousands of lines of instructions and codes to set up some of these things in the past.
Moving forward with data ops and kind of trying to address these things, we were able to kind of put those into a box, if you will, in that providing a catalog to sales engineers that didn't need to know how to deploy the actual solution. They obviously understand how snowflake works and the value of Snowflake. They no longer needed to spend the actual time to run and kind of build out these models, data sets, tables, views, RbAC, et cetera, et cetera, et cetera. That's now been packaged into these solutions, therefore simplifying how they go to market and how they can sell the value of snowplay. So I think that's a game changer for us as it relates to scaling, solution and value selling here at Snowflake.
[00:12:31] Speaker A: Yeah, in the marketplace, say there's a lot of discussion about data products, and you've used the term data products, you've used solutions a couple of times.
The goal, and one of the ideas in my mind behind data products is you can have people with, I'll say, less technical expertise necessary in order to access these data products and do the analytics, do whatever it is that they're trying to do. How does that fit in here with the Snowflake solution center, those ideas?
[00:13:04] Speaker C: Yeah, exactly. I think from our perspective, not everybody is an expert in all the different workloads.
And so if you need to showcase an end to end solution, you have the abilities at this point to leverage the catalog, have them automatically deployed, and go as deep as you can, and bring in the experts when you need to, to deep dive on the technical side of things. So these data products allowed us, and again, I think we're using this term interchangeably here with data products solutions demos. Ultimately, what we leverage with data ops live in our solution center is a catalog of assets that an individual sales engineer at Snowflake can leverage as a tool in their bag to showcase to potential customers.
Sometimes are the possible, sometimes solutions that can get implemented by SIS or snowflake services teams, sometimes the code can be shared with the customers. So they have that catalog now that allows them to highlight those things when and where it makes sense to their individual accounts.
[00:14:12] Speaker B: And the other part of that, too, is from a data product standpoint, it's all about eliminating friction as well. Because no matter how good your data product is, if the path to adoption is not there, you're not going to be successful. And if you're watching this right now and you're working for a tech company and you're rolling out data products internally or externally, or if you lead a digital team at a big organization and you're rolling out data products that people need to run to be successful, one of the main things that we started to really think about is reducing, guess the areas that we wanted to reduce friction in are a few things that Rob touched on, discoverability of the asset. So having a catalog where people can see here are all the data products that are available to me in this context, people are looking at what data products are available to them to sell snowflake, but this could apply really anywhere.
Discoverability is 1 second. Being able to filter through and figure out what are some of the parameters that I need to filter on to get to the right data product that I'm looking for, or a set of data products, what are some of the end outcomes these data products drive towards?
And next, how do you deploy it? How do you very simply remove the friction in deploying these data products at scale? So from an end user perspective, we wanted to make that dead simple, because if you look at how Apple does their product design, it's seamless. They have some of the most complex technology on earth, but they abstract all of that complexity in every single one of their product design choices. Right? Like when you look at airtags, for example, if you're trying to keep track of your luggage, there's no complicated pairing process. You simply rip off the tag, off the air tag, hold it close to your phone, and then suddenly you've got tracking enabled on that air tag that you can put in your luggage, you can put in your car, whatever you want to do.
And it's seamless, it's a beautiful user experience, and it's something that we keep in mind every time we roll anything out.
[00:16:36] Speaker A: Yeah. So in keeping with the pillars of data ops, you're hitting a lot of them. It's like you mentioned GitHub. So we've got the CI CD sorts of things for developing it, the version control, environment, management, collaboration. This part you were just talking about, about making it easy for people to access it and see it. And I assume there's also governance in there too. It's like not everybody inside of Snowflake sees all of the products. And you said the filtering is all there and things like that. Seems like that's a key aspect of all of this as well. I imagine it would be overwhelming. You're talking about how many different demos and deployments and feature sets are out there, right, for one sales engineer to try to get their head wrapped around in order to do this.
[00:17:34] Speaker C: Yeah, like I said, I think we embody a lot of those seven pillars in our daily lives on the frostbite team, starting with the ELP side of things, where as Verna mentioned, we centrally host hundreds and hundreds of tables and data sets to support some of these solutions that through our pipeline, processes get into the accounts of the sales engineers, and it kind of acts like a customer account. So what would a customer's account look like how would I get that data into the raw layer and then moving in from the raw layer to the different zones or layers or whatever modeling techniques they may apply. So these solutions that we've developed because of the way we've automated this, we don't simplify the solutions themselves to allow something to be seen. They still have the complexities in the background. So you're not trying to show the value of the data platform with one table and 1000 rows or three tables, right. So we have mass amount of data sets and models that are driven through these pipelines. And that's why in the past our GitHub and every postitors and instructions are so complex because we did not want to dumb down these solutions in a way that they lose their value.
So again, even starting from the ELT there, that is still maintained through what we're doing here, obviously the CI and CD, and that's massive. So as we move into 1020, 30, 40, 50 different solutions across the organization, and we have different levels of deployments in those 1400 accounts, if Snowflake upgrades, let's say the Python version, how do we know, and we roll out a change for that, how do engineers know that, oh, there's been a fix or an update, or I'm behind in a version, how do we get that out? How do we maintain that is all part of our CI CD as well as automated testing and monitoring. So looking at things all the time, we haven't fully automated this part yet. We're getting there, but making sure that we're not reactive to problems. So as these solutions are run right now and in the past, we're notified by sales engineers that are about to do a demo to a customer and all of a sudden something doesn't work.
And that's not a very good experience for anybody. So getting in front of that and having these automated tests running, monitored and actioned allows us to be way more proactive and provide a lot more reliability and comfort in this large amount of solutions within this marketplace.
[00:20:21] Speaker A: Yeah. So Rob, you're the development manager for the industry solutions team, right?
[00:20:27] Speaker C: That's right, yeah.
[00:20:28] Speaker A: So your team is actually using the dataops live platform then to do all of this work and keep things up to date and roll out data products to the field.
[00:20:41] Speaker C: Yeah, exactly.
So we've been searching for some help in this area. As the solutions teams grew and frostbite team grew within Snowflake, we looked at different options, whether it's homegrown, home build, paper solutions, et cetera, to kind of COVID all of these pain points that we know we're talking about here today.
But leveraging data ops and the solution there internally with the actual build team was a massive efficiency for us as it relates to more complex builds, multiple developers working in tandem on the same project, being able to share and kind of being agile in the way those assets and different parts of the code, whether it be the model, the table or ELT processes or pipelines, those now are much more easily shared amongst the team. And kind of that release management process has been simplified. And again, the true value of that is coming when we make changes to solutions and or we update solutions as the technologies evolve themselves and we get more features becoming available within Snowflake, let's say like notebooks or cortex, et cetera, we have constant innovation, constant change happening that we are now managing within.
[00:22:15] Speaker A: Okay, great.
So you've, I assume in the process then prior to this it was a lot of hand scripted things because I know certainly Vernon and I worked with a lot of hand scripted stuff in the early days. So have you. Fundamentally you're replacing a lot of the hand scripting and like you said, thousands of lines of instructions with the functionality that's in the dataops live platform.
[00:22:42] Speaker C: Yeah, the way we've done that is through creating templates and kind of working through frameworks where a solution itself will always have some similar principles, let's say like RBAC or warehouses or our data zones. So these things are repeatable across solutions. And it's kind of some of our methodology that we've now worked with data ops to kind of create those templates. So as a starting point, those things we no longer have to look at, whereas in the past, as you suggested, they've been totally scripted using standard SQL. And now within dataops we follow a more decorative approach to that output.
[00:23:25] Speaker A: So it sounds like you guys really formed a real good partnership with the solution architects and engineers at Dataops live in putting this solution together for Snowflake.
[00:23:36] Speaker C: Yeah, in this case, the actual Snowflake solution center was customized.
We innovated on this with data ops in a couple of different workshop sessions to figure out how do we get that kind of final pillar in collaboration and self service, how do we bring that to our internal users. And there the solution center was born, which provides us this kind of catalog and kind of the area that we struggled with in kind of sending sales engineers to GitHub where there's hundreds and hundreds of repositories. How are you going to find something that is actually of value and maintained and working in such a large, I'll say unmonitored or kind of not very much standards, if you will, on some of those repositories, because they might just be developer test accounts. And so, as you're looking for content and things to help your day to day life in kind of selling Snowflake, kind of the marketplace and this collaboration effort allowed us to kind of bring the level and the type of solution or demo or feature function that particular tile or solution was on the marketplace itself was available for the actual se.
Again, that final pillar and the collaboration effort with Didops to produce the marketplace was an amazing process, and we're very happy with the results.
[00:25:15] Speaker A: Great. So, vern, if you could summarize it, what's the value to Snowflake as a whole of having this solution center available now?
[00:25:27] Speaker B: Oh, man, that's a big question. So, the value to know right now, we're at a critical juncture in our evolution as a company going from simply selling technology capability to getting into actual solutions. Right? Like, how are we solving for the industry's most complex business problems?
And to make that shift with an entire sales force that is basically accustomed to selling feature function, product capability, and all that, there needs to be a path for them to easily adopt, learn, and sell solutions and business outcomes.
And having the Snowflake solution center in place makes that a lot easier to do, because from there, people can very easily discover what are the business outcomes that Snowflake can drive in specific industries. How are Snowflake features and functions contributing to that?
And how do I then easily deploy that solution? And if I were to quantify it, I mean, I don't have exact numbers here, but let's say without the Snowflake solution center, the average sales engineer would have to take one or 2 hours out of their day to set up a solution. But what if they had to set up five or six any given year?
I know that may not seem like a lot in the grand scheme of things, but they also have to learn it, get literate with it, start to master that solution in order to get effective selling it. And if you multiply that by the 750 plus sales engineers that all have to do that, without the Snowflake solution center, there's a massive, massive barrier to entry in people adopting these solutions. Because if it takes long enough, there might be only a few people that actually adopt it.
Maybe down the road a bunch of other people adopt it, but you'll still have a bunch of other people who think, hey, this is taking too long. It's too hard, I'm too busy, I'm not going to bother. And if we reduce that barrier to entry, we could accelerate the adoption of these solutions, accelerate sales engineers ability to execute on these, and also make the user experience very good. And people talk. Right. If something sucks and people hear about that, they're not going to try. Right. So to tackle all these problems and accelerate people's adoption of snowflakes, industry solutions will have a massive, massive outcome on snowflakes actual revenue targets down the road.
That's the impact that I'm seeing. Yeah.
[00:28:24] Speaker A: And I would assume that with.
[00:28:27] Speaker B: The.
[00:28:28] Speaker A: Productization, I'll say, of the demos and the automated regression testing and all that, I'm guessing there'd be significantly fewer oops in the demos. Right. We always joke, right, you're doing a live demo on a webinar. It's like, well, you know, it's a live demo because it just fell over. Right. I assume that that number has gone down dramatically with this.
[00:28:54] Speaker B: Yeah, exactly. And we've both been ses, so we know how those oops feel, and we definitely don't want our sales engineers to have that if it's.
[00:29:05] Speaker A: Yeah, no, that makes a lot of sense. So with all of this, and Snowflake itself has become a pretty massive enterprise, consumer of data. And the Snowflake product itself, do you think it's possible for major global organizations to really be successful at scale if they're not adopting some sort of a automated data ops approach like you guys have done with solution center?
[00:29:40] Speaker B: I don't think so.
We exhausted every possible option that didn't involve partnering with a company or purchasing a tool or platform. We tried everything in house, and I think automation could come from building something in house, but that comes with its own cost, technical debt, staffing requirements. And we explored that option and it was very onerous, very difficult.
[00:30:13] Speaker A: And you're a software company, you're actually a software company, and it's a lot, even for a software company, to build software to help manage their own work internally.
[00:30:24] Speaker B: Yes, exactly. And from there, you just have to think about what is the thing that you're trying to achieve and what are the options and how do you get there fast. And sometimes building things in house may not make sense. I mean, there are companies out there that prioritize building things in house. They have digital product teams that do all this stuff. But if you look close enough, everyone's using tooling that they've procured in order to achieve some level of automation, to achieve some level of scale.
And we have truly exhausted every option and data ops live delivered in a massive, massive way. And we couldn't imagine where we'd be now without their partnership.
[00:31:12] Speaker A: Wow. So is there any way that people see this solution center?
You're only going to see it if you're getting a snowflake demo from a snowflake sales engineer.
[00:31:26] Speaker B: That's a good one.
[00:31:29] Speaker A: I've seen it.
[00:31:30] Speaker C: I've obviously seen it myself.
[00:31:32] Speaker A: But it's an amazing product in and of itself, what you guys have developed.
[00:31:38] Speaker C: So if anybody out there in the audience, probably the best approach will be to talk to your friendly neighborhood account team and just ask what solutions are available that kind of are relative to my company or what I'm doing. And most likely there will be something available that account team can bring to you. Whether or not they showcase the solution center or not to you will be up to the account team.
[00:32:07] Speaker A: There's probably some sensitivity on some of the stuff in the solution center, I would imagine. But hey, you got governance, right? So you can hopefully control that.
[00:32:15] Speaker C: Exactly.
[00:32:17] Speaker A: Very good. Well, so do you guys go out and give talks anymore yourselves? I know Vern, you and I did talks together, data for breakfast and stuff up there in Canada.
People see you guys out there in the world. Anywhere other than or just Snowflake summit maybe?
[00:32:36] Speaker B: Yeah, Snowflake Summit is a big one. I'd love to do more, honestly. I love public speaking.
I love sharing the cool, innovative things that my team is doing.
I wish I could do more, but, yeah, Snowflake summit. Snowflake events are pretty much where we do a lot of our speaking.
[00:32:57] Speaker A: Yeah, well, and you've got the experience with what you are trying to do on the frostbite team is very similar to, I suspect, what a lot of teams at organizations are doing, certainly in concept, as they try to build out data products and deploy to non technical business unit or solutions that are going to work for know, when they click a few buttons, it's not going to fall over dead. And they don't have to know how to open a Jupyter notebook. They don't have to unroll a bunch of python code in order to make things happen. So I think there's probably a lot of good lessons that you guys have learned in the process that your prospects and your customers could learn as well from you.
[00:33:43] Speaker B: Yeah, I think so. A couple of Snowflake summits ago, actually, I did a session on rapid prototyping of industry solutions, or digital products, as we call it today, and there was a surprising amount of good feedback from Snowflake customers who were building digital products internally. Right. And whatever industry, manufacturing, retail, they weren't necessarily selling digital products like a software company would.
But they had to think about, how do we very quickly stand these up, prototype them, prove it out, get executive support and buy in, roll it out.
And there's definitely a lot here that we've learned that applies to a lot of different contexts. So I do think, as well, that this Snowflake solution center belongs anywhere. I think anyone could leverage this similar framework, even though Snowflake is using it for selling purposes. The principles, the concept, the delivery method, I think will apply to anyone trying to build and roll out a digital product.
[00:34:56] Speaker A: Great. So what's the best way for folks to connect with you guys?
[00:35:01] Speaker B: LinkedIn is good.
[00:35:03] Speaker C: Yeah, LinkedIn, perfect.
[00:35:04] Speaker A: All right. Well, as I expected, we ran a little bit over, but this has been a great conversation. You guys, like I said, have some amazing experiences now under your belt in first, establishing the frostbite team and growing it and building these solutions, and then your partnership with dataops live to build the Snowflake solution Center. So I want to thank, you know, Vern, Rob for taking the time to be on the show today and talk about your experience.
[00:35:36] Speaker B: Awesome. Well, thank you so much for having us, Ken. It's always good to speak with a data warrior. It's been a lot of fun.
And, yeah, please reach out anytime if you ever want to chat again.
[00:35:48] Speaker A: Love to do it.
[00:35:49] Speaker C: A lot of fun there.
[00:35:50] Speaker A: Yeah. All right, well, thanks, everyone, for joining us today. Be sure to join me again in two weeks when my guest is going to be the author of how to succeed with Agile business intelligence. He's a consultant and a self proclaimed bi artist, Raphael Branger, who'll be coming to us from, I think, Switzerland.
So, as always, be sure to like the replays for today's show and tell your friends about the data Ops podcast. And don't forget to go to truedataops.org and subscribe to the podcast so you don't miss the upcoming episodes. So until next time, this is Kent Graziano, the data warrior, signing off. For now.
