Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS
Chris BachOver the past ten years, Chris Bach has been at the forefront of the transformation of web development.
Chris coined the term “Jamstack,” which refers to one of the first conceptions of a composable web architecture (the acronym JAM accounts for the JavaScript, APIs, and markdown that make up a simple decoupled web system).
He also founded Netlify, a company that supports these new architectures and which now serves tens of millions of customers.
We talked about:
- his role as the co-founder of Netlify
- the origin story of Netlify and decoupled web architectures
- how the JAMstack movement arose in the tech ecosystem of ten years ago
- how phone app stores set the stage for decoupling apps from data
- the technical developments that permitted the development of this new ecosystem: cloud computing, APIs, Git, static site generators, more capable browsers, etc.
- their development of the open-source developer community that supports the JAMstack ecosystem
- the emergence of headless CMSs alongside the JAMstack ecosystem
- how his 14-year experience in digital agency work informed his work at Netlify
- how issues like performance, security, and scalability show up in the JAMstack world
- the benefits of decoupling back-end services and front-end web presentation
- the advantages that composable architectures offer: simpler migrations, quicker time to market, reduced operational costs, etc.
- the evolution of his conversations with enterprise clients over the past 10 years
- how composable architectures permit better decision making and quicker action around adopting new technologies like generative AI
- how generative AI is changing content marketing and his thought that less content of higher quality will be crucial going forward
Chris’s bio
Chris Bach. Serial entrepreneur, unicorn founder (Netlify), co-creator of the “Jamstack” terminology, featured as a “2024 top 60 angel investors that back B2B startups” by Business Insider, and outside of 50+ angel investments he sits on 15 advisory and executive boards. He also an advisor for TUM (Technical University of Munich), Copenhagen University, and the Danish Innovation Center. Danish but lives in Silicon Valley.
Connect with Chris online
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 203. Ten years ago, web development was in a very different place. New technologies like cloud computing, APIs, Git repos, static site generators, and headless CMSs were emerging, but how they might all work together wasn’t yet clear. Into this primordial version of the modern web stepped Chris Bach. Chris co-founded Netlify, an innovative development platform which has been instrumental in creating the web’s new decoupled and composable architectures.
Interview transcript
Larry:
Okay, here we go. Hi, everyone. Welcome to episode number 203 of the Content Strategy Insights Podcast. I am really excited today to welcome to the show Chris Bach. Chris is the co-founder at Netlify, a web services company, a development platform where probably most of the stuff you look at on the web is happening over there. He’s also an advisor to a lot of other companies, an investor. He sits as an executive on a number of boards. So welcome, Chris. Tell the folks a little bit more about what you’re up to these days.
Chris:
Thanks for having me. Yes, I am the co-founder of Netlify, as you said, a developer platform. We run a lot of site stores, applications, and so on. For the last three and a half years, I’ve been CSO there, so a little less operational. And then I actually just stepped out of my full-time role there. So now I still sit on the board. I continue my work as an advisor, as an investor, and as a board member. Also looking at a little bit of climate tech, which is a little outside the scope of today’s conversation.
Larry:
Yeah, I’d love to talk more about that some other time, but, well, first thing, I think a lot of folks like Netlify. In the landscape that many of my listeners occupy, it’s a thing their content is going through every day, but they probably don’t know what it is. Can you describe the company and maybe the origins of it too, because it was a new concept when you started it 10 years ago?
Chris:
Absolutely, yeah. So the origin and the backstory of this was that the web 10 years ago was struggling and it was losing out to walled gardens like App Stores and so on. And it wasn’t because you’re using one piece of software, let’s say WordPress or Drupal or whatever, it didn’t really matter. It had to do with the architecture underneath it. And that architecture meant that a website essentially was a program running on a singular server somewhere and building a version of itself for every single visitor. And that made it fairly slow. It also made it very vulnerable. The code was exposed and it didn’t scale very well. And my co-founder and I were sort of eager to see what could be done to change this, because the web is a place where everyone has permission to publish and so on. It should be a place where, if you want to publish something, you shouldn’t have all these gatekeepers and it shouldn’t be controlled by a singular company.
Chris:
And what we saw was that, if you could do essentially what happened with mobile apps, which is decoupling the application itself from the back end, that would solve all the major issues. So the notion is that you can more pre-build a front end, and that front end means your UI, your presentation there, whatever someone is going to experience on that browser, however they’re visiting that, if that could be separated from the back end that has to run and feed all the data into it, well then, that can be pre-built to a higher degree. It also solves for if you have multiple digital touch points. Let’s say I have a mobile web application, I have campaign sites, I have my main.com and so on. All of those can draw from the same back end because they’re built separately and then they would just access the back end as what we today would typically talk about as a headless API or microservice and so on.
Chris:
And this decouplement just made a lot of sense. Essentially, we wanted to decouple the front end from the back end, and in that we saw that it would solve for notions of scalability. You would have multiple points of origin. It would be way faster, more secure, more scalable, but it would at the same time also require a reinvention of the ecosystem. So let’s take e-commerce. Every e-commerce provider at that point, well, their output was always a website, it was a dot com or whatever it might be. And so that means that you can have that and then that outputs your website and that’s it. And so you can’t marry that with something else that also has an output of a website. In other words, we needed someone to come and invent some headless commerce solutions and headless content management solutions and so on and so forth. Everything from form handling, which it was one of our first debits because it was so frequently asked for. Sign up for newsletters or whatever it might be because this started with blogs in the beginning.
Chris:
But this was really the notion. There were a few things already that we had made as third party services. So if you think of payment gateways, that was a typical thing. I don’t build that myself. We figured that out even before then. But we still ran these monoliths. And so we said, “Okay, well we can’t build out an ecosystem, but we can pave the way of saying, when you go,” what we today talk about as composable, headless. When you follow the best practice of the Jamstack, in Danish where I’m originally from, Denmark, you say, “Dear child has many names,” and there’s a lot of ways of talking about it, a lot of nomenclature out there. But essentially if you follow this architecture, then when you get, let’s say, a traditional CMS, what you’re also getting is not just content management. You’re also get an template engine, a build tool, glue code. You’re getting all these things that you don’t really think about, but it’s there to help you output a site at the end of the day.
Chris:
Now, those things, I can mix and match the best builder and the best tool over here and the best commerce solution, the best CMS, but how do they actually talk together? How do they integrate? How’s that notion integrated with things like CD/CI? That’s continuous integration and deployment. And how is it actually distributed/hosted afterwards? And so in other words, you needed to rethink the whole workflow, the whole orchestration and operation parts of how we do these site stores and apps. And that was a platform that we felt that we can go and build. And so that’s what we did. That’s the origin. We built on Netlify as a workflow platform for anyone that wanted to build these decoupled sites. But, of course, back then, there wasn’t really a notion of decoupled and what it actually entails. So we came up with the terminology around JAM.
Larry:
And talk about JAM. Well, actually, I’ll let you define it, because I’ve heard the M described as a couple of different things. But you invented this, so I’m going to defer to your origin story knowledge of it.
Chris:
This is JavaScript, APIs, and markup. It was the notion of decoupling, but there were a lot of things that led to this decoupling that enabled it. Chief amongst this was actually that browsers had become an operating system, because that’s why you had an App Store on mobile phones. Many people don’t know that when Steve Jobs presented the iPhone in a PDF, the App Store didn’t exist. All those icons were showcased to websites. It was only because, again, the web wasn’t in an architectural state that was performing enough that we shifted and said, “Well, this is not going to work. You can’t pull in the UI every time you turn a page. The phones aren’t fast enough. The broadband isn’t fast enough. We have to do something else. Why don’t we pre-build this, download it, execute it by the phone’s operating system, and then pull in whatever needs that real-time updating from other microservices?” Great. Problem solved. “Hey, by the way, now we can get an App Store. We can take 30%. Then we can regulate all this.”
Chris:
But I think the browser had become a full-fledged operating system. That used to be a document viewer. That became a really linchpin in this, hey, you can actually take that runtime and instead of having one server that has to cater 100 visitors, you can have 100 browsers doing that for you. Then, of course, came much more powerful edge software. There was also distribution of compute, and that has all evolved since then. But the best practices evolved. There’s still the basic notion of decoupling those things has become obviously quite default today. But in this, we had to talk about, another part of this was using Git. Another part of this was using early site generators and what we talk about as JavaScript frameworks.
Chris:
And so there were early stabs at all these things, but there weren’t, as I said, very mature like browsers, but there weren’t a notion by anyone that they were all part of this same story that this actually enabled a new architecture altogether. And so in order for that to become a thing and to become a movement and for the ecosystem that we were super dependent on to start building for this, it had to build for something. Otherwise, it’s just, well, Git is great. It’s version control. That’s end of story.
Larry:
I got to say, for those of us on the outside looking back, that story checks out, but you were there building this thing. So you’ve mentioned a lot of the things that were there, like cloud computing, and the closely associated, I guess, notion of APIs. You have the ability to do stuff abstractly and scalably in the cloud. You have APIs as the way to stitch it together. I’d forgotten the detail of the browser capabilities being so crucial. And then the idea of having Git there as a place to put all your code, I can’t remember, did those all tumble together nearly in the same year?
Chris:
Well, it’s more saying, “Hey, if we decouple this, what are the dependencies? What would it take to work?” And you identify, well, the high economy is becoming a thing, but it’s a thing. It’s not because you’re saying, “Hey, I have to make this available as an API,” because then it can serve as these decouple websites. It is not that understanding, so you’re not specifically building to order, and it needed even more momentum. And so that was the notion of saying, “Hey, right now we just draw some lines in the sand and saying, if these things happen, if we circle around this and we keep building out here, then this version of the web essentially will be viable.” So we need to take that and get everyone else excited about it as well.
Chris:
And so Jamstack, JavaScript, API, and Markup had nothing to do with… Netlify, very often, if you look at the mean stack or Lamstack and so on, the acronyms has to do with specific service providers, but we’re two Danish guys. We weren’t thinking that, that would be a wise move. And again, I was much more interested in getting an ecosystem and growing the pie, so to speak. And so we wanted to talk about it in a way that everyone, including competitors or anyone with competitive overlap, would also want to embrace it. And so that was the notion of the Jamstack, and the idea was that, hey, if you use this approach, you get these sites that address the main issues with web essentially today, web properties today, whether it’s sites, stores, and apps.
Chris:
And that was the notion behind Jamstack. And the basic was that, hey, you want to not run things as a monolith on a singular server. You want to distribute the workload by decoupling. And then the best practices, they changed. Of course, you needed to rethink distribution. So distribution back then, typically, it was a constant delivery network or a CDN. However, that CDN, like Cloudflare and so on, was meant for images and video files. It was never really meant to do anything else but that. What we needed was something that was geared for small files. You needed to actually take the whole site, the HTML itself, and distribute it. The site or the property had to have multiple points of origin, and nothing was built for this. So we had to build our own as part of the solution. So even though we always saw ourselves as a workflow company, we had to be able to provide that infrastructure.
Chris:
Now, we didn’t have our own metal. We just piggybacked off the data centers of the … that do, like the large cloud providers out there, which also gives a lot of flexibility and a lot of redundancy and all these things that you typically want laid on as an enterprise. But that’s another story. But that was really it. So some of the things we had to invent and others were already there, but they weren’t thought in connection in to support this new way of building. And that was really the motivation behind the category because, outside of that, if it wasn’t then people would use this to build their own blogs.
Chris:
It was very developer bottom up, and it didn’t really have an application inside large organizations because those headless services didn’t really exist yet. Good luck finding an enterprise ready common solution that was headless. It didn’t exist yet.
Larry:
Yeah. I want to quickly ask, how did you jumpstart that chicken and egg dilemma? Because you need headless services for this kind of architecture to work.
Chris:
Absolutely.
Larry:
How did that come together?
Chris:
Well, so first of all, we were out there talking about the examples of this have been very self architected, but with great extent. There was the Obama campaign, which was from a digital point of view quite a milestone. They had been built with a separate decoupled front end. You can almost call it a modern static site, where that meant that the load they could take at peak times traffic wise wouldn’t lead to the site crashing, which it would in other circumstances, because you can’t handle that much traffic alone. But here you could distribute the load. Now, it wasn’t a service that anyone else could go and buy and use, it was very homemade, but it had used an early site generator called Jekyll, made in Ruby by Tom Preston-Werner, founder of GitHub, actually.
Chris:
And so we saw these examples that had great benefit and also very obvious value proposition for an enterprise as well. And we went and talked about these things. Also, our first clients that built meaningful things, they had to self architect a lot of these things in order for this to scale, and then we spent a ton of time thinking about, how do we engage with the community? So in open source projects, we may deploy Netlify button so you can click through this and then your read me text would be a website with a single click. Because we had automated everything that was into the CD/CI solution, and we took all the site generators and made what became the world’s largest open source directory off site generators in the world. And every time someone would submit something to that, we would get that contact info and we could reach out to them and say, “Hey, this is awesome. Love what you’re doing. You want to chat around how you’re part of a bigger thing?”
Chris:
And so we created advocates and fellow enthusiasts about that. Because that was the idea. Get into the tool bits of as many developers as possible and then create awareness of this entirely new way to build. Because, again, it’s not just getting people to use Netlify. For us to succeed, we had to enfold for our vision of a better web. To succeed, the ecosystem had to be built out. And so, of course, you then go to the conferences and you do meetups and do everything you can, and then you do integration with anyone coming out. So even if it’s an early CMS that’s decoupled, Contentful already existed because they had seen the notion of saying, “Hey, if you have a mobile app and you have a dot com, it would be great to have not the front end dictated because then you can do whatever you want and then you can just pull from the same place.”
Chris:
So we started meeting with the founder there every two weeks talking about, how do we get the mission out there? So really heavily engaging with an early community was a big part of it. And then thankfully the ecosystem really came, and I think it came because it was a win-win-win. Hey, this is, objectively speaking, a better way to build.”
Larry:
Tell me more about that community because one of the, I won’t call it a criticism, but people like Greg Dunlap and others in our community have observed, an Lo Etheridge at HighGraph, and others have pointed out, everything you said, it makes sense that developer relations and DevRel outreach is probably the thing that makes the most sense. But a lot of content people feel a little, not excluded, but like, “Hey, can you come talk to us?” I know you’re doing heavy, deep back-end work, but was it ever part of your plan to go further out from the core and out talking to designers and content people? Tell me a little bit about those.
Chris:
1000%. First of all, I think we knew, we called it the biggest microservice out there, needful. And that was just, what dynamic “function” is the most needed by the most users out there and it’s a content management system, a way to create and update content for people that don’t code, essentially, very simply speaking? We also knew that nothing became a standard without open source. And so there was Contentful, but there was no open source CMS out there. And so we actually built our own called Netlify CMS, and it was only because the others were API driven and we wanted a Git-based one, because that was the new workflow. Everything went through get Git. The whole notion of GitOps really started there. And so we did this, and then thankfully, within a year or two, we started seeing other commercial players come up with both Git-based stuff, open source stuff, close up. It became a saturated landscape and we started seeing all these content management solutions.
Chris:
And for me it’s like, well, if you’re trying to build a CMS and you’re trying to give that catering experience, one thing, if it’s a site built, if there’s never a developer involved, but that I feel is a very separate part of the market. We’re talking about the market that’s the 70% that’s built by professionals for themselves or other people. And I think those are the ones we’re catering. And once you talk about that, but they also in the organization have content moderators and so on that needs to be done, then I really believe that having something where you can create a great experience but at the same time not restrict people to saying, “Well, it’s never going to work very well on this data touch point. It was not going to translate to this at all, and so on.”
Chris:
I think that’s a huge advantage. I saw a lot of early people that were working with content management and so on that said, “Hey, this could be the first time where we really get a content management solution at length that will cater both developers and content creators and content managers,” because there was a huge divide then, the CMSs. And I came from 14 years and SIs before that. And I was Chief Digital Officer. I was very aware of the divide. I came from a place where I had front-end developers as well, by the way, that exclusively cut out Photoshop files and turned them into HTML. That was the job. That was what front-end development was.
Larry:
I remember those days.
Chris:
And then sent them off to implementation, right?
Larry:
Yeah, totally remember that. That’s right. And your agency background, because you spent 14 years, you had a lot of experience building digital experiences and having a feeling of like, oh, I bet there’s better tooling and platforms we could be working on. How relevant was that to the foundation and the conceptual foundation of your work?
Chris:
So when Matt, my co-founder, who was already doing a fully hosted CMS over here, actually doing it as a monolith but feeling like he was building for obsolescence at every turn he took and every time something new came out and new trends in front end and so on, they weren’t moving towards what he was doing, but it felt to him foundationally like he was moving away and he came with these basic notions of what this decouplement would look like. What was interesting for me was that he was challenging what I thought was the premise of doing business online. The notion of optimizing by not having a server was as relevant to me as trying to optimize for people that don’t have screens. It’s like, well, okay, if you don’t have a screen that’s probably going to be hard. It wasn’t, in other words, something that I was spending a lot of time on.
Chris:
But at the same time, the security concerns, they were becoming brutal. I remember the Drupacalypse. On their website, on the main website, they were like, “If you haven’t patched your site within seven hours, you should consider yourself hacked, and all your plugins will break.” It was a messy time and there was more and more of it, but, of course, there is. Because all of these are building in the open constantly everywhere, and they’re also a very large surface area. They have to cater for all these edge cases. It just becomes quite hard. And the complexity of what you need to do and what you need to integrate with is also exploding exponentially. So for so many reasons, that was hard. Scalability as well. More and more people were visiting sites and mobile was coming out and we saw all that traffic as well. And so it was really starting to creek, and all the times people said, “So what hosting solution do we want for this?” “I don’t know, we just build it. Let’s hope that people come.”
Chris:
And so Western agencies double provisioned hosting costs on average by 700%. 700%, that’s because most things could probably get away on putting on a DreamHost or whatever it’s called in your local market, something that’s cheap and easy. But, of course, in the minute, you get real traffic, you’re done because you didn’t pay for that. And so if you’re done because you opted for a campaign site and all of a sudden it gets traction or it gets mentioned on the front page of the New York Times and you tell your client, “The reason it went down was because we chose a $9 a month hosting solution,” probably not going to talk to that client again. And so you over-provisioned and then still three, four, five times a year it wasn’t enough and you had those things. And so this notion of saying, “Well, it’s pre-built so much to a large extent. It’s already globally distributed because it lives on an ADN/CDN.”
Chris:
That was a huge value proposition to me. It’s like I don’t even have to think about it. It’s just there. And then you can say, “Well, what about, let’s say, a checkout experience,” or something else that needed to be dynamic laid on? Yeah, sure, but at least they have a working site that they’re on, and it’s not just blanking out. You can give them a pretty rich experience already. And so the more I dove into this, the more I saw it. It challenged my main issues around performance and scalability and security. And so that was why I became really bullish on this and said, “Hey, this is fantastic.”
Chris:
And then there was the adventure of doing this with a friend moving to Silicon Valley and trying this out. I was like, “Okay, I’m enticed.” And at this point, I’d also done so many projects, but there’s a limit to how deep you go when you’re an outside agency and you move on to the next thing and the next thing and the next thing. And I welcomed the notion of saying, “I want to double click on this and see how deep the rabbit hole goes.” So that was my last reasoning.
Larry:
And not even 10 years later, here you are already departing it. I don’t know if you’re going, “Mission accomplished.” But that’s awesome. Hey, one thing I wanted to talk about, I think a lot of people, their appreciation of the benefits of these architectures probably comes out of that, I remember 10 or 15 years ago, it was super common to have that, “oh crap, the site went down” because of some successful promotion. The other one that’s I think really relevant to a lot of people is search engine optimization and the growing importance over the years of site performance as one of the metrics there. Are those two major things or are there other benefits of these kind of architectures that jump out?
Chris:
By the way, just for what you were saying before, this notion of how it’s proliferated, today, I hatched it up, but if you look at the notion, we started with 0.01% of sites built in this way, now it’s probably 97%. The best practices can keep evolving, but the notion that the way you’re building the presentation layer is pretty separate from that backend, it doesn’t have to be dictated about it outside of a site-builder environment or target audience. We had 97% or something. It’s completely happened. And so even the notion of the Jamstack isn’t used very much because it was such a quick term to outlive itself because it became default. And it’s the same if you think of, before, we didn’t talk of dynamic websites. We did in the beginning, but then everything was made with that service site hack of, “Hey, we’re going to build for every visitor because then you can have someone leave a comment and someone read it, even if they’re visiting the site two seconds later.”
Chris:
It was beautiful. So it’s really one of those things that truly has become. And I love this notion of coming out and solving those problems, and Netlify has also ourselves seen some growth here. We have about five million developers at this point and businesses, and they run around 50 million sites, stores, and apps. So we’ve also seen the scale there. And, of course, this has evolved into enterprises using this for the largest of the digital solutions. But yes, I think the notions that we talked about now was so far the advantages of decoupling. But if you go to the advantages of a composable architecture, so let’s zoom out a little bit and look at larger solutions, so instead of just the website, let’s talk about your best digital experience platforms, the DXPs or the like. That means largest suites that encompasses your dot com. It might also have campaign sites, but it also has a lot of different backend modules of content management and commerce and so on.
Chris:
And I think the notion there, and I’ve saw that as an SI. It was so painful because you had these huge monoliths and then you’re saying, “Okay, well, this is dated, or for whatever reason we can’t use it. It doesn’t offer the right multilingual support for what we need to do. The markets. Whatever your reason is, I want to move to the next thing.” Now, you built that out. You portal the content and so on. You feature lock it and 18 months later you’re live. And this is a multi-year process, and you have no idea if this was a good idea or if the millions and millions that you spent were well spent until you start switching it on. And so that’s super painful. And I often thought, this is grotesque. We want to change this part, but because of that, we have to change everything else and everyone will do everything they can to lock you in. So it’s not easy.
Chris:
And I think the beautiful part, and one of my favorite parts of decoupled and composable architecture is the ability to gradually migrate. It also means that, hey, I have this and actually this part I really like. It’s part of my old monolith, it works and so on, but these parts don’t. Well, let’s change those parts first. What it also means is changing everything, there’s no silver bullet. That will probably take as long as it did before, but you get value gradually and along the way. And that is a huge, huge differentiator. This notion of saying, “Yes, the architecture works. I can see it. Our conversion metrics are better. Our operational costs have lessened. Our time to market is much shorter. And I can see that right here, so let’s do it for more of the solution,” that’s powerful. It’s so hard to do with a traditional monolith.
Chris:
And then I think another thing, and this is what I’ve spent the last few years in Netlify often around, I think there’s always these digital transformations. And I think that by now, finally we have an enterprise especially audience that knows that, okay, maybe this digital transformation thing that I’ve been sold on now for two, three, four times, maybe that’s just going to keep happening. Fair enough. But I think outside of that, and I often say this, that, when I sat with a CTO, VP of Engineering, whoever it might be, the key stakeholders back in the day in my SI work, essentially what I was doing, it could be finding out a social media monitoring tool for Sony in Europe, or it could be the digital strategy for the Walmart of Northern Europe overall, but it always came down to trying to figure out, what is the right solution? That was it.
Chris:
Today, those conversations have fundamentally changed. Now, there is no right solution. The notion is that what they have to do is to be agile enough to move fast enough to be able to take services, use them, and discontinue them, to constantly interchange your stack. And I think, well, we had 10 times more digital services than we did 10 years ago, and there was a lot 10 years ago. But secondly, this notion of being composable becomes extremely important when you look at things like AI. Now, AI is a newborn. It’s an infant, generative AI. We can always discuss how intelligent it is, but it’s very good at summarizing, synthesizing, and automating a bunch of tasks. And there’s only more of it. Already now, there’s this notion that most businesses will have to, at this point, have leaned in to AI in one way or another by vendors or themselves in order to not stare at a competitive disadvantage.
Chris:
But how in the world are you going to pick a winner at something that’s barely started? The notion that, “Oh yeah, these are the ones and this is how it’s going to be, and we’re just going to build that way,” that’s naive. And basically anyone I will talk to will know that, whether they’re practitioner or whether they’re a enterprise buyer or whatever. And so in other words, you have to lean in, but there’s no way to pick the right solution necessarily. There’s a perfect example of saying, “What I need to be able to do if I’m responsible for driving the digital infrastructure or digital solutions for my company, I have to be able to make a decision where I can take on something, integrate it into our stack, and then discontinue this or discontinue something else with as little friction as possible.”
Chris:
So it needs to be able to also by mergers and acquisitions and all these things. How do we remove friction and stay agile as we use all these different services? That is the key, not finding the right solution. And so obviously that’s also a very big focus of Netlify, providing you all the necessary automation. Because if you keep doing operations as usual and you have all these different building blocks and specialized engineers for all of them, your time to market is going to suffer so greatly. There’s so much manual work that taking this new component, these new intelligence software, whatever it might be, and implementing it into the rest of the stack is going to carry so much friction that it’s no longer viable. And so you don’t, and if you don’t, then you’re left at a disadvantage.
Chris:
And so I think that’s really the notion. And if you zoom out, fly up on your helicopter and zoom out as much as you can, and when it comes to this notion of the benefits of decoupling, that’s probably the very largest and furthest reaching one. Today, you have to go composable.
Larry:
Yeah. Five years ago, that merger and acquisitions use case would’ve been probably the most compelling. And now it’s like, “AI, are you sure that your monolith vendor is doing the exact right thing that you need, or should you be trying stuff on your own?”
Chris:
Are they sure?
Larry:
Exactly, yeah. Hey, Chris, I can’t believe it, we’re coming up on time, but before we wrap up, is there anything last, anything we haven’t got to that you want to make sure we cover or anything you want to revisit from the conversation?
Chris:
No. I mean, there’s so much to talk about. This was a bit of a trip down to, how do we get here and what decouple is and why is it important? There’s also the notion of, how is AI going to influence this, the different consult? The constant creatives, for example, how do you stay relevant? I was traveling around Europe talking about content marketing in my SI days and I love the notion, this notion of saying, “Hey, you want to go and qualify your product rather than just carpet-bomb advertisement, love it. Do that. Carries credibility and a bunch of other things with it.” And in our world of SaaS, it means integration into third-party software and all these things, and articles on how best to use the product and adjacent things to your product and so on. The problem now is becoming with, it’s already saturated.
Chris:
There’s not a company that doesn’t do a lot of this and have podcasts and all these things, but with AI and the notion of being able to auto-generate these things, what’s the user going to do if you look out even something quite specific and there’s 100,000 hits? And is it just going to be Google that decides that? And I think that going back to creativity and providing real quality content, and probably less of it, is going to be one of these things that’s going to be part of how you win and how you get your voice out there, more so than just the execution itself of provide a bunch of content and do it quickly, which I think we’ve seen more of in the last 10 years. So I think, for content creators, things change. Of course, the offspring services like CMS in itself is going to change very much, because a lot of that is about structured data and the notion of that changes if AI does a lot of these implementations for you.
Chris:
So I think you want to keep your eye on the ball of the actual value at which is the content creation in itself. How do you do that best and what are the right channels for that, and so on? But the landscape is obviously changing tremendously, and all channels of storage are going changes, where we might have a little bit of interaction in the social media. Now, social comments, you can do the whole transaction there. I’m sure that the aggregators like Google are going to go more in that direction already. You don’t go to the Weather Channel anymore. You go to Google and it’ll show you the weather right there. The same with plane tickets. That’s probably going to happen with a lot of other things as well.
Chris:
So the buck is totally moving and very, very fast in that way, but I think if I was doing it and I was sitting and my focus was constant creation, I would be more than ever thinking about, what is the actual value-add here and how do I double down on that part, the quality and relevance of the actual content?`
Larry:
I think that’s going to resonate with my folks a lot, the importance of relevant, quality content. Thank you so much, Chris. Oh, hey, one very last thing. If folks want to follow you or connect online, what’s the best place to find you?
Chris:
Absolutely. I mean, I’m on the socials, but yeah, LinkedIn is a good one. Christian Bach, Christian, Chris, I think it says, Bach because I used to go by Christian back in Europe, and then Chris happened over here. But LinkedIn is a good place, yeah.
Larry:
Excellent. I’ll put that in the show notes as well. Well, thank you so much, Chris. This was so awesome to get your perspective on this.
Chris:
Thanks so much for having me. It was fun.
Leave a Reply