Philippe Gamache  0:07  
Music. What's up, guys, welcome to the humans of martech podcast. His name is John Taylor. My name is Phil Gamache. Our mission is to future proof the humans behind the tech so you can have a successful and happy career in marketing.

Philippe Gamache  0:25  
What's up, folks? We've got a fun episode today. If you're a regular listener, you've heard me mention an article that's been living rent free in my head for a while now. Casey winters, the former CPO at Eventbrite and an instructor at reforge, wrote an article titled The problems with martech and why martech is actually for engineers. I've asked a lot of recent guests what their thoughts were on some of the arguments raised in the article. So today we're going to respond to his claims. I

Vish Gupta  0:56  
don't think martech is the sexiest thing for an engineer to do. Maybe that will change.

Sara McNamara  1:00  
I have a lot of skepticism around the idea that marketing operation teams are just going to become a bunch of engineers if you

Jacqueline Freedman  1:08  
want to build when it's already been built by another company whose sole focus is that first Why are you trying to reinvent the wheel?

Debbie Mayen  1:15  
It's also a signal from a company that says we're not going to do anything according to industry best practices. And I think

Natalie Miles  1:24  
most marketers have some form of PTSD, from having to make some in house homebrew solution work, right?

Ashleigh Johnson  1:29  
A marketer can be technical. An engineer can't necessarily be strategic. I

Josh Hill  1:36  
don't think martech is designed for engineering. I think it's still designed with really marketers in mind, but

Stephen Stouffer  1:42  
I think the engineering role is being decentralized.

Philippe Gamache  1:48  
This episode is brought to you by our friends at NAC launching an email or landing page in your marketing automation platform. Shouldn't feel like assembling an airplane mid flight with no instructions, but too often, that's exactly how it feels. Knack is like an instruction set for campaign creation, for establishing brand guardrails and streamlining your approval process to nack's no code drag and drop editor to help you build emails and landing pages. No more having to stop midway through your campaign to fix something simple. Knack lets you work with your entire team in real time and stops you having to fix things mid flight. Check them out@nac.com that's K, N, A, K, and tell them we sent you. This episode was brought to you by our friends at customer IO, oversold on a legacy marketing automation platform that is still struggling to update its user interface. I've done a tour of duty with all the major marketing automation platforms, and many are definitely similar, but customer IO is the most intuitive and beautiful platform. I'm talking about the industry's top visual workflow builder to design and implement your unique messaging strategy, powerful AB testing features inside your workflows, not just on subject line sends, hold out testing functionality to see the incremental impact to your messages queue draft mode, so you can QA messages and conditions in production with real users before anything is sent. Copy workflow items, so you don't have to repeat the building process again, and monitor campaigns tests and keyless membership growth from your personalized dashboard. The icing on the cake, marketers using customer IO, have seen a 20% increase in conversion rates from strategic messaging. So stop using clunky, old tools and adopt a multi channel approach that creates joyful interactions with your customers. Start a free trial without a credit card@customer.ao and tell them we sent you. 

Philippe Gamache  3:35  
So the article we're debating in this episode was written in 2019 that's five years ago, and five years is a bullet of time in martech, so we can't fault him too much, and I actually respect his bold claims, but he starts off by stating that I hate martech, and think martech will decline as a category, and most martech businesses will not be very successful. Now we could spend a whole episode disproving this prediction, but obviously we've got five years of hindsight, but it's worth mentioning that he did make this prediction in 2019 when the martech landscape exploded past 7000 tools. People to claim that it will decline as a category, given the meteoric rise of tools from only 350 in 2012 and actually flash forward to this year, Scott Brinker released the state of martech in 2024 and his team says that they've seen the largest number of new apps added to the landscape in the last 13 years that they've been curating it. So today, we've crossed 13,000 martech tools, nearly doubling the landscape from 2019 When Casey made his bold prediction that martech will decline as a category. Number of tools isn't the only way to evaluate whether martech has declined or not. I'm not a big fan of Gartner reports, but if that's your more trusted source, they reported that in 2023 client organizations spent over a quarter of their marketing budgets on technology in terms of VC investments, fluma reported a steady rise in martech acquisitions in. Two, three of 2023. Averaging like 40 per quarter. So a bunch of capital inflows in new martech ventures. Clearly, this financial backing kind of highlights the confidence in the industry's future. Okay, so Casey was wrong about martech declining as a category, but he did have some interesting arguments about why his main thesis is that martech faces decline due to in house engineers who are increasingly handling tailored solutions in house and the success of vendors hinges primarily on serving those engineers, not marketers. I've asked eight reasoned guests on the podcast to read Casey's article and share their thoughts. What's your take on this? Is martech, actually, for engineers.

