The Data Stack Show - 34: The Intersection of Data Engineering and Marketing with John Marbachm of Grafana Labs

Episode Date: April 28, 2021

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:Grafana Labs John Marbach Senior Growth ManagerIntroduction to John Marbach and working in the blurred lines between marketing and data engineering (2:14)How managing pipeline building and consuming data influences the use of downstream tools (6:28)Experiments in marketing (11:28)Exploring the role of marketing ops (15:35)How accruing technical debt can grind things to a halt (20:35)Matching the stack with the company's scale (24:48)CDPs and marketing to developers (28:40)Biggest challenges and barriers between data engineering and marketing (35:19)Takes on reverse ETL (39:07)Thoughts on cryptocurrency and the blockchain (44:08)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.

The Data Stack Show is brought to you by Rudderstack, the complete customer data pipeline solution. Thanks for joining the show today. 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. Costas and I called Grafana. I know that a lot of our listeners are familiar with Grafana. It's a greatly loved tool. Costas 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. Cannot wait to ask him about that. One of my big questions for John is going to be, you know, 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. Costas?

Yeah, I have a very similar question, to be honest. John has a very interesting background because he comes from, 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. Absolutely. Well, let's jump in. Let's do it. John, welcome to the DataSec show. We're really excited to talk with you about really a lot of things you've done, but especially your work at Grafana since we're such big fans of Grafana in general.

Yeah, thanks for having me on. I appreciate it. I'm looking forward to chatting today. 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. 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 we may have on this conversation and having that freedom to go implement things

that actually change the hearts and minds of your customers. That 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 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 Codecademy for a couple of 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 the similar customer data collection measurement, but this time via RudderStack. And I'm using that data that we're collecting to drive ad hoc growth experiments across the acquisition funnel. So interesting.

Okay, so I know Costas has a ton of questions. He always does, and we have to go back and forth. 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 that, it seems like that those lines got really blurred at 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? Yeah, that's a 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 digital ocean 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 code academy consumer scale i was able to say digital ocean, like I've used some of these really amazing data collection tools in the past to,

to eliminate repetitive tracking and consolidate a tracking plan. And I can bring this to digital ocean to make things a little bit more efficient and reliable. Super interesting. And do you feel like reflecting on that experience that, know codecademy and then and then digital ocean do you feel like as a data-driven marketer slash you know 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 those marketing SaaS tools? Yeah, I think there's a spectrum of ways that that type of experience has shaped me. I think, for one, being a responsible steward of customer data and saying, hey, we can't just be sharing all this customer data over 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 does an efficient data pipeline look like? Are we tracking the same event in multiple tools? Well, from the engineering world, there's the concept of having dry programming, dry code. Don't repeat yourself. So are we doing that on the marketing side? Next, there's just the idea and 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 was 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 could be mechanized and our team's doing that or being a data storage within the company and acting as that interface between engineering and marketing to say, hey, what is possible here from the marketing side? And really that's the marketer saying, hey, we can get this customer data from this part of the enterprise into this tool for the campaign that you want to run. So it's really enabling those marketers. And 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, they're just not thinking that 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. Super interesting. I love the analogy of dry code

and that paradigm being applied to the way that you structure things in downstream tools. I think just thinking back on my experience early in my days as a marketeer, 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. All right, Costas, I'm going to hand it over to you because I've been monopolizing as I usually do at the beginning of the episodes.

It's fine. 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 expand a little bit more on this in terms of how do you think that being trained into computer science has affected the way that you approach and your work in marketing? Yeah, I think that's an interesting question. It's not easy to understand on the surface, but just to give you some examples, I think a lot of the times I'm working at companies like Grafana, DigitalOcean, or Codecademy,

and there is the question of we're using a tool, for example, and something, 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. 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 your average toy web app. But I think being able to, again, be that steward internally saying like, hey, 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 yeah that's super interesting and you have mentioned at the beginning a lot like the the word experiment which i mean okay it's something that we hear a lot when it comes to marketing especially like to b2c marketing where you have

like the sample sizes there where you can run experiments. But that's, I think, another, I'd say that like 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 do you mean about experiments? Like what is an experiment in the context of marketing? And give us like a couple of examples. 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 there's a quote from Jeff Bezos on, if the data leads you one way and the anecdotes don't match, it's usually a problem with how you're measuring things. So that's sort of something interesting to keep in mind as well. As far as the growth experiments, I think, you know, going even back to the engineering example again, like on the growth side of things, our interest is always to do to have the largest impact with the least effort. And that that's because we're able to do something very little, let's say a little task and make a huge impact.

Like we, we would always prefer to be as efficient as possible. And so one thing we did at Code Academy really, really well was actually just change the pricing, the subscription for different users. And we, 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 background. 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 if you're in France or London. And that simple change, as far as the technical requirements, was very simple. You'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 were finding a better price point for the customers.

