On this week’s episode of The Data Stack Show, Eric and Kostas talk with John Marbach, senior growth manager at Grafana Labs. In this conversation, John discusses marketing ops and the blending of roles of data engineering and marketing.
Highlights from this week’s episode include:
The Data Stack Show is a weekly podcast powered by RudderStack. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.
RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.
Eric Dodds 00:06
The Data Stack Show is brought to you by RudderStack, the complete customer data pipeline solution. Thanks for joining the show today.
Eric Dodds 00:16
Welcome back to the show. Really interesting guest today from a company called Grafana. I know that a lot of our listeners are familiar with Grafana. It’s a greatly loved tool. Kostas and I love Grafana. And we get to talk with John who plays a really interesting role and has an interesting background. So background is technical– computer science–has been a founder, which we are definitely going to ask him about, and then has spent a lot of time in both marketing and sort of the data engineering data ops role related to marketing. I cannot wait to ask him about that. One of my big questions for John is going to be, working in data, and being a marketeer creates a really interesting perspective. And I want to know if his work in data has influenced the way that he sort of wields marketing tools as a marketer, because I have a theory that there’s a direct relationship there. That’s my burning question. Kostas?
Eric Dodds 01:18
Yeah, I have a very similar question, to be honest, John has a very interesting background because he studied computer science. He’s a founder and works in marketing. So it’s very interesting to see how this journey has affected the way that he understands and works in marketing. And I think this is going to be a big part of our conversation today.
Eric Dodds 01:40
Absolutely. Well, let’s jump in.
Kostas Pardalis 01:41
Let’s do it.
Eric Dodds 01:43
John, welcome to The Data Stack Show. We’re really excited to talk with you about a lot of things you’ve done, especially your work at Grafana. Since we’re such big fans of Grafana in general.
John Marbach 01:55
Thanks for having me on. Appreciate it. I’m looking forward to chatting today.
Eric Dodds 01:58
Cool. Well, why don’t we start out with just a little bit of your background? You and I chatted a little bit this week, and there’s so many interesting things. But why don’t you just give us a quick background of what you’ve done throughout your career and how you wound up at Grafana, and then what you do at Grafana?
John Marbach 02:14
Yeah, so my background is a little bit of a whirlwind. I studied computer science in school, but always found myself more fascinated by the marketing side of things and being closer to the business simply because marketing is a little bit more creative, while being able to take ideas that you know, we may have on this conversation. And having that freedom to go implement things that actually changed the hearts and minds of your customers seemed to be the thing that appealed to me the most while being rooted in a more technical background. As I found myself in the workplace, I found that there was really a deficit of people who really understood how some of these web products work at a fundamental level. And then also had an interest in wanting to drive marketing experiments and craft compelling messages and, and whatnot. And so that led me into a variety of marketing operations roles, starting at a company named Bitnami, which packaged up open source apps for deployment on the cloud. Then I moved to New York working at Codeacademy for a couple years, mostly on their email marketing, and some website growth experiments. That led to DigitalOcean where I became the owner of the company wide customer data collection and measurement via Segment. And today, I’m at Grafana, where I’m doing a lot of similar customer data collection measurement, but this time via RudderStack, and using that data that we’re collecting to drive ad hoc growth experiments across the acquisition funnel.
Eric Dodds 03:48
So interesting. Okay, so I know Kostas has a ton of questions. He always does. And we have to go back and forth. But I’m interested to know … you’re not the first person we’ve had on the show who has lived in a world that blurs the lines between marketing and really sort of data engineering. And I’m really interested to know how it seems like that those lines got really blurred when you went to DigitalOcean, where you were, you know, sort of serving a bunch of marketing use cases. But you were managing all the pipelines and data. How did that happen? And what was that like for you to sort of live in that interesting, sort of almost in-between type role?
John Marbach 04:34
Yes, good question. I think that the team at DigitalOcean, they recognize that there are a lot of people on the marketing team who understood the tools that they were responsible for very well, such as Marketo, such as Google Ads, and what have you not. And there were also engineers at DigitalOcean, who really understood cloud infrastructure and how to build a web app to make it really reliable and scalable, but there weren’t any people there who had an interest in how the cloud actually works, and then how to connect those applications that DigitalOcean was building to modern marketing tools. And so that’s where that’s where I really filled in having had experience using tools like Segment in the past at Codecademy consumer scale. I was able to say, Hey, DigitalOcean, like, I’ve used some of these really amazing data collection tools in the past to eliminate repetitive tracking and consolidate a tracking plan. And I can bring this to DigitalOcean to make things a little bit more efficient, and reliable.
Eric Dodds 05:41
Super interesting. And do you feel like reflecting on that experience at, you know, Codecademy, and then DigitalOcean? Do you feel like as a data-driven marketer/data engineer, do you feel like working from the data layer has influenced how you use some of those downstream tools. We talk on the show so much with people who are building pipelines, and we talk about moving data around, and it’s an interesting opportunity for us to talk to someone who’s sort of done heavy duty pipeline management, and then also has acted as a consumer of that data. How has that experience influenced the way that you wield sort of those, you know, like marketing, SaaS tools?
John Marbach 06:28
Yeah, I think there’s a spectrum of ways that that type of experience has shaped me.I think, like, for one, like being a responsible steward of customer data and saying, like, Hey, you know, we can’t just be sharing all this customer data. With Slack and other tools, we need to be really considerate about what exactly is going where to reduce our risk exposure. Next, to think about what an efficient data pipeline looks like. Are we tracking the same event in multiple tools? Well, from the engineering world, there’s the concept of having dry programming and dry code. Don’t repeat yourself. So are we doing that on the marketing side? Next, there’s just the idea of operating with an ethos of, are we doing repetitive things today that can be automated, because if we’re doing something that is repetitive, we should automate it. And to give you one example, in the past, it’s very common for marketing teams to upload CSV lists of email addresses that they wanted to match on Facebook ads for retargeting. That’s a very repetitive process that can be mechanized. And our team’s doing that, are they using tools that can help them move more quickly in that way. And so all that to say, it’s sort of like being a data store within the company. And, you know, acting as that interface between engineering and marketing, to say, Hey, what is possible here from the marketing side, and relaying that to the marketers saying, like, Hey, you know, we can get this customer data from this part of the enterprise to this tool for the campaign that you want to run. So it’s really enabling those marketers. It’s also helping the engineers understand what is the impact of the customer data that we are collecting? Because a lot of the times they’re not able, engineers aren’t, they’re just not thinking about this one button change on this one part of the website or UI can lead to a meaningful impact in the company’s revenue or retention.
Eric Dodds 08:24
Super interesting. I love the analogy of dry code and that paradigm being applied to the way that you structure things in downstream tools. Just thinking back on my experience, early in my days as a marketeer, that just all the mistakes I made around even simple things like naming conventions around campaigns, or automations, or custom fields that led to severe problems at scale, because there wasn’t any sort of well thought out taxonomy. And the deeper I’ve gotten into the world of data and sort of data structures and understanding that, I feel the same way. It’s really influenced the way that I sort of approach or think about the way that I do things in the UI of a SaaS tool. So I love that. Really interesting. Alright, Kostas, I’m going to hand it over to you because I’ve been monopolizing, as I usually do, at the beginning of the episodes.
Kostas Pardalis 09:23
It’s fine. It’s fine. So, John, I think you gave us some idea of how your computer science background has affected let’s say, your career in marketing. But can you expound a little bit more on this in terms of how do you think that being trained in computer science has affected the way that you approach and you work in marketing?
John Marbach 09:47
Yeah, I think that’s a interesting question. It’s not easy to understand on the surface, but just to give you some examples. I think like a lot of the times I’m working at companies like Grafana, DigitalOcean, or Codecademy, and there is the question of like, we’re using a tool, for example, maybe a query on a database is executing too slowly. Or we’re receiving a high volume of events for some promotion that we’re launching on the marketing side. I think like, one thing that you learn just within a more engineering driven background is just the concept of scale. And, frankly, DigitalOcean, Codecademy, Bitnami, Grafana, these companies have done well, but they’re not Facebook-level scale. So some of the problems that we’re dealing with, they are bigger than, you know, your average toy web app. But I think being able to, again, be that stored internally saying, like, hey, like, what is the appropriate level of scale and resources and time required to do certain things? That’s where it’s really been the most impactful.
Kostas Pardalis 10:49
Yeah, that’s super interesting. And you have mentioned at the beginning a lot like the word experiment, which I mean, okay. It’s something that we hear a lot when it comes to marketing, especially like B2C marketing where you have, like, the sample sizes where you can run experiments, but that’s, I think, another kind of modality that is brought into marketing from more engineering disciplines and science related disciplines. Can you give us a bit of more information around what you mean about experiments? Like, what is an experiment in the context of marketing? And give us like a couple of examples?
John Marbach 11:28
Yeah, I totally agree with you. First of all, on the experimentation side of things, I think the best growth marketing people I’ve worked with, they’ve just been the people that are constantly acknowledging the reality in front of them as far as what the data is saying, and, and there’s a quote from Jeff Bezos, if the data leads you one way, and the anecdotes don’t match, it’s usually a problem with how you’re measuring things. And so that’s sort of something interesting to keep in mind as well. As far as the growth experiments, I think, going back to the engineering example, again, like on the growth side of things, our interest is always to have the largest impact with the least effort. And that’s because we’re able to do something very little, let’s say, a little task and make a huge impact, like, we would always prefer to be as efficient as possible. And so one thing we did at Codecademy really, really well was actually just change the pricing of the subscription for different users. And we said to ourselves at the time, the subscription is $20 a month for everyone worldwide. But our customers were coming from all over the world. And they were coming from different levels of income and backgrounds. We said, why don’t we just change the price for people inside the US versus outside the US? If you go to McDonald’s in Times Square, the cost of a cheeseburger is much different than you know if you’re in France or London. And that simple change, as far as the technical requirements was very simple. We’re just looking at an IP address and routing a visitor to a different checkout page. But the impact on the business was massive. The revenue from new customers increased by 30% overnight, and the churn actually decreased since we’re finding a better price point for the customers and people who are more price sensitive weren’t signing up at all.
Kostas Pardalis 13:14
Wow, that’s, that’s amazing. And this idea came from marketing, to change the pricing and experiment with pricing?
John Marbach 13:22
Yeah, I would say, you know, I think as in any company, there’s a lot of collaboration between product and marketing and that’s a collaborative effort. But sort of just taking that mindset of like, Hey, you know, our aim is to grow the business here, and what are the really low lift things that we can do that can potentially have a high impact and marketing is certainly involved with understanding the needs and wants of consumers, and product is more responsible for carrying out the change in the whole user experience? So that was a fun experiment.
Kostas Pardalis 13:53
Yeah, that’s, that’s amazing. And I think it’s also an example of like, a good, you know, company culture. I mean, if you ask like a random person, what do you think that marketing is doing? Like, they will describe to you that, okay, marketing is trying to communicate what the business does, right? So that’s a bit different than hearing about how marketing can cooperate, actually, with the rest of the company, like all together, trying to figure out and come up with experiments and change things. Like pricing, it’s something that most people would think that does not come like from marketing. And so that’s great. That’s, I think, an amazing example of like, how culture is important and how it can help accelerate growth of a company. By the way, you said about McDonald’s, I remember, I’m originally from Greece, right, so I remember my first trip in Switzerland, which of course, like, you know, the two countries in terms of GDP and all these things like that are completely different, right. So I went to visit the McDonald’s store and I was extremely surprised at the price difference between how much the Big Mac costs between Athens, Greece and Geneva in Switzerland. It was super interesting.
Kostas Pardalis 15:06
Nice. So you mentioned the term marketing ops. And it’s something that we hear more and more like lately. My understanding for the role of marketing ops, it’s some kind of intersection between a technical role and a marketing role. Can you help us define this role? And what do you think like the history of his role is? Like how was it done in the past, when the term was introduced, and what do you think is the future of marketing operations?
John Marbach 15:35
Yeah, I think in the past, it may have meant something more similar to a database administrator, or someone who is helping coordinate a campaign. As far as just like the different interactions with different vendors, I think today, it really means you’re sort of the owner of what we’ve been talking about today, the data pipeline, and how customer data fits into tools where ultimately that data is acted on. And oftentimes, when a marketer is coming up with a new idea, the idea is coming in place, because it’s something they’ve never done before, the data’s not been available. So I also think the marketing ops person of today and the future is interfacing with other teams, and it’s really sort of like a help desk for the marketing team, for the marketers to say, hey, marketing ops, we’d like to run this campaign, can we do this? If the answer is yes, this is exactly the data you need to use. This is how to query the database or get this new data into a new tool. If no, then it’s, what’s the process for getting that data? Do we need to create a new form on the website? Do we need to collect data in some other indirect way, and it’s facilitating that process and being basically a marketing ally to enable future marketing experiments?
Eric Dodds 16:54
When did you think is the right time for a company to introduce the role of marketing ops inside the marketing organization?
John Marbach 17:02
I think it’s never too early to have the skill. The person dedicated to that, I think, makes sense once there’s a dedicated marketing function, and there’s a dedicated person, or there’s a person focused on driving new ideas and growth from marketing. It’s really like a tag-team effort, I think, between a marketing ops person and someone actually to execute on campaigns.
Eric Dodds 17:29
One follow up question there. We say marketing ops, but one thing that I’ve seen is almost more of a, a sort of utility ops function, that kind of is, like we said, like almost more of like a data engineering function that’s serving multiple teams. I mean, at really large scale, you have ops for, you know, for sort of individual teams, but the type of experimentation we’re talking about can apply to lots of different functions within the company that can think about marketing, but you could just as easily replace that replaced product, or replace the term marketing with product. So do you see that happening? Where you kind of have a, you know, especially in sort of maybe early or mid-sized companies, where there’s someone who serves that function across multiple teams, as opposed to just one specific discipline like marketing? Or you know, you’ll see sales ops, etc?
John Marbach 18:28
Yeah, I think I haven’t seen a good name for it yet. But I think in any org, they’re sort of always the person that people lean on when no one else has the answer. And especially when there’s a technical question, and just that ability to write code, whether it’s writing a script to automate some sort of data collection and ETL process into some tool, or writing SQL query to get the results from some sort of experiment, or, again, extracting data, or actually jumping into the code base, or the marketing site and changing something on the homepage. Just that technical ability I’ve seen, you know, and that insatiable curiosity to learn and want to make a difference, there’s that person in every successful SaaS startup I’ve seen. And they’re constantly wanting to learn and make an impact, and grow the business.
Eric Dodds 19:18
Yeah, that’s, that is really interesting. That’s a great way to describe it as the person who people lean on for sort of very technical tasks, you know, across functions, and they don’t really have a name, because it’s not necessarily formal data engineering, you know, in the sense of, you know, sort of at a super large scale, like enterprise company, data engineer, but yeah, I agree. It’ll be interesting to see if the industry sort of adopts a title for that utility player. That’s really interesting.
Kostas Pardalis 19:51
I have a question actually, for both of you gentlemen, Eric. And I was thinking because you mentioned the term “dry” earlier. Is there such a thing as technical debt when it comes to marketing ops, and the reason I’m asking is, I’ve been through like the process of, for example, trying to migrate from HubSpot to Salesforce, right? Or start introducing a new marketing platform. And some of that’s quite painful. So have you seen that? And the reason I’m asking is because when a company starts, people tend to be very scrappy and it makes sense, right. And one of the areas that we really get scrappy is when it comes to marketing, what kind of effect does that have to the operations as the company grows?
John Marbach 20:35
I’ll take it first. I think yeah, that there’s definitely the concept of marketing, technical debt, I think. I think that’s sort of the consequence of not being equipped with the right tools or tools that are built in like the web era, web-scale era. I think anyone who has worked with Salesforce will encounter the three crazy words, “Salesforce API limits”.
Eric Dodds 21:02
*Laughter* It’s so true.
John Marbach 21:07
Yeah. So I think that right there, you sort of face limits in a lot of other ways, with more antiquated tools. And that holds people back frankly, from developing new ideas and working with customer data and, you know, growing your reach. So anyways, I think that a company can avoid, or be more focused on future oriented infrastructure and eliminating those repetitive processes. I think the less debt you’ll have, and the more allies you have on the engineering side, the more quickly you’ll be able to run.
Eric Dodds 21:39
Yeah, I agree. I think, as I think back on my experience, I’m trying to think of an analogy. It’s almost like when you are building software, and let’s say you roll out a feature, and there’s some sort of issue with it. And you say, you know, we really should sort of go back and think about this feature from the ground up, but we’re just gonna put a patch on it for now. And then you don’t go back and look at it from the ground up. And so that means you sort of do another patch and another patch. And then, at some point, you have this feature that’s really difficult to deal with and work on, and requires a lot of tribal knowledge on the lineage of all the different patches that have been applied. And I’ve seen the same thing happen a lot in the world of marketing. And it’s not because marketers aren’t smart, or aren’t good at using the tools. But there is a pretty different mindset. And I think that’s why like, John, it was so interesting to hear about your background in working with data and how that influenced your use of marketing tools, because if you’ve worked with data, you’re constantly thinking about what problems you might encounter at scale, right? So if you’re thinking about even things like a tracking plan, which will require you to, to build a naming taxonomy and other things like that. You’re trying to think about, okay, if we do this, and then we add a bunch of other tools into the mix, and then those tools need to adjust this end data, and someone wants to change the name like, are we building this taxonomy in a way that is very extensible? And when you’re just working in a single marketing SaaS tool, it’s very easy to adopt the patch mindset, where you’re like, well, we’ve got to get this campaign out the door, we should probably think about this more, but we’re just going to patch it, right, whether that’s adding another custom field or sort of breaking a naming convention, or, you know, whatever, like rolling out a form in a way that’s not standard. And you do that enough times, and it really creates sort of a huge amount of debt long term. And ultimately, that slows the marketing team down, right? It’s way harder to roll stuff out without breaking. You have, you know, the logic around automations becomes very difficult, because you’re like, ooh, you know, we’ve done some weird things. And with some custom fields, like, if we roll this out, are people gonna get it who weren’t supposed to? So I don’t know. That’s kind of been my, my experience of technical debt on the marketing side.
Kostas Pardalis 24:12
That’s super interesting. So John, can you share with us like some examples of let’s say, marketing stacks, like technology stacks that you have seen there and relate them to the scale of the company? Because you mentioned the word scale a few times. And I think it’s very important. And a very common mistake that many people do is they are, you know, trying to attack like a small problem and the tool that they’re using is actually like a whole bazooka that doesn’t make sense for the job. So can you give us an example of like the minimum stacks that you think the company needs for each stage?
John Marbach 24:48
Yeah, I think it’s funny. Sort of every time a new teammate joins one of these SaaS companies that have reached scale, the natural reactions like, Oh my gosh, we have so much data. And then I have to remind them, well, it’s a lot, but it’s not unmanageable. What I’ve seen today, though, for any company that sort of wants to build a scalable self-serve solution needs to have some sort of CDP, customer data platform, in the middle. And when I’m diagramming how our customer data goes from start to finish, it’s sort of the diagram that I would never want to share with a company like Segment or RudderStack. But the honest truth is that Segment or RudderStack, or any alternative is, is at the middle. You have your apps on the left side, such as the website for Grafana. In the middle, you’re, you’re shuttling data into a tool like RudderStack. And then from RudderStack data is going into a variety of other marketing tools and analytics tools such as Google Analytics, Google Tag Manager, Google Optimize, at Grafana here we use Marketo, BigQuery. So, yeah, variety of different tools, whether it’s analytics, or its data warehouse again, or it’s more of like a paid advertising type thing with Google Ads, I would say the minimum though you need to have, you need to have something that automates that repetitive process of shipping data to these other tools. And then separately, you need to have a warehouse where you can actually query the data. So again, the leading solutions are sort of like Redshift, Snowflake, BigQuery. And you need something where you can actually visualize the data. So a BI tool, like Looker, can repurpose Grafana. Something like Amplitude or Mixpanel, also R or Posthoc, or Pendo, sort of fit in that as well. Yeah. And then typically, you know, some sort of automation tool is in the mix there like Customer.io or Marketo.
Kostas Pardalis 26:52
And do you see this start to change from like a size of a company to another? Is it different for a startup compared to a company that, I don’t know, like, has 1,000-plus employees? Or it’s pretty much let’s say, the architecture is the same, but like some components might change, depending on the scale and the type of marketing that the company does?
John Marbach 27:13
Yeah, I think if you’re going for anything more than, you know, white glove service in the thousands of customers, you’re gonna want something that scales. And so fortunately, today, going back to the thought of, you know, being oriented with tools that can scale with you, I think, tools like RudderStack and Segment, they’re good to go through the 1000s of employees. Having worked with people that have come from organizations that are a lot bigger, I think, and then maybe not seeing the growth. I think that’s sort of even a risk where people who are coming from bigger companies don’t necessarily see how the value of these more SaaS cloud based tools can scale from a small startup, really into a big IPO-ready company.
Kostas Pardalis 28:03
That’s interesting. You mentioned that term CDP earlier. And you started describing, like, how, what’s the position of the CDP in this architecture stack. How do you define the CDP as a product? Like what’s the minimum functionality that you think a CDP needs to have? And the reason I’m asking is because there are many different interpretations of what a CDP is. And the whole term is very, very vague. So it would be great to hear from your perspective, what a CDP is, as a product, a product needs to have to define it as a CDP.
John Marbach 28:40
Yeah, sort of think back to when Segment launched years ago. And they didn’t really understand that they had a business in front of them, but they knew they had something valuable. And all they were saying at the time was, hey, we can take your Google Analytics scripts and a couple other front end JavaScript and bundle it together into a Segment script. And so you can go into our UI and toggle on and off a few different things so that you don’t have to bother your engineers to make changes to your website. And so from my perspective, CDP really just helps to automate that repetitive process of either adding new tools to and from your core web apps, and then separately shipping, tracking data to those tools or other tools as well. And an important part of the CDP is to enable non-technical or pseudo-technical marketers to be able to click a button and see results that typically would not happen without the help of an engineering team and a totally new deployment of an app or website.
Kostas Pardalis 29:44
That’s interesting. I have two more questions, and then I’ll give the microphone back to Eric, because he also has like, many questions to ask. My next question is purely about marketing. And actually, I find it very interesting. You have worked like with a couple of companies that you’re actually marketing to, let’s say, developers or engineers? Is there something special when it comes to marketing? to this category of people? Like have you seen some different approaches that marketing needs to have? And how at the end are developers different than any other person out there when it comes to trying to communicate product or brand?
John Marbach 30:25
Yeah, I think that’s another sort of interesting angle with the experience I’ve had. And I would say it’s hard to know exactly what will work with developers. But I think there’s a few myths like one, every company I’ve worked for, the sort of myth internally is that developers don’t want more email. That’s not true. They just don’t want emails that aren’t relevant to them. And so getting the targeting, right, it just sort of proves, you know, what is true throughout marketing with any company. You have to have the right message at the right time. So, for example, at DigitalOcean, one campaign that was really successful that I worked on was looking to see users who had deployed a Postgres database and saying, hey, by the way, like, if you just enable this read replica, your database will be much more scalable, and reliable, if there’s downtime. And that type of message really resonates with a developer, their job is to, you know, provide reliable and efficient solutions. If you’re sort of doing the spray and pray method, that can work, but it’s going to be less effective. And it could be a good way to generate new ideas and generate just sort of a way to get a compass on where to go next. But I think the fundamentals of marketing are true with developers more so than with any other business.
Kostas Pardalis 31:47
Oh, that’s super interesting. Do you think that your background in computer science and engineering can also help you in like, let’s say, figuring out easier or like trying to understand how to target this audience? Do you think it’s important for a marketer to have this background at the end, in order to be successful in marketing to engineers?
John Marbach 32:06
I think it’s helpful, but it’s not required. I think, sort of going back to some of the things that Jeff Bezos has talked about as well, you sort of just have to look at the world and see what the major trends are and make sure they’re at your back, for example. Today, would it be smart for a SaaS company to rely on just Google Analytics? In my opinion, the answer would be no, especially on a developer oriented website, where developers are more likely to disable ads and tracking scripts, especially Google Analytics. Likewise, developers are more likely to be privacy oriented, because they understand how this data is being shipped around. And so marketing messages that appeal to their sensitivity of data are more likely to succeed. So sort of just kind of like being aware of, you know, what, what’s going on in the world and making sure that you’re in touch and driving into that in a productive way, with the wind at your back, not fighting those strengths.
Kostas Pardalis 33:03
Nice, super interesting. So last question for me, I know that you have also been a founder in your life, and you’ve been a founder of a company that went through Y Combinator, do you would like to share your experience as a founder. And so how did it feel to go through Y Combinator, quickly?
John Marbach 33:19
Yeah, I think that’s sort of the ultimate DNA behind me, I think bringing the attitude of being action-oriented and wanting to help customers in any way that’s possible and building a business to capitalize and make the most of any opportunities, sort of the essence of who I am. And the company I built was called Wider did email filtering inside Gmail before that existed that now exists as tabs in the inbox, and it was a great experience. We didn’t get to the scale that is necessary to do a proper acquisition or anything like that. But it has me always thinking sort of my background process. What’s the next opportunity where I’m going to be ready to strike it out on my own and make a big impact? As of now I’m sure you’re following the whole cryptocurrency revolution. So I sort of see that as Internet 2.0. That’s here to stay. I’m sure I’ll be involved with that very shortly.
Kostas Pardalis 34:15
That’s amazing. Nice. Nice. So Eric, the stage is yours.
Eric Dodds 34:21
This has been such a fun call already. I’m thinking about our listeners. And your vantage point, having worked on the data side, and the marketing side, I’m going to keep returning to that on this episode because I think it’s so helpful. What are the problems that you see? I mean, we live in a world where I think the collaboration is getting better and better and just even over the last, you know, six or eight months that we’ve been doing the show, we’ve just heard some really cool stories about the ways that you know, sort of data and engineering are interacting with other teams, and how that used to be such a problematic thing and slow things down. And now it’s actually in some cases, creating competitive advantages. What do you think are the biggest challenges around that that you’ve seen? You know, especially coming from the marketing side? And what are some ways that you’ve found to sort of break the barriers of problems between data and engineering and marketing? Sort of the formal marketing?
John Marbach 35:20
Yeah, it’s a tension that perhaps may always exist, but can be alleviated with following best practices and being understanding and patient from both sides. I actually brought up something earlier, just providing, for example, a tracking plan, starting from really clear requirements on what is it exactly that we need to track? And why do we need to track something? I think, just doing that exercise of writing it out, and you know, writing what events the marketing team is looking to consume, and what exactly are the attributes on those events or understanding of the user state that is such a great exercise in producing clear thinking that, I think should be a requirement for every marketer, or technical marketer. That way, when an engineer’s actually taking on a task, it’s, it’s something that’s been well thought through, and there’s not as much back and forth, as far as you know, why, what is the purpose? And I think secondly, there’s a follow-up component, it’s saying, hey, from the marketing side of things, we use this data, we produce these results, and being just very transparent, for good or for good or for bad. This is how this engineer’s work actually ultimately impacted the company. And that feedback loop I think, is really critical to developing trust and moving more quickly in the future. So yeah, I think it’s sort of just like the fundamentals of working well, together with anyone, you know, being really clear about communicating your purpose, following up once the request has been completed. And then yeah, like I said earlier, just, you know, having some of these trends at your backs so it’s giving you the best odds to succeed.
Eric Dodds 37:01
Yeah, I’m going to reiterate one thing, he said, in large part, because I’ve done a really bad job of it in in the past, and that is, as a marketeer, creating a feedback loop, where you’re sharing results back to engineers who’ve helped you accomplish something that is so powerful, and I think it’s something that I’ve been really bad at, and I think, you know, not to throw every marketer in the spotlight here. But marketing tends to be pretty demanding and want a lot of things just because the tip of the spear of a company in terms of, you know, driving business and traffic and leads and all that. It’s pretty intense, right? And so marketers have to run lots of experiments. And, you know, and they tend to have a lot of technical needs, especially if the marketing team doesn’t have that sort of utility player or marketing ops person who can help create velocity there. And I think that’s just such a valuable thing that just struck a chord with me, because I’ve done such a bad job of that in the past. So great insight there.
Eric Dodds 38:06
We’re getting close to time here. But one other topic that’s interesting that I think would be fun to get your perspective on both from the data pipeline side, and as a marketer, yourself is the new hot term of reverse ETL. So, you know, you have a ton of experience with event streaming. And I know just from our conversations, you’ve done sort of the traditional, like batch ETL, and cloud SaaS, to, you know, to warehouse to sort of do interesting analysis, etc. But reverse ETL isn’t necessarily like, the basic concept of getting data out of the warehouse, and then getting it to another place is not new in itself, but this new sort of crop of functionalities around like automating that, and sort of, you know, making that a SaaS product that’s easily configurable, schedulable, all that sort of stuff, as opposed to having to write something custom is pretty interesting. And there are tons of opinions about that. So what’s your take, having seen both sides of the fence on marketing and data?
John Marbach 39:07
Yeah, it’s definitely a big trend right now, I think, I mean, it sort of just fits the whole idea of like, let’s automate as much as possible if it can be automated, let’s go for it. So I think, you know, there are some legs to the trend. I think it’s sort of the question back in my mind, are the existing tools going to be able to expand and help do this sort of thing anyways? For example, a Segment or RudderStack, we use Hightouch currently at Grafana. So it sort of fills that role a little bit. Yeah, I’m not sure exactly where if the reverse ETL will sort of fit in the center, like a CDP, it’s certainly on the periphery. But it definitely matches that sort of process, which is happening today, which is that all these tools are being stitched together, whether it’s analytics tools back into something like RudderStack or Segment and getting feedback out of Facebook ads, understanding experiment data, getting Customer.io or Marketo or whatever. And the idea here is that all these SaaS tools are out living in the ether, and they would all benefit from communicating more with each other. And currently, we’re using Hightouch to get data out of BigQuery into Slack. And it sounds so simple, you know, building a Slack bot based on BigQuery data. But it is a use case that, you know, increases the information throughput in our Slack. And that’s really valuable to us. So there’s something there. I’m curious to watch it as well.
Eric Dodds 40:36
It’s funny that you mentioned that the sort of getting key notifications into Slack. It’s on face value, like well, that’s pretty trivial. But because Slack is so integrated into the way that companies operate now, we’ve seen that as a major, like, key use case, you know, I mean, it may not be like sort of the core thing, it’s not like you want to build an entire, you know, entire core process for a team around just Slack notifications, right, alone. But it is so interesting, how pervasive and useful that’s become, you know, and then, of course, there’s all the other myriad of use cases for reverse ETL. Yeah, it’ll be really interesting to watch the space. And I think, I think it’s really interesting, I think, you know, that, it certainly opens up a world of opportunity. But I agree with the way that you described it in that it’s really cool. But it just kind of makes sense as part of this set of pipelines that, you know, reduce the need for someone to build something custom or, you know, manage a bunch of different things. So my prediction, which, you know, I’m wrong on many things, is that it will kind of get rolled into the set of pipelines and just kind of the standard of what you use. You have pipes going in, you have pipes going out, you have pipes connecting different things.
John Marbach 41:57
Right, yeah, I see the existing tools becoming easier to integrate. I think the trend that I’m sort of looking at right now is the sort of the observability of these data pipelines now that they are critical and if the data pipeline is broken, that’s causing massive revenue loss to businesses. I think that’s sort of something that is interesting to me, personally. So that’s another thing I’m working on as well.
Eric Dodds 42:21
Yeah, totally. Now, one other thing on reverse ETL, which I don’t know if you’ve seen this, or you deal with this at Grafana much, but one other interesting thing is for, you know, if you think about event stream stuff, we have kind of the clickstream data that represent user events from your website or app. And there are all sorts of use cases in regards to SaaS tools, analytics, etc. But there are some interesting things you can do with reverse ETL around non-customer data that needs to be represented in a certain way in certain downstream tools. So like, one example I was thinking of, that we heard about recently was almost treating an order that’s being shipped in the context of e-commerce as an object, and then sort of describing that, you know, with events, which can be really useful for certain use cases, especially, you know, in this particular case, there were sort of, by use around joining some batch data from carriers. And then, you know, describing an item that’s being shipped with events. And the reverse ETL thing makes it way easier to do interesting things like that, when you sort of have a need, that’s an edge case when it comes to your standard pipeline tools, but incredibly valuable for, you know, a particular business context.
John Marbach 43:33
Totally. 100%. I found myself in the past sort of kind of using tools like RudderStack or Segment in ad hoc ways to accomplish that. So I completely agree with you.
Eric Dodds 43:44
Cool. All right. Last question. And this is related to a passing comment you made … but cryptocurrency blockchain, make a prediction for us on that. I’d love to hear because I have several friends who I talk with about this, but I’d love to know, since you’re into that I’d love to know. Give our listeners a prediction.
John Marbach 44:08
Yeah, this is out of left field but Square came out today with their model for how Bitcoin mining or cryptocurrency mining in particular, is going to fuel or make wind and solar power economically viable. And I think that’s sort of like the really interesting thing to watch for. How does cryptocurrency interplay with the energy industry? That’s where we are today as far as being able to make solar and wind energy which are typically unreliable because the sun doesn’t shine at night. And the wind only blows when the weather’s right. How do we monetize those systems in a way that makes them competitive with coal, nuclear, other natural gas, etc. I think that’s sort of very recent, but I think that’s sort of the future and being able to get energy, right, is something that a lot of people are thinking about. And energy is sort of the start of all industries. So my prediction is, Bitcoin will hit $1,000,000 in six or seven years and the energy industry in particular will embrace it more so than almost anyone else.
Eric Dodds 45:20
Fascinating. If you’re driving and listening to the show, do not Google while driving, that’s unsafe, because I know I’m actively Googling things right now about several things he just said. Very cool, John, we may need to have another episode where you’re talking just about that. But this has been great. I’ve learned a ton. And I think you’ve just brought some really insightful thoughts for our listener. So really, really appreciate you giving us the time to jump on the show.
John Marbach 45:44
Yeah, thanks for the opportunity. I enjoyed it.
Eric Dodds 45:48
What a great conversation. I may be biased because I was once a marketeer. But it’s always fun to talk with people who have sort of played, you know, multiple roles in data and other teams. I think one of my favorite takeaways was his description of working in marketing, and leveraging the paradigm of dry code. I just really loved that. Because I think that’s a big problem that I’ve seen. I’ve made mistakes around that. And I think that’s a really, really good best practice from the data and engineering side of things that marketers would do really well to adopt. How about you Kostas?
Kostas Pardalis 46:25
Yeah, absolutely, I think dry is a principle that can pretty much affect everything that we’re doing in our life. And it’s not just for engineering, and, of course, not just for marketing. But yeah, I mean, as we said, before, the conversation with John, a big part of the conversation with him would be around how his background is affecting the way he’s doing marketing. And I think we’ve learned a lot about that from him. It was a super interesting conversation, I mean, outside of learning about Bitcoin and getting some really good tips there. I think that hearing from him, like how marketing operations and the technology behind marketing can be distilled into a very specific architecture and stock. It’s very important. And so that’s regardless of the scale at the end, that’s something that I keep from our conversation with him. Of course, it’s very important to choose the right tools that can scale together with you. That’s another thing that he said. And I think that at some point that it’s going to be more and more important. And that’s observability. And when we are talking about observability, we are more interested at the end, like observability is needed, because all the infrastructure that we’re building becomes more and more important. And we are at the stage right now where we really need to make sure that whatever we do works correctly. And if something goes wrong, we know that it goes wrong at the right time, and we know how to tackle the problem. So that’s what I keep from our conversation with him. He’s obviously a person with like, very rich experience, and I’m looking forward to talking with him in the future.
Eric Dodds 48:06
I know I have this hope that one day we’re going to get an email from someone who said I was listening to The Data Stack Show. I got a second mortgage on my house to go and buy some Bitcoin. And now I’m retired. That is not financial advice for our listeners. We do not give financial advice, but I hope that we get that email one day because that would make me very happy. Thanks again for joining the show. Make sure to subscribe on your favorite podcast network so you can get notified of new episodes every week. We have a handful of really great shows coming up with people from other awesome companies like Grafana. And until next time, we’ll catch you later. The Data Stack Show is brought to you by RudderStack, the complete customer data pipeline solution. Learn more RudderStack.com.
Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.
To keep up to date with our future episodes, subscribe to our podcast on Apple, Spotify, Google, or the player of your choice.
Get a monthly newsletter from The Data Stack Show team with a TL;DR of the previous month’s shows, a sneak peak at upcoming episodes, and curated links from Eric, John, & show guests. Follow on our Substack below.