Vish Gupta  5:45  
Um, I think it's, it's a nuanced answer I'll give you. So I think it's really an off putting statement for me, when a company tells me, Oh, we built our CRM in house, right?

Philippe Gamache  5:57  
That's Vish Gupta, marketing operations manager at Databricks.

Vish Gupta  6:00  
But that's I'm not an engineer, right? So to me, I'm like, uh, my value is that I know these popular systems like Marketo and HubSpot. So I think when it comes to, like, finding the right talent, I would have a lot of questions, like, I'm My parents are both engineers, like we talked about. I don't think Martex is the sexiest thing for an engineer to do. Maybe that will change. But I also, you know, I had our head of operations here, not marketing operations, that head of operations asked me, it is what we're building here, world class. And I think when you talk about world class, that's where it gets interesting with engineering, right? Because an engineer can look across the stems, not just your maritech stack, but where is your customer data living? Where is your product data living? And I think that's where I'm personally running into challenges with the systems that are, you know, the big vendors, like, how do you bring all of that in app data in? How do you have that customer data in and in a compliance way? And should that even sit with just the marketing department, or is this like now becoming an operational project, right? So I think you can do some really interesting things when you go there. I don't think martech will ever be just for engineering. I also think it depends how you approach your martech team. I think the value of a martech person is less so about the tools and systems. Some people might really disagree with me here, so I'll prepare for that. But I think the value is being able to see like this is what the marketer wants to do. Here is how we can enable them to get there and measure and make sure that they're doing the right things right to be able to have that holistic system view is really the value there. And I don't know that until this function is much further built out that an engineer is going to be for you.

Philippe Gamache  7:37  
Yeah, what do you what do you think it is that like martech might not be quote, unquote, for for some of some engineers like, Why? Why is the idea of like building a product that's being used by users more appealing than building an internal product that's used by users who grow revenue for the company? Yeah.

Vish Gupta  7:59  
I think when it comes to maritech engineering, I think it's a bit of a thankless job. And I'm sure like as ops people or analytics people, you might have experienced that, right? You build something if it works well, they're happy. If it doesn't work well, they're really unhappy. But even if they're happy, they're not going to scream from the rooftops. You're not going to get people work for a maritech company, and you're helping them build out tools right now that you generate so many more customers, that's something you're going to get credit for, right? And you're going to be proud of. But I think that thanklessness of it, and the amount of engineering work that's available to engineers that is rewarding, right, is going to be always a bigger draw to me than something I think, that's being in house and creating these tools that people will use.

Philippe Gamache  8:42  
So right away, we've got two themes from fish, marketers don't find homegrown tools that appealing at all, and engineers, even less, don't find martech part of the reason why many believe martech isn't appealing for engineers isn't just that they would rather be working on the actual product, but that the chaos of marketing isn't for the faint of heart.

Sara McNamara  9:03  
Well, first of all, thank you for sharing that article that was like fascinating to read.

Philippe Gamache  9:09  
That's the legendary Sarah McNamara, former senior manager marketing operations at Salesforce. This

Sara McNamara  9:15  
one is a tricky one, in the sense that with that state, like I I see the trend. I see the trend of engineering becoming more involved and creating more custom solutions. That being said, I have a lot of skepticism around the idea that marketing operation teams are just going to become a bunch of engineers for a few reasons. And I mean, I could be proven wrong if some of like, the cultural things change surrounding this. But first of all, like a lot of the engineers I've worked with cannot stand the chaos of marketing like they you're gonna always need some kind of middle person, at least, who knows marketing kind of like, be that translator between what, like, the chaos of what marketer. Think they want, or what they think they need, versus what needs to be built. Like they typically don't. They just want to, like, get the information right and then build and then not necessarily be involved in all of like, what about this? What about that? What about this? Oh, change our mind again. What about this, which I feel like is at a fever pitch in marketing just because of the nature of the job, is just reacting to a lot of different things in the market. Um, I also, just in my experience working with companies that have their own homegrown solutions. It's, it's not very scalable. It is hard to recruit talent to manage it, and then also engineers are super expensive. Um, so like all those things together I see as per, potential roadblocks. It's interesting because a lot of the larger companies have their own homegrown things, like a homegrown CRN, like you wouldn't believe they have a lot of just custom stuff, but then they'll tell me time and time again, they're like, Well, how do I recruit marketing ops people, because no one wants to take this job, because it's not transferable, right? It's like our own little thing that's very eccentric, and it's just it's hard to people. And then engineers, like I said, I just, I find that challenge of they'll at least need someone to be that kind of like that layer between marketers and engineers, but I do agree with the overall sentiment that a lot like marketing operations is becoming a lot more complex, and there are many more custom solutions, like even my team, we work with engineers all the Time.