And people who are more price sensitive weren't signing up at all. Wow, that's amazing. And this idea came from marketing to change the pricing and experiment with pricing? Yeah, I would say, you know, I think as in any company, there's a lot of collaboration between product and marketing. I think 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 that was a fun experiment 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 that, okay, like pricing is something that most people would think that does not come from marketing. And so that's okay like pricing it's something that like most people would think that does not come like from from marketing and so that's great that's uh i think the an amazing example of like how culture

is important and how can help uh accelerate like the growth of a company but 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 are completely different. So I went to visit the McDonald's store and I was extremely surprised on the price difference between how much a Big Mac costs between Athens, Greece and Geneva in Switzerland. It was super interesting. 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 like intersection between a technical role and the marketing role. Can you help us define this role? And what do you think like the history of this role is like? How it was done in the past when the term was introduced? And what do you think is the future of marketing operations? 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 gets 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 into place because it's something they've never done before. The data has not been available. So I also think the marketing ops person of today and 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 how this is 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 okay. 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. When do you think is the right time for a company to introduce the role of marketing ops inside the marketing organization? 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, 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 executing on campaigns. of a utility ops function that is like we said, almost more of a data engineering function that's serving multiple teams. At really large scale, you have ops for individual teams, but the type of

experimentation we're talking about can apply to lots of different functions within the company, right? So you think about marketing, but you could just as easily replace that, replace product or replace the term marketing with product. So do you see that happening where you kind of have, you know, especially as sort of maybe earlier midsize 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. 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 a 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

in that insatiable curiosity to learn and want to make a difference that there's that person in every successful SaaS startup I've seen, and they're constantly wanting to learn, make an impact and grow the business. 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 is, it'll be interesting to see if the industry sort of adopts a title for that utility player. That's really interesting. I have a question actually

for both of you, John and Eric. And I was thinking, because you mentioned the term dry earlier, is there such 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 like a new marketing platform and some of it's quite painful. So have you seen that? And the reason I'm asking is because when a company starts like people tend to be very scrappy and make sense right and one of the areas that we really get scrappy is when it comes to marketing what kind of effect it has that to the operations as the company grows i'll take it first i think

yeah there's definitely the concept of uh 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 sort of the web era, web scale era. I think anyone who has worked with Salesforce will encounter the two crazy words, Salesforce or three words, Salesforce API limits. And it's so true. Salesforce API limits. Sorry, it's so true. 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 growing your reach. So anyways, I think that a company can avoid or be more focused on future-oriented infrastructure and eliminating those repetitive process. 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. 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 going to 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 and working with data and how that influenced your use of marketing tools. Because if you've worked with data, you're constantly thinking about problems you might encounter at scale. So if you're thinking about even things like a tracking plan, which will require you 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 ingest the same 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 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 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 it 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 going to get it? We weren't supposed to. So I don't know. That's kind of been my, my experience, technical debt on the marketing side. 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 like the word scale a few times, and I think it's scale of the company because you mentioned like the word

scale a few times and I think it's very important and with something like 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 are using is actually like a whole bazooka that doesn't make sense for the job so can you give us like an example of like the minimum stacks that you think the company needs for each state? Yeah, I think it's funny, sort of every time a new teammate joins one of these more, these SaaS companies that reach scale, the natural reaction is like, oh my gosh, we have so much data.

And then kind of have to remind them, well, it's, you know, 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 that's sort of 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 at the middle. You have your apps on the left side,

such as the website for Grafana. In the middle, you're shuttling data into a tool like Rudderstack. And then from Rudder stack 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 big query. So you have a variety of different tools, whether it's analytics or it's the data warehouse again, or it's more of like a paid advertising type thing with Google ads. I would say the minimum though is 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, you can repurpose Grafana. Something like, even like Amplitude or Mixpanel also, or PostHog 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. 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 it's, I don't know, like has a thousand plus employees? Or it's pretty much, let's say, the architecture is the same, but some components might change depending on the scale and the type of marketing that the company does.

Yeah, I think if you're going for anything more than a white glove service and hundreds of customers, you're going to want, let's say, if you're wanting thousands of customers, you're going to want something that scales. And so fortunately today, going back to the thought on, you know, being oriented with tools that can scale with you, I think, yeah, tools like Rudderstack and Segment, they're good to go through the thousands of employees. Having worked with people who have come from organizations that are a lot bigger, I think, and maybe not seen 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 to into a big IPO ready company. That's interesting. You mentioned the term CDP earlier and you started describing like how, what's the position of the CDP in this architecture or 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 and what it needs to have to define it as a CDP. Yeah, I 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 that, hey, we can take your Google Analytics scripts and a couple other front-end JavaScripts 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 with the help of an engineering team and a totally new deployment of an app or a website. 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, is there like some different approach that marketing needs to have? And how are, at the end, developers different than any other person out there when it comes to trying to communicate a product or a brand? Yeah, I think that's, yeah, another sort of interesting angle of 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. 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 what is true through 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 a sort of way to get a compass on where to go next. But I think the fundamentals of marketing are true with developers more so than any other business.