Jon Taylor  11:40  
Yeah, yeah. Maybe it's a follow up. Like, and this is just a trend I've noticed in my own career. Like, over the last 1015, years, more and more engineers and software developers work side by side with marketing and much more closely, sometimes even hired into the marketing department. But you kind of touched on something that I'm curious if you've noticed as a trend, many software developers and engineers who come into marketing often do it as a tour of duty, to go on to this, the product team, or something like that. So yeah, it's actually really hard, in my experience, at least, and maybe yours, too, to find an engineer who wants to live with marketing long term. And that's what marketers need, people who understand these systems like the back of their hands.

Sara McNamara  12:17  
That's what I'm saying. It's it. It's tolerated, not love my experience. I mean, I even say, I even say, for marketing operations, like, it takes a special kind of crazy, right? Like, to want to work with marketing. And I say that was so much love for marketers. Like, I hope growing takes up the wrong way, but it's just like, it's just such a chaotic, it's not as organized as other environments. Yeah,

Philippe Gamache  12:39  
definitely. I came from the startup world for like, six or seven years, and like marketing operations and like demand, Jan and SEO, like they're they're all part of the same hat, like tiny team of like three or four marketers. But when I joined wordpress.com 7000 person company at Automattic, I, like, was quickly in awe by, like, just the size of the marketing team. We were, like, 300 plus people, and there was a 40 person dedicated martech team, and most of the people on the martech team were all engineers. Like the back end technical SEO team was all engineers. We had a ton of, like, homegrown martech stuff. Like, we had our own internal CDP solution. We had our own internal ESP and I totally resonate with what you said. Like, the folks there want to build, and they're excited about building, but first of all, they've never used ESPs or marketing automation platforms or like, CDP, so, like, they don't have that use case angle of, like, why are we building this? Like, what is the path to something usable for folks? And so, yeah, like, it just like, it didn't feel like a natural fit to me. And much prefer working now today I, like my startup, I have, like, a data team that you know, works super closely with me on building a composable CEP and, you know, I get to, like, play the role of what are the use cases that we're trying to build. Like this is why I need real time data so that it can power this personalized experiment or this campaign. So I feel like that works a bit better than having an in house team of engineers doing martech knowing that, like, you know, they're kind of mostly all allergic to marketing in the first place, and then they're not feeling super fulfilled like working on martech, when they could be part of the product team,

Sara McNamara  14:33  
when the product team tends to get a lot more love and funding too, right? Like, like, that's another issue that marketing faces is budget wise. It can be a challenge. So I think they like typically aren't going to get paid as much either. So unless that perception changes, I think that could be another central challenge.

Philippe Gamache  14:50  
So Sarah agrees that there's a trend of engineers entering marketing operations. There's no denying that, but she doesn't agree with this idea of a full transformation. Based on a bunch of different challenges. Notably, most engineers dislike marketing's chaos. You're always going to need this translator between engineer and marketers and also homegrown solutions are really hard to manage and recruit marketers for, essentially making them really costly. Sarah and Vish aren't the only guests that had things to say about martech not being appealing for engineers, and also how homegrown tools aren't attractive for marketing either. Another important question in the build versus buy debate is how you want to spend engineering resources just because you have the ENG resources to build internal martech doesn't mean you have to. For example, should a FinTech or a health tech company really be spending edge resources on marketing technology? Probably not.

Jacqueline Freedman  15:49  
This is a topic I adore talking about, because I love to challenge the narrative internally at company, much to many of my beloved engineers. Chagrin, that's

Philippe Gamache  16:00  
Jacqueline Friedman, CEO and founder at Monarch advisory partners and former marketing ops leader at Grammarly and WeWork.

Jacqueline Freedman  16:09  
If you want to build when it's already been built by another company whose sole focus is at first, why are you trying to reinvent the wheel? Unless your purpose is trying to reinvent the wheel. Then, of course, by all means, do it. But if someone's already doing it and dedicated to it, that answered your question exactly. I have a great example. I won't name name, but it was a, it was a big company I worked at decided, you know, we could do this better. We could build our own internal CRM. We don't need Salesforce, no such thing. And so they hired a few consultants who were specifically dedicated to hire to prove that they're engineered, were capable of filtering them out. Not only did those consultants prove this was not a worthwhile investment, and a company ultimately hired those consultants as full time w2 employees to manage architect, run and build the team to manage our Salesforce instance. And for me, that was a perfect example of showing it's already built by the best in the business, until there's something new. And I'm really excited to see what else is out there. If there's some a new competitor, hit me up. I want to see it, but it is a great example of, don't build something that already exists, and they do it really, really well. But that is often to say, if you're seeking to build something and it's not only going to become part of the company's core functionality, core tech, and you're gonna have a dedicated team supporting, maintaining and productizing it, and you did a cost analysis and all clear, do it? Build the tool. Build the proprietary, proprietary tool. I'm all for it. However, there's something to think about in terms of the longevity for career pathing. Right with custom built tool, particularly homegrown, EFTS. Every team regrets it. They are pleading their case day in day out to instead purchase the next generation platform support, not only their team needs, but the entire company's needs, and regular old personalization effort not taking a week to get a lift, you name it, and think of it from a career extractors and training perspective and standpoint, you can become an expert in the prioritary Cool, and that is great. However, the transferable guilt of that like not always the most easily explained and role is not irrelevant, but it's not a big name. It's not a top tier brand. And it's just something to think about in terms of transferable hard skills, of how you want to set up your team for success, and the way you frame it. Yeah,

Philippe Gamache  18:51  
it's a great probably a little long winded. No, no, that's super good point. I gave me a bit of PTSD listening to your answer because, oh, I joined, I joined wordpress.com like, knowing that, like, this was going to be part of the role, like, I kind of found it interesting that I was going to get to wear this product manager hat and build out, or at least figure out, what is a roadmap to building out an internal, ESP at a massive company like WordPress, and I

Jacqueline Freedman  19:20  
should talk after this. Yeah, more for sure. I assumed that

Philippe Gamache  19:25  
it was going to be a big team of engineers, like, supporting it, right? And at first it really wasn't. And we did get approval to, like, build out the team and get more folks, but after a while, like, I just didn't enjoy it. I, like, I realized that I was also, like, doing two roles at the same time, like trying to figure out how to build stuff in that tool, and like, increase the onboarding rates and like launch emails while, like, building out a roadmap to improve the UI of the tool. So maybe that was part of it. But like, as a marketer working on that, like internal build, I also, like, got my. Yourself into the shoes of some of the engineers who their counterparts and their peers were building the WordPress platform, and they were building internal tools for marketers. And there's just a different level of celebration when it comes to like, launching new stuff. And so I feel like there is and other guests have, like, mentioned this too. Like, there's this commonality that martech just isn't interesting for engineers to work on. And a lot of folks see it as this, like, tour of duty. Like, maybe they'll do it for a little bit, but it's like to stepping stone to do something else. So if you're going all in on this vision of, like, building internally, and you're dedicated engineers to it. How are you going to, like, figure out how to hire more folks, because there is going to be turnover on that team. Like most good quality engineers don't wake up one day and say, like, I want to build internal tooling for marketers. That's not usually the case. Do you agree? What are your thoughts there?

Jacqueline Freedman  20:58  
I definitely agree, unless and find the amazing engineer who are dedicated to it, and they are through unicorns. I have come across a few, and I'm grateful to them, and honestly, they're the reason why I've been able to uplevel my technical guilt, that because they talk to me like I'm in kindergarten, and I've literally learned the fundamental, yes, I'm in full agreement that even if you follow the team, you have to be prepared for churn and turnover, unless you're hiring very specifically, but at the same time, you have to remember every EFP, most ESPs out there is more accurate. They're the UI and UX of what exists as a core infrastructure of defendant domain. And if you're not focused on UAC and UI in addition to core functionality and feature, why are you building this? Yeah,

Philippe Gamache  21:49  
tons of awesome arguments from Jacqueline there. My favorite, the only time it makes sense to do a big internal martech build is if it becomes core to the company's product offering or functionality, and you're going to have dedicated support as well as a user interface for end users. But if you do go down this route, prepare that you might actually struggle to attract marketers as proprietary tools aren't necessarily seen as transferable skills. This episode is brought to you by our friends at revenue hero. I can't think of anything worse than finding out a lead waited a week for a response from sales. That's why we recommend revenue hero. It's the easiest way to qualify leads based on Form Values or enrich data and route them to the right sales rep. Their product is packed with a bunch of behind the scenes superpowers that ensures qualified leads are assigned to the right reps, following your custom round robin rules and sending key data back to your CRM. That means more qualified meetings for your reps. We all know they want more of those, but more importantly, no more waiting time for your potential customers. They back all of this up with the best product support out there, offering 24, five support on Slack, connect for all customers, no matter your pricing plan. So if you want to 3x your conversions with the same traffic, go to revenuehero.io and tell them we sent you. Your Sales Team will thank you for it. This episode is also brought to you by our friends at census, the number one data activation and reverse ETL platform loved by Activision, Canva, Sonos notion and more. As you might know, I'm pretty opinionated that the future of martech is composable, and that the single source of truth for your marketing data should be your data warehouse. Census helps marketers solve an age old marketing problem, getting real time complete access to your customer data without needing to write a line of code. Also, if you want your own face as a humans of martech style image, we're doing a fun monthly raffle with census for a personalized t shirt. Enter to win at getcensus.com/humans sometimes companies want to reinvent the wheel because they are very unique. And again, best practices aren't for every company, but this idea of going rogue and over customizing everything has clear maintenance costs. I