Oh, that's super interesting. Did you think that your background in computer science and engineering has also helped you in, let's say, figuring out easier, trying to understand how to target this audience? Do you think it's important for a marketeer to have this background at the end in order to be successful in marketing to engineers? 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's going on in the world and making sure that you're in touch and driving into that in a productive way, you know, with the wind at your back, not fighting those trends. Nice, super interesting. So last question from 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 want to share your experience as a founder and how it felt to go through Y Combinator quickly? 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 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 Glider. It did email filtering inside Gmail before that existed in 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, you know, internet 2.0. That's here. I'm sure I'll be involved with that very shortly. That's amazing. Nice, nice. So, Eric, the stage is yours.

Yeah, 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 just 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. I'm just thinking even over the last six or eight months that we've been doing the show, we've just heard some really cool stories about the ways that 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, you know, data and engineering and marketing sort of the formal marketing? I think this, yeah, it's a tension that perhaps may always exist, but it can be alleviated with following best practices and being understanding and patient from both sides. I think 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 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 it should be a requirement for every marketer or technical marketer. That way, when an engineer is actually taking on a task, it's something that's been well thought through and there's not as much back and forth as far as 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 bad, this is how this engineer's work actually ultimately impacted the company. 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 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 having some of these

trends at your back. So it's giving you the best odds to succeed. Yeah, I'm going to reiterate one thing you said in large part because I've done a really bad job of it 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, not to, you know, throw, 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, 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 sort of that utility player or marketing ops person who can help create velocity there. And I think that's just such a valuable thing that, I don't know, that just struck a chord with me because I've done such a bad job of that in the past. So great insight there. 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, you know, like batch ETL and cloud SaaS to, you know, to warehouse to sort of do interesting analysis, et cetera. 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 it. So what's your take having seen both sides of the fence on marketing and data? 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 that was like, are the existing tools going to be able to expand and help do this sort of thing anyways? You know, for example, a segment or a rudder stack, we use high touch 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, 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 tool back into something like Redderstamp or Segment, getting feedback out of Facebook ads, understanding experiment data, getting customer IO or Keto, or Raise, or whatever. 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, yeah, we're using high touch 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. It's funny that you mentioned that the sort of getting like key notifications into Slack, it's on face value. You're 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, but 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 and 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, many things, is that it will kind of get rolled into the set of pipelines that just are kind of the standard of what you use, right? You have pipes going in, you have pipes going out, you have pipes connecting different things. 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're critical and the data pipeline is broken. It'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 looking at as well. Yeah, totally. Now, one other thing on reverse CL, 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, if you think about event stream stuff,

you have kind of the click stream data that represent user events from your website or app. And there are all sorts of use cases for downstream SaaS tools, analytics, et cetera. 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 with events, which can be really useful for certain use cases, especially in this particular case, there was sort of a use around joining some batch data from carriers and then 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 a particular business context.

Totally, 100%. I found myself in the past sort of kind of using tools like RutterStack or Segment in ad hoc ways to accomplish that. So I completely agree with you. Cool. All right. Last question. And this is related to a passing comment you made, but it's a cryptocurrency blockchain. Tell us, make a prediction for us on that. I'd love to hear because I have several friends

who I talk about this with, but I'd love to know since you're into that, I'd love to know, give us a, to know, give our listeners a prediction. Yeah, this is out of left field, but Square and Invest, they 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 is right. How do we monetize those systems in a way that makes them competitive with coal, nuclear, other natural gas, et cetera? I think that's very, very recent, but I think that's sort of the future. I think 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 a million dollars

in six or seven years. And the energy industry in particular will embrace it more so than almost anyone else. 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 you just said.

Very cool, John. We may need to have another episode where we talk 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 listeners. So really, really appreciate you giving us the time to jump on the show. Yeah, thanks for the opportunity. I've enjoyed it. 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 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? Yeah, absolutely. I think dry is a principle that can pretty much affect

everything that we do in our life. And it's not just for engineering. And of course, it's not just for marketing. But yeah, I mean, as we said before the conversation with John, 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 like a very specific architecture and stack, 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 these infrastructure that we're building becomes more and more important. And we are at a 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 on 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 chat again with him in the future. 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 at Rudderstack.com.