Debbie Mayen  24:10  
certainly hope not, because I'm not an engineer, you know he he has some valid points, and he has some points that I don't necessarily agree.

Philippe Gamache  24:22  
That's Debbie, main head of marketing operations at Logitech. So,

Debbie Mayen  24:27  
you know, one of the points I mean, and thank you for sending me that hour. Go ahead and read it. It was very interesting read. You know, one of the points he mentioned was he said that the marketing function in technology companies is usually a response to engineering constraints. If you don't have enough engineers to build a system to manage bidding for performance marketing, you hire a marketer, my point of view, and maybe I'm over simplistic here, but my point of view is, why would you want to. Build everything internally. Why would you want to reinvent the wheel? You it's just going to lead to customization bloat, you know? And it's also, to me, at least, it's also a signal from a company that says we're not going to do anything according to industry best practices. We're going to do everything custom that fits us right. And so it, yeah, it's to me. I just, I see customization blow. Is there a potential for, you know, internal builds to start to ramp up of it? Absolutely. I think that's where AI is going to have a big impact, right? My husband is actually head of AI at his company. He's also an engineer. And, you know, I he can't stop talking about copilot and how it helps him code, like he and like there's 10 of him, right? And so in that respect, do I think that we'll see an uptick in internal systems probably being built out more by engineer. Probably. Is it going to kill more tech? No, I don't think so. You know, I have it's it happened recently here where we had a need in our team. And I casually mentioned it actually, during one of my one to ones with with it. And I was saying that how I was going to onboard a new vendor to meet this need, because after extensive kind of research and diving in, we decided it was worth it. And he mentioned to me, he said, Well, yeah, we could build that for you, right? And I said, Well, yeah, I know you can. But why would you you have, you know, this is something that's already built. It actually inexpensive, and therefore leaves you time to continue to do the more business, impactful thing that you have on your plate, right? So I think that's where you know, just because you can doesn't mean you should. Is my, is my point of view. So it again, it all comes down to cost benefit analysis. Is it worthwhile for you to build? Is it worth it for an engineering internal groups to build a marketing automation platform? Absolutely not. Why would you want to do that? It's who has the time to maintain that, and not you run the risk of, you know, because of customization bloat, what happens when those people, yeah, if they leave and then nobody knows how to update this, nobody knows how to fix it, nobody knows how to integrate it with anything else. It's, to me, it's this. This goes back to, yeah, I see why he has these found opinions. I personally don't share them. I think there's a middle ground. Yeah, yes, some things should and candy builds internally. Well, things shouldn't, and double duty.

Philippe Gamache  27:49  
So Debbie's pretty much saying, run the math, evaluate the balance between internal builds and external solutions, and consider cost effectiveness, maintenance and potential risks of customization bloat. Anyone that's worked in marketing operations knows what I mean when we talk about customization bloat. Engineers are expensive. We don't live in this utopia of endless resources, even though we like to think that we might. Reality is most companies still have a ton of engineering constraints, and we still need third party Bartek, but let's say, for sake of argument, like Debbie said, even if we did live in this utopia most of the time, it still wouldn't make sense to have engineers build all martech tools internally. Any marketer like myself who's been stuck using homegrown tools probably has a bit of PTSD and appreciates that friendly user interface of third party tools, something that is usually deprioritized in internal tooling.

Natalie Miles  28:44  
Yeah, Casey's got a spicy take. So I'm actually really big fan of Casey, and I'm a huge shill of reforge, and highly recommend some of his content on on growth.

Philippe Gamache  28:59  
That's Natalie miles, head of marketing technology at chime.

Natalie Miles  29:03  
No surprise, I'm going to disagree a little bit this article, not purely out of self preservation, maybe a little bit, you know, sort of like the crux of his article, is this idea of, you know, martech has evolved as a response to engineering constraints. And he sort of argues that if you lift these engineering constraints, then you should just build everything in house. I would say the reality is most companies don't live in this utopia of unlimited engineering resourcing and competencies, hence the need for third party solutions. And I think most marketers have some form of PTSD from having to make some in house homebrew solution work, right? Often, one of the complaints is or one of the last things that gets built in some of these internal tools is a usable. UI for the marketer. So I think at the end of the day, who's our ultimate customer? In my view, it's the marketing team and enabling them to do their job. And so you know, who's best equipped to identify some of the problem spaces that need to be solved by marketing. I think you also have to think about, you know, going back to the reality is, most of us don't live in this world of unlimited engineering resources. You have to think about, where should you be aligning those engineering resources with your business competencies? So especially in FinTech, do you want to be a FinTech company, or do you want to be an ad tech company? Do you really want to spend your precious and often very limited engineering resources on building martech products or actual products that your consumers want to use in order to drive product led growth. But then let's you know, for the sake of argument, say we do live in this utopia where we do have unlimited engineering resources, I'd say there's always going to be a need for that one person who sits at the intersection of engineering and marketing and data privacy to figure out that problem space, whether that person is a product manager or a martech person, take out the title doesn't matter. Someone needs to be thinking about the problem space for our marketers, creating the roadmap, defining the requirements, and partnering with these cross functional teams to make sure the solutions are being actually built and delivered. And I think that's true whether you're building a solution or buying a solution. I also think taking the view that martech is just third party solutions is a very limited view, and I don't think we need to think about, you know, build versus buy as this dichotomy. Oftentimes it's probably a hybrid. Even if you're buying a solution, it takes a lot of engineering resources, usually, to instrument a new tool to get it to work. Or, you know, you may have to create, you know, some sort of like hacky solution to integrate it into whatever your existing data architecture is. So, you know, I also don't think we need to it. I think most martech stats are going to have some sort of blend of both build and buy, and most of us aren't working at fin companies, where, realistically, we can build everything in house.

Philippe Gamache  32:44  
Yeah, it's a really interesting concept for me. Like, is martech for engineers? Like, I buy the angle that engineers are kind of required in the martech sphere to fully enable your like, knowledge worker, marketer, who might not be like a SQL expert, might not have like CSS chops and needs a little help to get stuff over that finish line, like I get that point of view. Like engineers have a role to play in martech, especially like conversion rate optimization when we get into like data and tracking, but at the end of the day, like the main user of a marketing automation platform, or a CDP or, like, an ad platform, like it's a marketer, like they're the ones coming up with the campaign, the idea launching it. So I feel like martech vendors still need to sell to the end user, even though engineers, like play a role in that, in that whole journey, right?

Natalie Miles  33:39  
Yeah, yeah. And it's difficult from the B to B side. You know, a lot of these martech tools maybe over index on the marketer as their ideal customer profile. In some situations you you've got to write, you've also got your engineering team. And I can also emphasize with engineering teams, who you know, and we went through some of this in our sort of CDP decisioning, you know, like their peers, marketing is going to go off and buy a tool and not include engineering as part of that consultation process, and suddenly we've got a tool that doesn't fit with our existing architecture, you know, I can certainly empathize with that. Yeah, I think it ultimately, you know, the unsatisfactory answer is like, it ultimately depends. It also depends how closely embedded is your engineering team with marketing, if it's a very, you know, large company that is very siloed from marketing and doesn't have dedicated resourcing to marketing, right? Do they actually understand the problems that marketing needs to solve, and so that's why you always need that one person, whether it's martech person or product manager. Um. Who, who can kind of be that translation layer between, you know, the marketing problem, and then also understand, kind of the basic data infrastructure and data architecture to find the right solution. If

Philippe Gamache  35:13  
engineering constraints are lifted, companies should still avoid building everything in house. Homegrown solutions are hacky, hard to use. Usually have bad UIs, and overall it's really hard to manage. Let's say Casey's right, though, and that martech is fully serviced by engineers. Can those engineers handle marketing operations and be that bridge between marketing engineering and data privacy? Can they handle the strategy involved in marketing operations? Martech is

Ashleigh Johnson  35:40  
the marketers, I can't tell you. I don't think I know any one in the martech space that has an engineering background. One

Philippe Gamache  35:49  
that's Ashley Johnson, marketing technologist at Microsoft.

Ashleigh Johnson  35:53  
Better the hot better, the hot topic question, goodness. Yes, I have to be technical in what I do, but at the same time, I have to be able to strategize, right? I have to be able to strategize with marketers, with the business on how we should be using these tools in tech. Are you able is a market? Is a engineer able to do that? Yes, a marketer can be technical, but can an engineer be a strategizer when it comes to marketing initiatives. Like, I need someone to answer that question, because I think that will put this whole debate to ref.

Philippe Gamache  36:27  
It's a tricky it's kind of a tricky one, and it feels a little contentious, but I think you're on, you're on a solid thread, martech people in humans and martech and marketing operations people are engineers in a lot of ways. They just don't necessarily code or have a computer science background, but like, if you just take a step back and look at no code tools, like, what is coding? I know coding. It's like, if then loops, you know, recursive statements, like, are we just making it more complicated for ourselves? Yeah, no. I like your point. Ashley, about like, ultimately, martech is about servicing marketers. It's working with marketers to understand their pain points and building systems and processes that enable them to do things faster and be more efficient. And even though you could make the argument that on the platform side, integrations and API and like customizing stuff with JavaScript that maybe you could use engineers as part of the process. But when it comes to, like, the consultative piece that you just kind of mentioned, working with marketers and like strategizing around like, how can we build something for you that, like, makes your life easier and understand in the context of of marketers. I feel like that's, that's like a perfect rule for a marketer. And like, you assign an engineer to do that. And like, All right, well, I have to, like, spend a year learning what the hell a marketer does and what their pain points are. So yeah, I really like your point.

Speaker 1  37:54  
I think it also goes back to what we talked about, expanding that knowledge. Right before this, I had no knowledge of coding or how integrations work within Tools, but having that experience now, of having being able to expand my skill set, there it has. It's been a good thing. And so I wouldn't necessarily say, and thinking about two integrations, it's not that complicated. Once you actually know what you're doing, right? It's not something that is engineering is always needed for. And so I do think a marketer going back, a marketer can be technical. An engineer can't necessarily be strategic.

Philippe Gamache  38:43  
I think some engineers can absolutely be strategic, but Ashley makes a compelling point. When it comes to marketing operations, the tech is usually easier to pick up than the strategy component, understanding and addressing the needs of the marketers on your team is kind of at the heart of all of this topic, and it's best suited for those with a marketing background. Maybe martech was born out of engineering constraints, way back in the day, cool. But marketers have also evolved. It's not the arts and crafts department anymore. Martech is fundamentally designed for marketers, not engineers.

Josh Hill  39:19  
That's a tough question. I think you're right in the fact that it was a response to engineering constraints,

Philippe Gamache  39:26  
right? That's Josh Hill, best known for creating marketing rock star guides blog for seven years, one of the top blogs supporting marketing technologists. That's, I don't know

Speaker 2  39:36  
how much anyone remembers about the original marketing automation platforms and the number of competitors that were actually around in 2009 and 2000 and a lot of what they were saying was, don't wait for the web team. Don't wait for engineers to build your form. You can do it yourself. You have templates. That was very appealing. I'm like, Yeah, I know, in Norfolk Valley, you know, I. How this should work that, yeah, why should I call the engineering team? It's going to take three months to build out a custom fork. This is obviously, there were CMSs at the time. Many companies were still leveraging, kind of, not out of the box, customized things, or they had all sorts of back stuff together. I mean, some still do, but it wasn't as API friendly. So how does a marketer get a webinar format that on bringing on the kind of experience that you want? And Mercator, eloquent companies, they that was what they were solving for. Now there was a period of time full median for the last couple of years where I did solve the engineering demand gen marketer, even with some knowledge of technology could do that right. And then you ended up with the marketing operations teams and specialists who knew how to leverage this more effectively and specialize on it, right? People like me who kind of had a technology background but wasn't really wasn't in technology, right? But it was natural for me to kind of be interested in that and make full time switch to say, I'll do this, but having that background in marketing fails is very helpful in kind of understanding how to apply to technology. Whereas you and Sarah were talking about, it's like an engineer doesn't always know what the market is really thinking, regardless of friction points where marketers, you know, some marketers, especially in technology. Thus, companies change your mind a lot it you know, it's not about you can't mind read someone Right, right? So, like, if the marketers have to keyword doing it technically, theoretically better. And I think that was very effective for certain kinds of organization. But as Marketing Tech has matured, as people want real time omni channel personalization, it's they work on plg motions. They work closer to the databases, because that data that you need to drive campaign or sales motion or trigger certain things is no longer exclusively in the more more and more companies and marketing UPS people are looking at the map and saying, Well, it's acting like my CDP, but it's not really what I needed to do, because they can't handle certain things on that certain scale. So for many organizations now, they need marketing engineers or they need more coders to do a certain thing more effectively build that experience, you can have at least a hybrid marketer, engineers like me or people on my team to do that. You could hire actual data engineers to help you do those integration there is a shift at a certain level of organization where you need more engineers, but I don't think martech is designed for engineering. I think it's still designed with really marketers in mind, which, you know, we could have a debate about, is that the right approach? Because the reality is, most marketers don't use it right. The mops team that uses it. So

Philippe Gamache  43:21  
like Josh says, maybe martech was born out of engineering constraints, but it's evolved to necessitate a hybrid approach involving both marketers and engineers. But I think it's totally fair that while the tools are designed for marketers, effective implementation definitely requires technical expertise and sometimes involves engineering. So there is definitely the importance of cross functional collaboration with your Eng team. Actually, cross functionality is a really interesting part of this debate, like, what is engineering anymore? Is it even a single department right now? Maybe functions are kind of blurring more than we think. I don't

Stephen Stouffer  44:01  
think he's wrong necessarily. I think it's like, okay, so I'm gonna say I think he's right.

Philippe Gamache  44:08  
But that's Steven Stouffer, VP of Digital transformation and innovation at suscend.

Stephen Stouffer  44:15  
I think he's I think there's some messaging being missed there. Yes, I think it's being catered to engineers. I think you need to have a technical background. Technical background to really unleash the power of all things AI and not create a whole bunch of problems with the data integrity and systems integrations and APIs and, you know, blah, blah. But I think the engineering role is being decentralized. I think that 10 years ago, 15 years ago, there's an engineering department that tickets would be opened from marketing, tickets would be open from sales, customer success, etc, and they'd be flowing through one department. I think it's being decentralized in that marketing is hiring engineers for marketing, sales is hiring engineers for sales, and we're getting these engineer type roles. But within. Departments themselves. It's not its own department, like maybe it was. So I think the technical role of folks on the marketing side, the sales side, is increasing. Like, I can't tell you how many content folks who are writing emails and who are writing social media posts, but they also know HTML, and they also know CSS, and they also manage some, you know, a Zapier account, which is kind of a soft integration tool, where they, know, kind of JSON, and they're starting to work with APIs a little bit. So I think the lines are blurring a little bit. I think to create a robust system and a robust company that can scale, you do need engineers, and they need to be engineering focused, but I'm just not seeing them in their own department anymore. They sit on the sales team, they sit on the marketing team, they sit on the customer success team, they even sit on the finance side for knit suite and QuickBook integrations. So yes, but decentralized.

Philippe Gamache  45:57  
So the lines are definitely blurring. Instead of asking if martech is actually for engineers. Maybe we should be asking, is engineering an integral part of marketing, sales and customer success teams, rather than being confined to a separate engineering department? 

Philippe Gamache  46:12  
Anyways, that was super fun, folks for all the listeners and the viewers, thanks for making it this far. I wanted to just spend a bit of time recapping some of the main counter arguments to the initial article here. So number one, homegrown tools aren't appealing to marketers. If you've worked in some of these tools, maybe you got really lucky and had one that was really well supported and you actually really enjoyed it. But you know the idea of we built our own CRM or our own marketing automation platform? Is it actually an appealing thing to tell to a seasoned marketing technologist? It's hard to scale. Most have a really UI, and it's not recognizable as a name that you can add to your resume, that arms you with, like transferable skills to a company using the same platform. There, I can think of countless marketing experts that have kind of made a career on the back of expertise in a platform or two. How many of them have made a career on homegrown platform that you won't find at any other company? Number two, working on internal martech isn't for engineers either. Not only are homegrown martech tools not appealing to marketers, they're even less appealing to engineers. Let's face it, working on product pushing features that get seen by 1000s of customers is way more attractive than building internal tools for a handful of marketers. No engineer wakes up one day and is just like I'm so excited about building an internal CRM for a handful of marketers. And those marketers you're servicing, they live in a chaotic and unstructured world, something most engineers would probably loathe. Number three, we don't live in this utopia of unlimited engineering constraints that can be diverted from product. Do you want to pivot and be a martech company, because usually the cost benefit analysis of build versus buy favors build only when you can not only service internal marketers, but add it to your core product offering and add value to your customers. A company building in like FinTech or health tech should be ultra focused on FinTech or health tech in their industry, and not divert those engineering resources to tools they can't offer to customers, not when there's 13,000 potential third party alternatives. Number four, engineers will always need translators to speak marketing and vice versa. If martech is actually for engineers, it means engineers can also handle the process and the people side of the gig and marketing operations isn't just about tech, after all, right, but engineers don't understand a day in the life of a marketer or the nuanced use cases like marketers do. Martech will never be just for engineers. Will always need a translator, someone who can bridge technical counterparts with other cross functional teams across data privacy, IT and marketing. And finally, number five, decentralizing the role of engineering. Martech byte have been born out of engineering constraints, but it's evolved to necessitate this hybrid approach involving both marketers and engineers, while the tools are designed for marketers, effective implementation does require collaboration with engineering, so we definitely need to highlight that component there. Ultimately, folks, here's my main takeaway on is martech actually for engineers. Should you buy a third party martech tool or build your own in house tool? The answer is almost always, buy. Let your in house engineers focus on products and data while leveraging the cutting edge solutions and support offered by specialized martech vendors. Unless you're planning on building a martech company, leave the. Marty to the experts, we'll catch you next time. Folks, thanks for watching and thanks for listening.

Philippe Gamache  50:14  
Folks, thank you so much for listening this far. We really appreciate you being here. Just wanted to call out two things before we go. Number one, the best way to support the show is by signing up for our newsletter on humans@martech.com we send you a quick email every Tuesday morning letting you know what episode just dropped. We include our favorite takeaways. So if you don't have time to listen to that one, no pressure. We have you covered with some learnings anyway. And number two, proceeds from sponsors this year to have allowed us to venture into video. We recently launched a YouTube channel where we publish full length episodes. So if you want to see our radio faces, check that out. That's it for now. Really appreciate you listening again. Thank you so much. You

Transcribed by https://otter.ai